==========
代码大全 2
==========

.. book:: _
   :isbn: 9787121022982

Chapter 2 用隐喻来充分地理解软件开发
------------------------------------

-  「建筑」是软件构建的最佳隐喻

Chapter 3 三思而后行：前期准备
------------------------------

定义问题 -> 需求 -> 架构 -> 详细设计 -> 构建 -> 质量保证/系统测试

-  前期准备是非常重要的
-  在构建活动清除一个错误的的返工成本远远低于在开发过程后期再清除的成本

   -  即，发现错误的时间要尽可能接近引入该错误的时间

-  迭代开发法相比于序列开发法，通常是更好的选择

   -  迭代法在每轮迭代的末期修正缺陷，平均修正成本低
   -  迭代法会在项目过程中分次支付成本

-  应当从用户的角度，使用用户的语言定义问题
-  稳定的需求是软件开发中的「圣杯」，明确的需求有助于减少开发后的系统变更情况
-  架构应该定义程序的重要构造块（building blocks）
-  架构的组成部分：

   -  程序组织

      -  每个构造块实现一种高层功能
      -  各个构造块对其他构造块的了解应达到最小，将信息局限于构造块内
      -  明确构造块直接的通信规则

   -  主要的类

      -  指出主要类的责任，该类如何与其他类交互
      -  把类组织成子系统

   -  数据设计

      -  所用到的主要文件和数据表的设计
      -  数据应该只由一个子系统或子程序访问

   -  业务规则
   -  用户界面设计
   -  资源管理
   -  安全性
   -  性能
   -  可伸缩性
   -  互用性
   -  国际化/本土化
   -  输入输出
   -  错误处理

      -  错误处理常被认为是「代码约定」层次的事情
      -  应当考虑：

         -  纠正还是检测
         -  主动还是被动
         -  程序如何传播错误
         -  错误的处理有何约定
         -  如何处理异常
         -  在什么层次上处理错误：在发现的地方处理 or 专用的错误处理类
         -  类在验证输入的有效性方面需要负何种责任，能否假设自己接受到的数据
            是始终有效的？

   -  容错性
   -  架构可行性
   -  过度工程

      -  在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积

   -  复用决策
   -  变更策略
   -  架构的总体质量

Chapter 4 关键的构建决策
------------------------

-  编程约定：变量名，类名，子程序名，格式约定，注释约定

   -  *成功编程的一个关键在于避免随意变化*
   -  编写完软件后，几乎不可能改变软件遵循的编码约定

-  在一种语言上编程：大多数重要的编程原则不依赖特定语言
-  深入一种语言去编程：发明自己的编码约定，标准和类库弥补语言的不足

Chapter 5 软件构建中的设计
--------------------------

-  设计：

   -  设计是险恶的（wicked），你需要把问题解决一遍以便明确地定义它，然后再次解决
      该问题，从而形成可行方案
   -  设计是了无章法的——在犯错中修正——在你觉得没时间的时候停止
   -  设计是确定取舍和调整顺序的过程
   -  设计受到诸多限制：资源是有限的
   -  设计的成果是不确定的
   -  设计是启发式的
   -  设计是自然而然的：在评估，讨论，编码中演化和完善

-  软件的首要技术使命是管理复杂度
-  理想的设计特征：最小复杂度，可扩展性，松散耦合，可重用性，高扇入，低扇出，
   可移植性，精简性，层次性，使用标准技术
-  子系统间的通信应当严格限制

   -  子系统的通信图应当是无环的
   -  常见的子系统：业务规则，用户界面，数据库访问，特定系统依赖