技艺的乐趣 The Joys of the Craft
- 编程是一种记忆
- 凡人享受了上帝造物的乐趣，不亦快哉
- 所造之物有用于世，不亦快哉
- 所造之物妙境玄机，不亦快哉
- 在未知中求索，日日履新，不亦快哉
- 所造之物是纯粹智慧的产物，不亦快哉
编程的苦恼 The Woes of the Craft
- 编程要求完美，而完美却又不可达，这是一切苦恼的根源
- 编程者不得不依赖他人的软件和接口交互来继续自己的开发；对他人程序的依赖对编程者特别痛苦
- 设计大的概念和系统非常兴奋，但找出一个细小的bug却大费周章
- 比起编程带来的成就感，测试大量发现bug往往令人沮丧，却又无法逃避
- 最后一个苦恼，也是压垮骆驼的最后一根稻草：作品千辛万苦的完成时，又一代新技术已经诞生，你的作品被取而代之似乎已经迫在眉睫
- 任务和挑战是对于现实的问题，如何找到既满足实际的时间表，又只使用现有的资源的现实的最佳解决方案。
- 程序的性能和大小，空间和时间往往是矛盾的，编程者往往在鱼和熊掌都要兼得的需求中挣扎。
打破人月神话的关键：沟通 Communication / Passing the Word
- 团队中的沟通包括聆听、汇报、激励士气等，永远不能用软件工具替代
- 软件项目的最大成本在于沟通，协调每个人对目标和业务的理解，以及消除由于无效沟通和理解而造成的系统缺陷
- 软件经理如何保证每个人都听到、理解并且正确实现了架构师的设计思想和决策？
- 人员越多，越难保证概念的完整性
- 沟通增加的额外开销有两类：培训和内部沟通
- 人员越多，子任务越多，内部沟通的代价是n(n-1)/2，所以合理控制项目人数能控制沟通复杂度和有效性
- 子任务间的沟通代价是额外的时间开销，这是打破人月神话的关键所在
- 额外增加的沟通代价会大大减少程序员的开发时间
- 增加更多的开发人员会延长开发时间，而不是缩短
- 文档，例如概要设计说明书，是架构师和成员沟通的良好途径和精确、完整的书面规约
- 会议是贯彻信息的必要方式，会议要有效率，严格次数和参与人员
- 周例会侧重于交流和启发，处理问题，决策快速灵活，给出解决方案以使得工作能继续
- 除了会议形式的正式沟通，平时的非正式沟通也很重要，否则架构师不知道开发人员有没有正确的在实现自己的设计
- 另一种沟通形式是工作手册，记载项目信息的细节和每一个问题以及如何解决的，它是项目的第一手资料，灵感的火花和失败的肇因都可以由此追踪
- 无论概要设计的多么精妙，随着开发活动的展开，很多问题会出现。其中一部分是设计师的架构实现问题，需求理解问题，设计和实现矛盾问题，以及开发人员对需求或架构师的设计错误的理解所导致
- 即使每个小组都有良好的愿景，但若缺乏沟通，则他们的努力可能恰好互相抵消，从而都感到沮丧
- 良好的组织结构能定义明确的接口人、适合的角色定义，能减少沟通次数、提高协调效率。因为树状结构体现的是权威和责任的层次关系，然而交流往往是网状结构的
测试 Testing
- 测试是软件质量保证的关键，也是最难进行项目预估的部分
- 测试时间通常占了错误预估的项目时间的大部分
- 很少有人计划1/2的测试时间，但事实上却实际发生了；所以应当尽可能多的在计划中安排测试时间
- 测试往往是通向完美的必经之路，测试中的困境犹如黎明前的黑暗
- 不受开发人员立场所左右的测试团队是项目经理的诤友
- 尽早的引入测试和核查（Code Review），错误修复的越早，代价越小
- 测试和开发一样，不能盲目入手，事先做好调研和规划，能够事半功倍
- 测试会涉及大量的编码工作，不仅白盒代码测试需要编写代码执行，安全测试，压力测试等同样需要编制测试程序来模拟用户环境，并验证系统的健壮性和正确性等诸多质量特性。优秀的测试人员同样需要有良好的程序实现能力
作者推荐的开发时间安排 Scheduling a software task
- 1/3 Planning 开发计划和设计
- 1/6 Coding 编码
- 1/4 Component test and early system test 组件测试和早期系统测试
- 1/4 System test 系统集成测试
项目估计 Estimation
- 迫切的食客让厨师手忙脚乱，迫不及待的投资人让软件开发经理铤而走险
- 软件经理匆促做出的估计，缺少足够的数据支持和有效的度量方法，更多的依赖危险的直觉
- 一旦软件经理拥有清晰的量化数据、初步的业务验证模型和图表支持自己的计划，便能像具有职业自信的厨师一样拒绝食客的催促，胸有成竹的完成每个工序，而不会因为投资人的催促而乱了章法
- 项目估计中不能远离人间烟火，机器崩溃时间、高优先级的其它事务、会议、写文档、公司事项、生病、休假以及个人事假等都要考虑到
外科手术式的团队 The Surgical Team
- 对付软件开发，应当建立外科手术式的团队；一个人主刀，而不是每个人主刀；其他人提供支持，这会最大程度的提高效率和生产力
- 外科手术团队的核心理念在于配合，而非分工
- 手术师：Chief Programmer 首席开发人员或架构师，需要十年以上的经验，对数学、软件知识、也业务领域都拥有丰富经验
- 副舵手：相对于架构师有较少经验，例如5-8年经验，是架构师的首席备份和助手
- 其他辅助人员：手术师不可能面面俱到和处理所有事务，需要其他辅助人员来支持，例如文档书写，帮助支持等
- 其他必备：良好的工具以及测试人员，“工欲善其事，必先利其器”，软件开发也一样，必须有良好的开发工具，开发环境和其他显著提高生产力的先进支持工具；
并行工作 Work in parallel
- 早期设计应由架构师和首席程序员参与，而不是让大量的程序员一起涌入早期设计；面向对象的系统最好使用统一建模语言（UML）开描述系统包含的结构和过程
- 编码人员在等待架构师完成总体设计时并非无所事事，他可以实现开发环境的准备，开发语言的熟悉，难点算法的预研，系统原型的建立和探索，以及和架构师的交互等
- 测试人员可以在系统设计完成后期介入，在开发人员的开发过程中设计测试案例
- 当程序模块之间的耦合度较高时，人均代码生成率则相对低下
应对变化 Plan the System for Change
- 建立原型（Pilot System），提交给客户，然后不断修改，推倒，迭代，近年来兴起的敏捷模型更为强调临时模型的普遍使用。（只适合小系统）
- 应当有人负责控制需求变更，控制版本，并且详细记录每个变更，严密保持实现和文档的一致性，否则将陷入混乱
- 提倡小增量的变更，每次只变更系统的一小部分，而不是试图让所有东西在一个大发布版本中都完成
- 变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术在变化，故而最佳的解决方案也应随之变化
- 商业应用软件的发布之时，并不是变化终止之时，有时候还意味着来自实践的变化需求的产生；因为软件开发的测试往往是测试人员设计的测试案例，而实际上的用户案例，往往更为广泛而复杂。软件发布后的广泛使用，往往会发现许多在测试阶段始料不及的错误。事实往往是，用户越多，使用的越多，发现的bug越多。这个时候回归测试非常关键。尽量做到自动化的回归测试。
- 为变化而规范组织结构，在技术上是灵活的，可以方便的调配技术力量，适应开发过程中的种种问题，能够有效减少人员之间的接口，减少角色冲突，建立开诚布公的工作氛围；因为组织结构的目的就是提高组织的目标执行力，降低必须的交流和协调工作
- 高级技术人员给予管理培训，管理人员给予一定的技术培训，同时项目目标、进度和管理问题必须在所有资深人员中共享；这样，资深人员可以技术上做资深的工作，同时准备好也可以管理部分编程者。让资深技术人员和管理人员大家发挥所长，具备同样的权威和待遇。
其他
- 完美的产品需要完美的细节
- 实际的商用软件开发中，易用性和功能完善性应达到一种平衡
- 产品化的软件系统所需的资源和时间代价，并不是实验室原型系统代码的简单倍数关系。文档，部署，用户测试，用户培训，客户实际部署和试用，等时间必须另外加上。
- 在软件的Release Notes中向客户列出所有已知的尚存的bug，是当前软件开发团体的通常做法。这些bug不影响软件的正常使用，有待在后续版本中修复
- 设计师往往踌躇满志的进行过度设计，其结果是系统成为一个笨重的大饼
- 程序员的完美主义倾向常常导致画蛇添足，明智的删繁就简则是上策
- 项目失败的原因往往不是目标、人力、财力、时间和技术，而是因为失败的沟通和失败的组织结构，难以对付复杂多变的商业需求
- 表示是编程的精髓，巧妙的数据结构定义和算法往往能大幅度的提高系统的运行效率
- 大多数经验丰富的程序员都有自己的程序库，这可以帮助他们在开发过程中复用大约30%的代码；而一个大公司级别的复用程度能达到75%
- 软件项目实施中所选择的技术和工具对保障项目能如期完成是至关重要的
- 仿真程序也运用于软件系统和服务器的性能测试和压力测试