读书：《人月神话》摘录版16-19章

人月神话.PNG

第十六章 没有银弹－软件工程中的根本和次要问题
所有软件活动包括根本任务－打造构成抽象实体复杂概念结构，次要任务－使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。关注软件任务中必要活动，作者建议：
仔细地进行市场调研，避免开发已上市的产品
在获取和制定软件需求时，将快速原型开发作为迭代计划的一部分
有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能
不断挑选和培养杰出新生代的概念设计人员
对规范化过程进行持续不断地努力。没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。根本问题－软件特性中固有的困难，次要的－出现在目前生产中，但并非那些与生俱来的困难。一个互相牵制关联的概念结构是软件实体w必不可少的部分，它包括：数据集合、数据条目之间的关系、算法和功能调用等。这些要素本身是抽象的，体现在不同的表现形式下的概念构造是相同的。作者认为软件开发中困难的部分是规格说明、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行完整。软件开发总是非常困难的，天生就没有银弹，现代软件系统无法规避的内在特性：复杂度、一致性、可变性和不可见性。
以往解决次要困难的一些突破：高级语言（生产率、可靠性和简洁性）、分时（缩短系统响应时间）、统一编程环境（提供集成库、统一文件格式、管道和过滤器）。银弹的希望：Ada和其它高级语言、面向对象编程、人工智能、专家系统（建立接口规则，制定测试策略，提供BUG频率和优化建议等）、自动编程、图形化编程、程序验证、环境和工具、工作站。
针对概念上根本问题的颇具前途的方法。所有针对软件开发过程中次要困难的技术工作基本上能表达成生产率公式：任务时间=频率*时间，次数求和，假设工作的创造性活动占据大部分时间。我们必须考虑那些解决软件上必要困难的活动－即，准确地表达复杂概念结构。幸运的是，其中一些非常有希望：购买和自行开发、需求提炼和快速原型（让客户与设计人员多次广泛交流沟通）、增量开发、卓越的设计人员（卓越设计者产生的成果更快、更小、更简单、更干净、实现的代价更少，卓越和一般之间差异一个数量级）－杰出的设计人员和卓越的管理人员一样重要，他们应该得到相同的培养和回报。如何培养杰出的设计人员呢？
尽可能早地、有系统地识别顶级的设计人员，最好的通常不是最有经验的人员
为设计人员指派一位职业导师，负责他们技术方面的成长，仔细地为他们规划职业生涯
为每个方面制定和维护一份职业计划，包括与设计大师的、经过仔细挑选的学习过程，正式的高级教育和短期的课程－所有这些都穿插在设计和技术领导能力的培养安排中
为成长中的设计人员提供互相交流和激励的机会
第十七章 再论“没有银弹”
《没有银弹－软件工程中的根本和次要问题》。购买东西听取那些真正使用过产品并感到满意的用户的推荐。所有的创造性活动包括：概念性结构的形式规格化、使用现实的介质来实现、实际使用中与用户交互。软件开发中，“必要”的部分是构思这些概念上的结构，“次要”的部分是指它的实现过程。关键论点的正确与否归结为一个现实问题：整个软件开发工作的哪些部分与概念性结构的精确和有序表达相关，哪些部分是创造那些结构的思维活动？根据缺陷是概念性的，或者是表达上的问题，可以将这些缺陷的寻找和修复工作进行相应的划分。动机因素可以提高生产率－如果开发的次要部分少于整个工作的9/10，即使不占用任何时间，也不会给生产率带来数量级的提高。重用和交互的构件开发是解决软件根本困难的一种方法。固有的概念复杂性，无论是任何时间，使用任何方法设计和实现软件的功能。
复杂性是层次化的。《没有银弹》提出了全力解决复杂性问题的方法，这种方法可以在现实中取得十分乐观的进展。它倡导向软件系统增加必要的复杂性：层次化，通过分层模块或者对象；增量化，使系统可以持续地运行。乐观主义是程序员的通病。20世纪70年代，在软件生产上应用工程原理的目标是提高软件产品的质量、可测试性、稳定性以及可预见性－而不是软件产品的开发效率。生产率：购买，而非开发+创造性活动的强大工具。
面向对象编程，用更大的零件来构建。面向对象编程第一个特征，它强制的模块化和清晰的接口。其次，它强调了封装，即外界无法看到组件的内部结构：它还强调了继承和伴随着层次化类结构以及虚函数。面向对象还强调了继承和伴随着层次化类结构以及虚函数。面向对象还强调了强抽象数据类型化，它确保某种特定的数据类型只能由自身的相应函数来操作。软件包+程序重用，个人私人代码库/公司级别重用/需要对项目中的变更进行 统计和度量，重用需要良好的设计和文档。如果想获得所有潜在的重用，任何使用类库编程的人员必须学习其成员的语法（外部接口）和语义（详细的功能行为）。一些经验教训：
人们在上下文中学习，因此我们需要出版一些复合产品的例子，而不仅仅是零部件的库
人们只会记忆背诵单词而语法和语义是在上下文中通过使用逐渐地学习的
人们根据语义的分类对词汇组合规则进行分组，而不是通过比较对象子集
第十八章 《人月神话》的观点：是与非？
好的自上而下设计。编写代码前，规格说明必须提交给外部测试小组，以详细地检查说明的完整性和明确性。项目经理应该制定一套策略，并为通用工具的开发分配资源；于此同时，他还必须意识到专业工具的需求。缺陷修复总会以20%-50%的几率引入新的BUG，老板可以使管理人员和技术人员具有互换性，为每个关键文档的维护提供了状态监督和预警机制。项目经理的基本职责是使每个人都向着相同的方向前进。项目经理主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。
项目工作手册，尽早和详细设计结构，实时更新。团队组织的目标是为了减少必要的交流和协作量。增强交流，尽早交流和持续沟通。小型、精干队伍是最好的－思绪尽可能的少。
进度安排：1/3计划、1/6编码、1/4构件测试以及1/4系统测试。精炼、充分和快速的程序往往是战略性突破的结果，而不仅仅是技巧上的提高。编程需要技术积累，每个项目需要自己的标准组件库。
关键路径，每日落后，日计划，老板期望日期和估计日期。
第十九章 20年后的人月神话
那些写作时正确，现在依然成立的部分：概念完整性是产品质量的核心，拥有一位结构师是迈向概念完整性最重要的一步。核心观点－概念完整性和结构师（一个整洁、优雅的编程产品必须向它的每位用户提供了一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略，用户感受到的是易用性中最重要的因素。大型编程项目与小型项目的管理性质上都不同，为获得一致性，经过深思熟虑的，有时甚至是英勇的管理活动是完全必要的）、结构师（产品结构师负责产品所有方面的概念完整性，用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法－模型所有者和用户代理。在不可避免地对功能、性能、规模、成本和速度进行平衡时，卓有成效地体现用户的利益。这个角色是全职工作，只有在最小团队里，才能和团队经理角色合并－结构师类似于导演/经理类似于制片人）、将体系结构和设计实现物理实现相分离（体系结构和实现划分在各个设计任务中形成了清晰的边界，边界两边都有大量的工作）、结构师方案的重用（主结构师把系统分解成子系统，系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。每个部门拥有自己的结构师，他必须向主结构师汇报，重复递归）
开发第二个系统所引起的后果－盲目的功能和频率猜测：为大型用户群设计（设计通用工具比设计专用工具更加困难，这是因为必须为不同用户的各种需要分配权重）、盲目的功能（通用工具不断困扰结构师的诱惑是以性能甚至是易用性为代价，过多地向产品添加边界实用功能）、定义用户群（用户群越大和越不确定，就越有必要明确地定义用户群，以获得概念完整性。结构师的用户画像会有意或者无意地影响每天结构决策，因此有必要使设计队伍共享一幅相同的用户图像，这需要把用户群的属性记录下来，包括：他们是谁、他们需要什么、他们认为自己需要什么、他们想要的是什么）、频率（为了得到完整、明确和共享的用户群描述，结构师应该猜测，或者假设一系列完整的属性和频率值。总结：为用户群的属性明确地记载各种猜测，清晰和错误都比模糊不清好得多－对于任何软件产品，任何用户群属性实际上都是一种概率分布，每个属性具有若干可能的值，每个值有自己的发生频率）。
图形界面的成功：通过类比获得的概念完整性、命令表达和双光标问题、一个卓越的解决方案（键盘）、用户功能和易用性、从新手向熟练用户的逐渐过渡（快捷键）、强制体系结构的实施，作为设备的直接整合、WIMP过时被淘汰。
没有构建舍弃原型－瀑布模型是错误的！瀑布模型的基本错误是它假设项目只经历一次过程，而且体系结构出色并易于使用，设计是合理可靠的，随着测试进行，编码实现是可以修改和调整的。换句话说，瀑布模型假设所有错误发生在编码实现阶段，因此它们的修复可以很顺畅地穿插在单元和系统测试中；第二个谬误是它假设整个系统一次性地被构建，在所有的设计、大部分编码、部分单元测试完成之后，才为闭环的系统测试合并各个部分。《未雨绸缪》最大的错误是它隐含地假设了使用传统的顺序或者瀑布开发模型。1970年一篇经典论文：存在一些从一个阶段到前一个阶段的反馈、将反馈限定在直接相邻的先前阶段，从而容纳它引起的成本增加和进度延迟。
必要存在逆向移动在开发过程“下游”的经验和想法必须跃行而上，有时会超过一个阶段，来影响“上游”的活动。在把任何东西变成代码之前，可能要往复迭代两个或更多的体系结构－设计－实现循环。
增量开发模型更佳－渐进地精化。构建闭环的框架系统（先使用空函数进行基本轮询，为每个功能都提供子函数调用，编译测试可以使它不断进行。不做任何事情，但至少是正常运行的；添加输入和输出模块，尽管只是一个框架，每个阶段都有一个可运行的系统；增量开发），我们所有时刻都拥有一个可运行的系统，我们可以很早就开始用户测试、我们可以采用预算开发的策略，彻底保证不会出现进度或者预算超支的情况（以允许的功能牺牲为代价）。
产品家族树：基产品－内部版本－功能修改、第二代产品、移植到其他平台。设计人员对产品的后期扩展和后续版本进行预测，定义它们在功能或平台上的差异，搭建一颗相关产品的家族树。将那些变化可能性较小的设计决策放置在树的根部。这样的设计策略使得模块的作用最大化－发布产品+增量开发策略创建后续版本，每日构建（规范化、可跟踪、开诚布公的流程），增量开发和快速原型。把所有工作都暴露在每个人的凝视之下，能够帮助质量控制，源于其他人优秀工作压力，同伴能直接发现缺陷和bug VS 代码模块应该采用定义良好的接口来封装，这些模块的内部结构是程序员的私有财产，外部不可见。
《软件工程经济学》得出人力和时间之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。特别是他发现：
第一次发布的成本最优进度时间，月单位的最优时间是估计工作量的立方根，估计工作量则有规模估计和模型中的其他因子导出。最优人员配备曲线是由推倒得出。
当计划进度比最优进度长时，成本曲线会缓慢攀升。时间越充裕，所花的时间越长
当计划进度比最优进度短时，成本曲线急剧升高
无论安排多少人手，几乎没有任何项目能够在少于3/4的计划出的最优时间内获得成功！
新成员有学习曲线和需要额外的沟通和培训工作，项目早期加人更安全。最有价值的是如何添加新成员，进行培训，用工具来支持等。他建议项目后期增加的开发人员，必须作为团队成员，愿意在过程中努力投入和工作，而不是企图改变或者改进过程本身！作为平衡，我还是坚持这个简单的陈述，作为真理的最佳近似和一项经验法则－警告经理们避免对进度落后的项目采取的盲目、本能的修补措施。
人就是一切（或者说，几乎是一切）：对项目成功而言，项目人员的素质、人员的组织和管理比使用工具和采用技术方法更重要。团队质量是项目成功最大的决定因素，实际上是下一个次要因素的4倍。工具重要，对人的关注、激励和培养的持续研究。《人件：高生产率的项目和团队》：管理人员的职责不是要人们去工作，而是创造工作的可能。相同组织中开发人员的表现之间及工作空间和生产率以及缺陷水平之间令人吃惊的关联。团队融合，创造力来自个人，而不是组织架构或开发过程，项目经理面临的中心问题就是如何设计架构和流程，来提高而不是压制主动性和创造力。《小就是美：人们关心的经济学》：权力下放，团队是流程的拥有者，并且必须拥有一个流程－他们有不同的流程，他们是进度计划的所有者，但能感受到市场的压力。授权。
件工程是一些特殊问题：如何把一系列程序设计和构建系统；如何把程序或者系统设计构建成健壮性、经过测试的、文档化的、可支持的产品；如何维持对大量的复杂性控制。持续发展，持续学习，工程方法，谦卑。