AlphaCat的博客

文章目录1.交付高质量的产品1.1软件质量的挑战1.2什么是软件质量1.3缺陷并非“漏洞”1.4质量是永无终点的旅程1.5以明确目标为起点2.为高质量项目制定计划2.1最难以制订计划的时候,也是最需要计划的时候2.2作两类计划:阶段计划和产品计划2.3为每一项主要的工作制订产品计划2.4与你的管理者共同审查详细的计划2.5每个人都会因不恰当的计划蒙受损失2.6计划必须满足五条基本要求2.7若你不能使计划准确无误,那就常作计划2.8计划必须得到维护3.高效团队的基本要素3.1团队致力于共同的目标3.2团队合作

本文仅对《黑客与画家》中笔者感兴趣的地方进行了摘录文章目录为什么书呆子不受欢迎黑客与画家不能说的话良好的坏习惯另一条路如何创造财富关注贫富分化防止垃圾邮件的一种方法设计者的品味编程语言解析梦寐以求的编程语言设计与研究为什么书呆子不受欢迎书呆子”与“高智商”有强烈的正相关关系如果智力本身与“受欢迎”无关,为什么聪明的小孩一直不受同龄人的欢迎呢?我认为,答案就是他们真的不想让自己受欢迎书呆子不受欢迎的真正原因,是他们脑子里想着别的事情。他们的注意力都放在读书或者观察世界上面,而不是放在穿衣打扮、开晚会

文章目录《人件》读书笔记前言人的困难开发者之间的交互一-管理人力资源错误在所难免人力不是齿轮多花时间进行思考和学习西班牙理论管理者的艺术二-办公环境花钱就是省钱关于“流”人既是个体的人，又是群体的人三-正确的人正确的人管理热力学第二定律为什么人力不是齿轮《人件》读书笔记前言软件系统的主要问题不在于技术,而在于社会性因素实际上读到这句话的时候，我已经明白了这本书的主旨，它与《人月神话》中所讲述的核心观点实际上是一致的。我们回到《人月神话》中第一章所引出的那一个问题：为什么我们的项目看起来好像

人月神话读书笔记文章目录人月神话读书笔记第1章-焦油坑第2章-人月神话2.1为什么项目会滞后2.2安排的不合理2.3Brooks法则第3章-外科手术队伍3.1必须有优秀的专业的程序员3.2小而精的队伍第4章-贵族专制、民主政治和系统设计第6章-贯彻执行第8章-胸有成竹第9章-削足适履9.1规模控制9.2空间技能第10章-提纲挈领第11章-未雨绸缪11.1重视试验性版本11.2为变更计划组织架构11.3前进两步,后退一步—程序维护11.4前进一步,后退一步——系统熵随时间增加第12章-干将莫邪第14章-祸起

文章目录核心观点—概念完整性和结构师开发第二个系统所引起的后果盲目的功能和频率猜测图形界面的成功没有构建舍弃原型——瀑布模型是错误的增量开发模型更佳——逐进地精化构建闭环的框架系统Parnas产品族Microsoft的“每晚重建”方法增量式开发和快速原型关于信息隐藏,Parnnas是正确的,我是错误的人月到底有多少神话色彩?Boehm的模型和数据人就是一切放弃权利的力量最令人惊讶的新事物是什么?数百万的计算机全新的软件产业——塑料薄膜包装的成品软件买来开发——使用塑料包装的成品软件包作为构件核心观点—概念

文章目录第1章-焦油坑第2章-人月神话第3章-外科手术队伍第4章-贵族专制、民主政治和系统设计第5章-画蛇添足第6章-贯彻执行第7章-为什么巴比伦塔会失败交流项目工作手册组织架构第8章-胸有成竹第9章-削足适履第10章-提纲挈领第11章-未雨绸缪为变更计划组织架构前进两步,后退一步—程序维护前进一步,后退一步——系统熵随时间增加第12章-干将莫邪高级语言交互式编程第13章-整体部分第14章-祸起萧墙第15章-另外一面第1版结束语第1章-焦油坑编程系统产品( Programming Systems

文章目录摘要介绍根本困难以往解决次要困难的一些突破银弹的希望针对概念上根本问题的颇具前途的方法摘要关注软件任务中的必要任务仔细地进行市场调研,避免开发已上市的产品在获取和制定软件需求时,将快速原型开发作为迭代计划的部分;有机地更新软件,随着系统的运行、使用和测试,逐渐添加越来越多的功能;不断挑选和培养杰出新生代的概念设计人员。介绍没有银弹根本困难软件开发中困难的部分是规格说明、设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度进行验证。软件系统中无法规避

文章目录需要什么样的文档流程图自文档化的程序公共应用程序的用户在时间和空间上都远离它们的作者,因此对这类程序,文档的重要性更是不言而喻。对软件编程产品来说,程序向用户所呈现的和提供给机器识别的内容同样重要。需要什么样的文档不同用户需要不同级别的文档。某些用户仅仅偶尔使用程序,有些用户必须依赖程序,还有一些用户必须根据环境和目的的变动对程序进行修改使用程序。每个用户都需要一段对程序进行描述的文字。(1)目的。主要的功能是什么?开发程序的原因是什么?(2)环境。程序运行在什么样的机器、硬件配

文章目录里程碑还是沉重的负担“其他的部分反正会落后”地毯的下面当人们听到某个项目的进度发生了灾难性偏离时,可能会认为项目一定遭受了一系列重大灾难。然而,通常灾祸来自白蚁的肆虐,而不是龙卷风的侵袭。同样,项目进度经常以一种难以察觉,但是残酷无情的方式慢慢落后。实际上,重大灾害是比较容易处理的,它往往和重大的压力、彻底的重组、新技术的出现有关,整个项目组通常可以应付自如。但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。昨天,某个关键人员生病了,无法召开某个会议。今天,由于雷击打坏了大厦的供电

剔除BUG的设计测试规格说明。在编写任何代码之前,规格说明必须提交给外部测试小组,以详细地检査说明的完整性和明确性。如同 yssotsky所说的,开发人员自己无法完成这项工作:“他们不会告诉你他们不懂。相反,他们乐于自己摸索出解决问题和澄清疑惑的办法。”自上而下的设计。在1971年的一篇论文中, Niklaus Wirth把一种被很多最优秀的编程人员多年使用的设计流程形式化。尽管他的理念是为了程序设计,也完全适用于复杂系统的软件开发设计。他将系统开发划分为体系结构设计、设计实现和物理编码..

就工具而言,即使是现在,很多软件项目仍然像经营一家五金店。每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集,这些工具成为个人技能的直观证明。正是如此,每个编程人员也保留着编辑器、排序、内存信息转储和磁盘空间实用程序等工具。这种方法对软件项目来说是愚蠢的。首先,项目的关键问题是沟通个性化的工具会妨碍而非促进沟通。其次,当机器和工作语言发生变化时,技术也会随之变化,所有工具的生命周期都是很短的。最后,毫无疑问,开发和维护公共的通用编程工具的效率更高。不过,仅有通用工具是不够的。专业..

规模控制 指定总体规模的预算 指明模块有多大的同时，确切定义模块的功能 培养开发人员从系统整体出发、面向用户的态度 空间技能 用功能交换尺寸。设计人员必须决定用户可选项目的粗细程度 “空间——时间”的折中 编程需要技术积累 数据的表现形式是编程的根本计算机产品的文档 目标：定义待满足的目标和需要,定义迫切需要的资源、约束和优先级。 技术说明:计算机手册加性能规格说明。它是在计划新产品时第一个产生,并且最后...

实践是最好的老师，但智者还能从其他的地方有所收获——《穷理查年鉴》必须声明的是,构建独立小型程序的数据不适用于编程系统产品。对规模平均为3200指令的程序,如 Sackman、 Erikson和 Grant的报告中所述,大约单个的程序员所需要的编码加调试时间为178个小时,由此可以外推得到每年35800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的1/4,相应推断出的生产率几乎是每年80000代码行。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此,上述小型项目数据的外推是.

在系统设计中,概念完整性应该是最重要的考虑因素。也就是说,为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。 如何获得概念的完整性 这样的观点是否要有一位杰出的精英,或者说是结构设计师的贵族专制,和一群创造性天赋和构思被压制的平民编程实现人员? 如何避免结构设计师制订出无法实现,或者是代价高昂的技术规格说明,使大家陷入困境? 如何才能与实现人员就技术说明的琐碎细节充分沟通,以确保设计被..

20000美元/年的程序员的生产率可能是10000美元/年程序员的10倍需要沟通协作的人员数量影响着开发成本如果在一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发现在我们来验证一下这个解决方案。一方面,这个开发队伍不是通常所说的不超过10个人的、理想的小型精干的队伍,该团队的规模如此之大,以至于至少需要两个层级的管理,或者大约5名管理人员。另外,它需要额外的财务、人员、空间、文秘和机器操作方面的支持。另一...

缺乏合理的进度安排是造成项目滞后的最主要原因导致这种灾难的原因 对估算技术缺乏有效的研究 估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆 软件经理通常不会有耐心持续地估算这项工作 对进度缺少跟踪和监督 当意识到进度的偏移时，下意识的反应是增加人力 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。十个...

过去几十年的大型系统开发就犹如这样一个焦油坑,很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过只有极少数的项目满足了目标、进度和预算的要求。各种团队,大型的或小型的,庞杂的或精干的,一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢。图1-1的左上部分是程序( Program)。它本身是完整的,可以由作者在所开发的系统平台上运行。它通常是车..