软件构造之“构造”（construction）漫谈

[ 一 ] 软件培育

1. 一个有趣的隐喻。
软件开发人员每次设计系统的一小部分、写出一段代码、做一点测试，并将成果一点点添加到整个系统中。人们逐渐为这个“每次做一点”的主意找到了恰当的隐喻——growing（培育）。
2. 要养殖牡蛎吗？
牡蛎制造珍珠的过程逐渐地添加微量的碳酸钙。我们可以用生长这个词描述这个过程。而同样的，在开发软件的过程中，我们要学会如何一次为软件系统增加一个小部分。这就是“系统生长”。与之相关的词汇有“迭代的（iterative）”、“自适应的（adaptive）”以及“演进的（evolutionary）”。这是在描述一种以增量方式进行设计、编译和测试的软件开发概念。

[ 二 ] 软件构建

1. 构建意味着什么？
   构建就暗示了软件开发不是一蹴而就的，而是存在着多个阶段滴！
   具体阶段留待以后分解，现在先略略略。。。

2. 作为一个有良心的程序猿（软件开发人员），我们的构造是需要质量滴！
   那至少需要满足什么要求呢？可理解性、可维护性、可复用性、健壮性、时空性能；
   如果在一个项目的生命周期的前、中、后期都强调质量，那么一个高质量的计划、高效的实践以及系统测试是必不可少的。

[ 三 ] 前期准备

3. 你有WIMP综合征吗？
   *Why Isn’t Mary Programing?(WIMP)或者Why Isn’t Sam Coding Anything?(WISCA)*为什么Sam不在写代码？很多人控制不住自己写代码的欲望，于是果断的牺牲了前期准备。。。
4. 前期准备什么

[ 四 ] 需求变更怎么办？
三十六计走为上，放弃这个项目怎么样？或者使用能适应变更的开发方法。比如演进原型法，利用分阶段交付系统的方法不断的从用户获得反馈。

[ 五 ] 构造的典型组成部分

1. 程序组织
   明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情，并且对其他构造块负责的区域知道的越少越好。同时应该明确定义每个构造块的通信规则。对于每个构造块，架构应该描述他能直接使用哪些构造块，能间接使用哪些构造块，不能适用哪些构造块。
2. 主要的类
   架构应该详细定义所用的主要类。它应该指出每个主要的类的责任，以及该类如何与其他类交互。图应该包含对类的继承体系、状态转换、对象持久化等的描述。
3. 安全性
   实现设计层面和代码层面的安全性的方法。建立威胁模型。
4. 错误处理
5. 变更策略
   在开发过程中产品很可能发生变化。这些变更来自不稳定的数据类型和文件格式、功能需求的变更、新的功能特性等等。这些变更更可能是计划增加新的功能，也可能是没有添加到系统的第一个版本中的功能。因此软件架构是面临的一个主要挑战是，让架构做够灵活，能够适应可能出现的变化。
   架构应当清楚的描述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能，并说明“最优可能增强的功能同样是最容易实现的”。
   以下是《代码大全》中推荐的书籍：
   
   [ 六 ] Multi-dimensional software views