第一部分：打好基础

第一章

构建包括的范围很大：

定义问题

需求分析

规划构建

软件架构（高层设计）

详细设计

编码与调试

单元测试

集成测试

集成

系统维护

保障维护

----------------

平时接触的也就是从详细设计到系统维护，

后面的测试和技术支持都是必须要打交道的，

但是定义问题和需求，基本都属于产品部门。

----------------

P7：“很多项目，程序员得到的唯一文档就是源代码本身。需求规格书和设计文档可能过时，但是源代码是最新的”

——基本如此，很多工程只有在编码之前有需求文档和设计文档，在以后的修改中，基本都不会去修改这2个文档。

----------------

构建活动主要是从详细设计到开发者测试，也就是程序员的工作，从设计到编码实现，到最后的自测试。

P7：“构建活动是唯一一项确保会完成的工作”

因为时间原因，需求可能是临时的，测试可能是不充分的，但是代码必须编码完成。

——以前有个培训，排名程序员的各项条件，我把诚实放到后面了，不是它不重要，而是没有办法去不诚实，跟卖商品不一样，有没有实现需求，靠嘴说谎马上就要露馅。

 

第二章

“隐喻的重要性。”

“使用隐喻的方法叫建模。比如分子运动理论是撞球，光的波粒二象性。”

“编程最大的调整是问题概念化，编程中很多错误是概念性的错误。”——个人认为，不应该是编程中，开始编程基本概念已经确定了，而是在前三步（定义问题，需求分析，规划构建）

“把软件的构建过程比作房屋的建设过程，移动承重墙肯定比移动隔墙成本低，软件的结构改变也根本比周边功能改动成本高。”

 

第三章

“准备工作的中心目标是减低风险。”

“建设大厦和搭建狗舍的前期准备肯定不一样。”

“测试不能测试出‘设计了一个错误的产品’，解决缺陷要在构建活动之前完成”

准备工作不周全的原因“

1、绝大多数开发人员没有需求、产品方面的经验和训练。

2、程序员无法抵御‘尽快开始编码’的欲望。

3、管理者对准备工作的重要性不理解。

--------------------

——对2深有体会，每次总是喜欢写个大致的详细设计，然后立刻投入编码，不过似乎只有在编码中才能更好的去构想细节，如果不编码那么脑袋里面就没有具体的印象，可能是没有使用伪代码编程的习惯，在后面的章节里面有伪代码编程的例子。

这也同样导致了我宁愿一个人加班完成工作，也不原因和别人合作完成一个程序。

不过在实际中，可能是我的团队人数都很少，一个人的效率要比几个人合作高的多。而且就算是分开每人维护一个模块，接口的调试都会花去很多时间。如果2个模块是自己一个人负责的，接口的调试很快就通过了。这或许也是最早设计报文格式的时候不周全导致的。

-------------------

“有时候用户一开始不完全确定自己想要什么，找出他们真正想要的，比做一个错误的东西再修正要好多了。”

没有直接面对客户，也没有直接的感觉，但是客户经常会提出永远都用不到还必须要有的功能。

 

“需求、架构、构建，缺陷越靠前，修改的成本越大。”

------------------

“我们最好立即编码，后面有很多调试要做。”和“我们没有为测试安排太多时间，因为将来不会发现太多的缺陷。”

相对而言，第二个比第一个好。

-----------------

“迭代法开发比序列开发节约成本”

迭代法就是随着项目的进展，开始检查并返工，再进行下一步的开发。

序列法是开发完成后检查并返工。

-----------------

“问题定义只是定义了问题是什么，而不涉及解决方案。”

“问题定义要用顾客的语言来书写，而不是用计算机的专业术语来叙述。”

‘我们的出口带宽总是跑满’，‘我们需要优化缓存系统，让出口带宽不要跑满’

明显前一个是问题，而后一个不像问题，倒像一个解决方案了。

----------------

“明确需求有助于用户驾驭系统功能，有助于避免程序员之间的争论”

——感觉很多程序做出来，发现需求理解的不一样，往往研发之间无关紧要的就糊过去了，最多的争论在于研发和测试对它的不同理解。

“客户经常改动需求，IBM的统计平均开发过程中，需求会有25%的改动。”

“客户往往喜欢拍脑门，用成本和进度可以提醒他们。”

——哈

 

P42针对功能需求有疑问，这么详细的外部接口，包括握手协议，通信协议到底是属于需求还是属于详细设计？感觉不应该是需求层的啊。

P46数据设计也一样的疑问，不过里面提到的，使用什么数据结构或算法要写出为什么这么用的好处，便于让程序员洞察构架师的思想。

“数据通常只有一个子程序或一个类之间访问”

“程序员会处于专业自豪感，对自己编写的类做过度工程”

——的确是事实啊，但是如果有时间的话，难道不好吗？

“架构应该描述所有主要决策的动机，而不是向来如此”

“优秀的架构很大程度上与机器和编程语言无关，但是也不能忽视环境。独立于环境的好处是避免过度架构。”

 

第四章

构架决策：

选择编程语言

编程约定（代码规范和风格、性能or稳定）

团队工作（代码管理cvs，如何分工）

质量保证（先写测试用例，评审）

工具（代码管理工具、编译工具）