第一部分：打好基础
第一章
构建包括的范围很大：
定义问题
需求分析
规划构建
软件架构（高层设计）
详细设计
编码与调试
单元测试
集成测试
集成
系统维护
保障维护
----------------
平时接触的也就是从详细设计到系统维护，
后面的测试和技术支持都是必须要打交道的，
但是定义问题和需求，基本都属于产品部门。
----------------
P7：“很多项目，程序员得到的唯一文档就是源代码本身。需求规格书和设计文档可能过时，但是源代码是最新的”
——基本如此，很多工程只有在编码之前有需求文档和设计文档，在以后的修改中，基本都不会去修改这2个文档。
----------------
构建活动主要是从详细设计到开发者测试，也就是程序员的工作，从设计到编码实现，到最后的自测试。
P7：“构建活动是唯一一项确保会完成的工作”
因为时间原因，需求可能是临时的，测试可能是不充分的，但是代码必须编码完成。
——以前有个培训，排名程序员的各项条件，我把诚实放到后面了，不是它不重要，而是没有办法去不诚实，跟卖商品不一样，有没有实现需求，靠嘴说谎马上就要露馅。
第二章
“隐喻的重要性。”
“使用隐喻的方法叫建模。比如分子运动理论是撞球，光的波粒二象性。”
“编程最大的调整是问题概念化，编程中很多错误是概念性的错误。”——个人认为，不应该是编程中，开始编程基本概念已经确定了，而是在前三步（定义问题，需求分析，规划构建）
“把软件的构建过程比作房屋的建设过程，移动承重墙肯定比移动隔墙成本低，软件的结构改变也根本比周边功能改动成本高。”
第三章
“准备工作的中心目标是减低风险。”
“建设大厦和搭建狗舍的前期准备肯定不一样。”
“测试不能测试出‘设计了一个错误的产品’，解决缺陷要在构建活动之前完成”
准备工作不周全的原因“
1、绝大多数开发人员没有需求、产品方面的经验和训练。
2、程序员无法抵御‘尽快开始编码’的欲望。
3、管理者对准备工作的重要性不理解。
--------------------
——对2深有体会，每次总是喜欢写个大致的详细设计，然后立刻投入编码，不过似乎只有在编码中才能更好的去构想细节，如果不编码那么脑袋里面就没有具体的印象，可能是没有使用伪代码编程的习惯，在后面的章节里面有伪代码编程的例子。
这也同样导致了我宁愿一个人加班完成工作，也不原因和别人合作完成一个程序。
不过在实际中，可能是我的团队人数都很少，一个人的效率要比几个人合作高的多。而且就算是分开每人维护一个模块，接口的调试都会花去很多时间。如果2个模块是自己一个人负责的，接口的调试很快就通过了。这或许也是最早设计报文格式的时候不周全导致的。
-------------------
“有时候用户一开始不完全确定自己想要什么，找出他们真正想要的，比做一个错误的东西再修正要好多了。”
没有直接面对客户，也没有直接的感觉，但是客户经常会提出永远都用不到还必须要有的功能。
“需求、架构、构建，缺陷越靠前，修改的成本越大。”
------------------
“我们最好立即编码，后面有很多调试要做。”和“我们没有为测试安排太多时间，因为将来不会发现太多的缺陷。”
相对而言，第二个比第一个好。
-----------------
“迭代法开发比序列开发节约成本”
迭代法就是随着项目的进展，开始检查并返工，再进行下一步的开发。
序列法是开发完成后检查并返工。
-----------------
“问题定义只是定义了问题是什么，而不涉及解决方案。”
“问题定义要用顾客的语言来书写，而不是用计算机的专业术语来叙述。”
‘我们的出口带宽总是跑满’，‘我们需要优化缓存系统，让出口带宽不要跑满’
明显前一个是问题，而后一个不像问题，倒像一个解决方案了。
----------------
“明确需求有助于用户驾驭系统功能，有助于避免程序员之间的争论”
——感觉很多程序做出来，发现需求理解的不一样，往往研发之间无关紧要的就糊过去了，最多的争论在于研发和测试对它的不同理解。
“客户经常改动需求，IBM的统计平均开发过程中，需求会有25%的改动。”
“客户往往喜欢拍脑门，用成本和进度可以提醒他们。”
——哈
P42针对功能需求有疑问，这么详细的外部接口，包括握手协议，通信协议到底是属于需求还是属于详细设计？感觉不应该是需求层的啊。
P46数据设计也一样的疑问，不过里面提到的，使用什么数据结构或算法要写出为什么这么用的好处，便于让程序员洞察构架师的思想。
“数据通常只有一个子程序或一个类之间访问”
“程序员会处于专业自豪感，对自己编写的类做过度工程”
——的确是事实啊，但是如果有时间的话，难道不好吗？
“架构应该描述所有主要决策的动机，而不是向来如此”
“优秀的架构很大程度上与机器和编程语言无关，但是也不能忽视环境。独立于环境的好处是避免过度架构。”
第四章
构架决策：
选择编程语言
编程约定（代码规范和风格、性能or稳定）
团队工作（代码管理cvs，如何分工）
质量保证（先写测试用例，评审）
工具（代码管理工具、编译工具）
本文出自 “飞翔正义的博客” 博客，请务必保留此出处http://xzq2000.blog.51cto.com/2487359/1767389
原文地址：http://xzq2000.blog.51cto.com/2487359/1767389
