第6部分 系统考虑（System Considerations）
第27章 程序规模对构建的影响（How Program Size Affects Construction）
随着项目规模的增大，更大一部分错误要归咎于需求和设计。
随着项目规模的增长，构建活动将只占项目总工作量的一小部分。
对于大项目来说，如果不有意识地去选择方法论，就将无法完成任务。
项目越正规，你不得不写的文件的数量也越来越多，用于确认你已经完成了自己的工作。
随着项目规模的扩大，交流需要加以支持。大多数方法论的关键点都在于减少交流中的问题，而一项方法论的存亡关键也应取决于它能否促进交流。
在其他条件都相等的时候，大项目的生产率会低于小项目。而大项目的每千行代码错误会高于小项目。
在小项目里的一些看起来“理当如此”的活动在大项目中必须仔细地计划。随着项目规模扩大，构建活动的主导地位逐渐降低。
放大轻量级方法论要好于缩小重量级方法论。最有效的办法是使用“适量级”方法论。
第28章 管理构建（Managing Construction）
鼓励良好编码实践的一些技术：
-
给项目每一部分分派两个人。
-
逐行复查代码。
-
要求代码签名。
-
安排一些好的代码示例供人参考。
-
强调代码是共有财产。
一个简单而有效的衡量标准是：“我必须能阅读并理解这个项目里的所有代码”。
需求变更和设计变更：
-
遵循某种系统化的变更控制手续。
-
成组地处理变更请求。记下所有的想法和建议，不管它实现起来有多容易。把它记录下来，直到你有时间取处理它们。到那时，把它当做整体来看待，从中选中最有益的一些变更来加以实施。
进度落后时，增加时间通常并不可行。
任何一种项目特征都是可以用某种方法来度量的，而且总会比根本不度量好得多。度量结果也许不会完全精确，度量也许很难做，而且也需要持续不断地改善结果，但是它能使你对软件开发过程进行控制，而如果不度量就根本不可能控制。
程序员之间有着数量级的差异。即时个体程序员都一样，不同编程团队在软件质量和生产率上也有着相当大的差异。
第29章 集成（Integration）
要点：
-
构建的先后顺序和集成的步骤会影响涉及、编码、测试各类的顺序。
-
一个经过充分思考的集成顺序能减少测试的工作量，并使调试变容易。
-
增量集成有若干变型，而且–除非项目是微不足道的–任何一种形式的增量集成都比阶段式集成好。
-
针对每个特定的项目，最佳的集成步骤通常是自顶向下、自底向上、风险导向以及其他集成方法的某种组合。T型集成和竖直分块集成通常都能工作得很好。
-
Daily Build能减少集成的问题，提升开发人员的士气，并提供非常有用的项目管理信息。
第7部分 软件工艺（Software Craftsmanship）
第32章 自说明代码（Self-Documenting Code）
好代码本身就是最好的说明。如果代码太糟，需要大量注释，应先试着改进代码，直至无须过多注释为止。
注释应说出代码无法说出的东西–例如概述或用意等信息。
第33章 个人性格（Personal Character）
编程工作本质上是项无法监督的工作，因为没人真正清楚你正在做什么。
高智商与优秀的程序员之间并无太密切的联系。
编程首先是与人交流，其次才是与计算机交流。
人的个性对其编程能力有直接影响。
最有关系的性格为：谦虚、求知欲、诚实、创造性、纪律，以及高明的偷懒。
小聪明、经验、坚持和疯狂既有助也有害。
好性格与培养正确的习惯关系甚大。要成为杰出的程序员，先要养成良好习惯、其他自然水到渠成