全部书摘参见 读《代码大全2》
第1部分 打好基础
译序
应该首先为人编写代码，其次才是为机器
第1章 欢迎进入软件构建的世界
提高关键的质量和开发者的生产效率都是很重要的
构建活动会占到整个软件开发时间的30%~80%，占整个项目成本的65%左右
不同程序员的生产率差异可达10到30倍
软件构建是软件开发的核心活动，构建活动是每个项目中唯一一项不可少的工作
软件构建的主要活动包括：详细设计、编码、调试、集成、开发者测试（包括单元测试和集成测试）
第2章 用隐喻来更充分的理解软件开发
重要的研发成果常常产自类比
模型的威力就在于其生动性，让你能够把握整个概念
数据处理正在从“以计算机为中心”的观点向“以数据库为核心”的观点转变
算法直接给你解决问题的指导，而启发式方法则告诉你该如何发现这些指导信息，或者至少到那里去寻找他们
三分之二的项目在首次发布之后还有90%的工作量要做
精心计划并不意味着事无巨细的计划或者过度的计划
隐喻是启示而不是算法，因此往往有一点随意
隐喻把软件开发过程与其他你熟悉的活动联系在一起，帮助你更好的理解
有些隐喻比其他隐喻更贴切
通过把软件的构建过程必做是房屋的建设过程，我们可以发现，仔细的准备是必要的，而大型项目和小型项目之间也是有差异的。
通过把软件开发中的实践比作是智慧工具箱中的工具，我们又发现，每位程序员都有许多工具，但并不存在任何一个能适用于所有工作的工具，因地制宜的选择正确工具是成为能有效编程的程序员的关键
不同的隐喻彼此并不排斥，应该使用某种对你最有益处的隐喻组合
第3章 三思而后行：前期准备
软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划
人生苦短，当有大量更好的选择摆在你面前的时候，在一个荒蛮的软件企业中工作是不明智的。
尽早把哪些是最关键的需求要素和架构要素确定下来
选择序列式开发的理由：
需求相当稳定
设计直截了当，而且理解透彻
开发团队对于这一领域十分熟悉
项目的风险很小
“长期可预测性”很重要
后期改变需求、设计和编码的代价很可能较昂贵
选择迭代开发的理由：
需求并没有被理解透彻，或者出于其他理由你认为它是不稳定的
开发团队对于这一领域不熟悉
项目包含许多风险
“长期可预测性”不重要
后期改变需求、设计和编码的代价很可能较低
在射击之前，确信你瞄准了正确的目标
一般项目在开发过程中需求会有25%的变化，需求变更导致的返工占总返工量的75%~85%
需求核对表：
针对功能需求：
是否详细定义了系统的全部输入，包括其他源、精度、取值范围、出现频率等
是否定义了系统的全部输出，包括目的地、精度、取值范围、出现频率、格式等
是否详细定义了所有输出格式，web页面、报表等
是否详细定义了所有硬件和软件的外部接口
是否详细定义了全部外部通信接口，包括握手协议，纠错协议、通信协议等
是否列出了用户想要做的全部事情
是否详细定义了每个任务所用的数据，以及每个任务得到的数据
针对非功能需求（质量需求）：
是否为全部必要的操作，从用户的视角，详细描述了期望响应时间
是否详细描述了其他与计时有关的考虑，例如处理时间、数据传输率、系统吞吐量等
是否详细定义了安全级别
是否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等
是否定义了机器内存和剩余磁盘空间的最小值
是否定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件接口变更的能力
是否包含对“成功”的定义？“失败”的定义呢？
需求的质量：
需求是用用户的语言书写的吗？用户也这么认为吗？
每条需求都不与其他需求冲突吗？
是否详细定义了相互竞争的特性之间的权衡——例如健壮性与正确性之间的权衡
是否避免在需求中规定设计（方案）
需求是否的详细程度上保持相当一致的水平，有哪些需求应该更详细的描述吗？有些需求应该更粗略的描述吗？
需求是否够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么认为吗？
每个条款都与待解决的问题及其解决方案相关吗？能从每个条款上溯到它在问题域中对应的根源吗？
是否每条需求都是可测试的，是否可能进行独立的测试，以检验满不满足各项需求
是否详细描述了所有可能的对需求的改动，包括各项改动的可能性
需求的完备性：
对于在开发开始之前无法获得的信息，是否详细描述了问题不完全的区域
需求的完备度是否达到这种程度：如果产品满足需求，哪么它就是可接受的
你对全部需求都感到很舒服吗？你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西
架构的典型组成部分： 程序组织
主要的类
数据设计
业务规则
用户界面设计
资源管理
安全性
性能
可伸缩性
互用性
国际化/本地化
输入输出
错误处理
容错性
架构的可行性
过度工程
关于“买”还是“造”的决策
关于复用的决策
变更策略
架构的总体质量
架构核对表： 针对架构的主题
程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（包括理由）？
是否明确的定义了主要的构造块？（包括每个构造块的职责范围以及与其他构造块的接口）
是否明确涵盖了“需求”中列出的所有功能（每个功能对应的构造块也不太多也不太少）？
是否描述并论证了那些最关键的类
是否描述并论证了数据设计？
是否详细定义了数据库的组织结构和内容
是否指出了所用的关键业务规则，并描述其对系统的影响
是否描述了用户界面设计的策略
是否将用户界面模块化，使界面的变更不会影响程序的其余部分
是否描述并论证了处理IO的策略
是否估算了稀缺资源（如线程、数据库连接、句柄、网络带宽等）的使用量，是否描述并论证了组员管理的策略？
是否描述了架构的安全需求
架构是否为每个类，每个子系统，或每个功能域提出空间与时间预算
架构是否描述了如何达到可伸缩性
架构是否关注户操作性
是否描述了国际化/本地化策略
是否提供了一套内聚的错误处理策略
是否规定了容错的办法（如果需要）？
是否证实了系统各个部分的技术可行性
是否详细描述了过度工程的方法
是否描述了必要的“买vs.造”的策略
架构是否描述了如何加工被复用的代码，使之符合其他架构目标
是否将架构设计得能够适应很可能出现的变更
架构的总体质量：
架构是否解决了全部需求
有没有哪个部分是“过度架构”或“欠架构”，是否明确宣布了在这方面的预期指标
整个架构是否在概念上协调一致
顶层设计是否独立于用作实现它的机器和语言
是否明确了所有主要决策的动机
你，作为一名实现该系统的程序员，是否对整个架构感觉良好？
一般来说，一个运作良好的项目会在需求、架构以及其他前期计划方面投入10%~20%的工作量和20%~30%的时间
前期准备核对表：
你是否辨明了自己所从事的软件类型，并对所用的开发方法做出了相应的剪裁
你是否充分明确的定义了需求，而且需求足够稳定，能开始构建了？
你是否明确的定义了架构以便开始构建
是否已经指出项目中独有的风险，以避免构建活动面临不必要的风险
构建活动的准备工作的根本目标在于降低风险，要明确你的准备活动在降低风险，而非增加风险
如果你想开发高质量的软件，软件开发过程中必须由始至终关注质量。在项目初期关注质量，对产品质量的正面影响要比在项目末期关注质量的影响大
程序员的一部分工作是教育老板和合作者，告诉他们软件开发过程，包括在编码之前进行充分准备的重要性
你所从事的软件项目的类型对构建活动的前期准备工作有重大影响——许多项目应该是高度迭代的，某些应该是序列式的
没有明确的问题定义，那么你可能在构建期间解决错误的问题
如果没有做完良好的需求分析工作，你可能没能察觉待解决问题的重要细节。如果需求变更发生在构建之后的阶段，其代价是“在项目早起更改需求”的20至100倍。因此在开始编程之前，你要确认“需求”已经到位了
如果没做完良好的架构设计，你可能会在建构期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加，因此，也要确认“架构”已经到位了
理解项目的前期准备所采用的方法，并相应的选择构建方法
第4章 关键的构建决策
每种编程语言都有其优点和弱点，要明确知道你所使用语言的有点和弱点
在开始编程约定。“改变代码使之符合这些约定”是近乎不可能的
“构建的实践方法”的种类比任何单个项目能用到的要多。有意识的选择最适合你的项目的实践方法
问问你自己，你所采用的编程实践是对你所采用编程语言的正确响应，还是受它的控制，请记住“深入一种语言去编程”不要仅“在一种语言上编程”
你在技术浪潮中的位置决定了哪些方法是有效的——甚至是可能用到的。确定你在技术浪潮中的位置，并相应调整计划和预期目标
评论