转载

《代码大全》读书笔记-构建的前期

如上图所示是软件工程的生命周期或者是软件中某个迭代生命周期。构建活动一般滴被认为是包括 详细设计 、 编码调试 、测试这些活动的集合。当然这张图只是一个简单大概的示例而已，实际软件开发过程中的会涉及到更多的活动以及更多的参与者，并且每个活着的参与者不止是只有一个。比如测试的步骤细分来说包含了单元测试、系统测试、集成、集成测试等步骤；规划构建的活动可能是由项目经理、产品经理、项目主管等多个参与者共同决议的。

构建的几个先决条件

整个软件的生命周期可以看做是由各种活动以及活动参与者构成的食物链，链下游的活动和参与者会受到链上游的活动和参与者影响，每一级的参与者都会把上一级的任务具体化、细化、消化，以供给下一个参与者对应的活动。从食物链的角度看，食物链底端的参与者吃了受污染的食物那么势必是会影响到食物链上端的参与者，构建活动也是类似的。如果构建活动的上游包括问题提出、需求分析、架构设计相关的活动除了差错那么到了构建活动纠正这些差错的代价就会大得多了，比如需求出现了问题，可能导致下游的架构设计、详细设计、编码调试、测试等一系列活动的变更和调整，需要花费更多的时间、人力去做这个调整，比起在需求分析活动中纠正这个错误，到了构建活动发现这个错误来说这个问题就显得相对的致命了，所以这些构建活动的前期准备需要被认真加以对待的。

构建前期的活动包含了 问题的定义 、 需求分析 、 构建设计 ，下面分别谈论这些活动所需要的先决条件

问题的定义的先决条件

何为问题的定义，就是对要解决的问题作出清除的陈述，有以下几个原则需要被遵守

问题的定义应该使用客户的语言来书写
最好的解决方案未必是一个计算机程序
例外的情况：解决的问题本身即是计算机有关的问题：编译时间、BUG，这种情况是可以使用计算机语言描述的
未能定义问题的后果：浪费了大量的时间去解决错误的问题，这是双重处罚，因为你为没解决问题

为什么需要遵循以上这些原则呢？还得从实际的软件活动中来看的，比如我在开发过程中遇到一个问题是：Android平台详情页中显示长图的效果比较模糊，这是因为Android平台对图片渲染使用的内存做了限制，长图或者相对比较大的图会被压缩为比较小的图片导致清晰度降低了很多。如果从技术角度看待这个问题，这个问题就会被描述为：“Android平台的长图显示过于模糊，开发人员需要对长图做优化”。前半句是问题描述、后半句是对应问题的解决方案，这是一个反面的例子，因为不止描述了问题，还包含了问题的解决方案，其实这个问题出现的概率是比较小的，可以通过运营手段来处理这个内容，比如长图分割为多图显示、带有图文的长图分解为图文重新排版，这就可以解决该问题了。所以精确不带方案的提出问题的意义其实是十分重大的，可以重新从多角度看待该问题，最终提出合理的解决方案，反之不严格的问题定义限制了方向，导致了最终问题的解决出现偏差。

需求的先决条件

为什么

确保是用户而不是程序猿驾驭系统的功能，不需要猜测用户、客户想要什么
有助于避免争论，可以查看书面需求，以解决分歧
重视需求有助于减少表层开发之后的系统变更

在上面的 构建的几个先决条件 也提到了这一点

怎么做

需求变更是客观存在的事实，25%的变革导致的返工占到总量的70%-85%，处理需求的变革可以遵循的一些原则

核对表评估需求的质量，这是量化的标准
确保需求变更的代价、成本（需求变更会影响到需求-设计-编码-测试等相关的活动和用户文档）评估变更的待机是必要的，哪怕是看上去微不足道的变更
变更控制程序（你知道自己的需求在特定的时候处理变更，客户知道你打算处理他们的提议）
- 设定需求变更的优先级
- 控制需求变更
堤防大量的变更请求（表明需求、架构或者上层设计做的不够好，从而无法有效的支持构建活动）
警惕官僚主义，医药害怕官僚主义而排斥有效的变更控制，在已有的计划上引入了糟糕的变更控制会让变更堆积如山，这种变更是具有破坏性的，体现在以下几个方面
- 项目状态的能见度
- 长期的可预见性
- 项目计划
- 分享管理
- 项目管理
成组的处理变更请求
- 记录下来，不管它实现起来有多容易，直到你有时间去处理它
- 把它当做整体来看待，从中最有价值的变更加以实施
使用能适应变更的开发方法，合适的增量集成策略，功能导向的集成，其实目前在移动或者后端的开发框架总都有广泛的使用到的
- 先完成 框架、容器层 以及 底层共享组件
- 然后根据不同的功能完成中间的业务功能，实现分批交互