Code Complete学习笔记--Chapter3总结

第三章主要论述了前期准备的重要性，重要组成部分以及每个部分的关键举措。前期准备是项目构建的基础，是软件全流程质量管理的重要组成部分。前期准备包括了4个部分：定义问题、明确需求和架构设计，以下是这一章的框架：

• 3.1 前期准备的重要性
• 3.2 确定要开发什么类型的软件
• 3.3 定义问题的先觉条件
• 3.4 需求的先决条件
• 3.5 架构的先决条件
• 3.6 前期准备所花费的时间

3.1 前期准备的重要性

前期准备是构建高质量软件的重要前提，完善的软件质量管理应当在软件构建的前、中、后各个阶段都有相应的质量保障举措，其中，软件构件中的保障举措是完善的构建规范、软件构建后的保障举措是系统测试，但是这两个阶段的举措都无法保障软件在设计和定位上的缺陷，而这部分的缺陷就要依靠前期准备来做有效的管理。

作者还为程序员如何说服领导重视软件的前期准备工作分别就逻辑、类比和数据三个方面进行了阐述，也是真的很懂大家了（其实不做准备锅不在程序员这儿）。

3.2 确定要开发什么类型的软件

这一节作者想要破除一个误解，即敏捷式开发并不需要花费重点关注前期准备。

软件可以被分为商业系统、任务攸关系统以及嵌入式生命攸关系统，我个人觉得这个分类方法重点想要表达的是软件可以依据构建复杂度进行分级（这主要为后续敏捷式开发和瀑布式开发的区别来做铺垫），其中复杂度低的系统更推荐敏捷式开发，而复杂度高的系统推荐瀑布式开发。而作者从数据的角度强调了前期准备对于敏捷式开发的项目成本也有极大的优化，而且这个优化的力度也不比瀑布式开发差多少。

这一章的结尾作者还教了我们如何选择这两种方法：

	瀑布式开发	敏捷式开发
需求	需求相当稳定和明确	需求没有得到充分理解或者还不够稳定
设计	设计简单，容易理解	设计复杂并且有挑战性（就是会有返工的风险）
开发	开发团队熟悉相应领域	开发团队不熟悉相应应用程序领域
变更	后期变更成本高	后期变更成本低

3.3 定义问题的先觉条件

这是前期准备的第一个重要环节，即明确这个系统到底要解决什么问题，作为需求方能不能非常清晰的说明。这里要注意问题定义一定要使用用户的语言，并且应该从用户的角度去描述问题，它不应该用计算机术语来表达（因为最好的解决办法未必是计算机程序）。

作者还强调了问题定义不清会造成的损失，即造成双重惩罚（因为后续一切的资源投入原则上都是浪费，而且最终问题还是没有得到解决，你会为这个问题的拖延支付利息）

3.4 需求的先觉条件

作者先强调了一下需求的重要性，但是我个人觉得这个倒是不用强调，在实际工作中需求肯定是会做的（这一般也是一个重要的交付件），但是花多少心思去做还真说不准。这里作者使用了一组数据来说明任何需求阶段的错误都是极其昂贵的（对于大型项目，架构阶段的修复成本是3倍、编码阶段的修复成本是5-10倍、测试阶段的修复成本是10倍、而在发布后的修复成本将会达到100-1000倍，对于小型项目发布之后也有5-10倍），而且不同于technical debt里说的利息是运维成本，需求的错误一般是无法通过交付评审的，也就是说这种debt是一个断头贷，到期不还血本无归，都不用跟你谈什么利息。

接下来，作者做了一个重要的论断：不要寄希望用户提出的需求不会变更，这只是一个美好的愿望（所以要以平常心去看待需求变更）。接下来作者引出了如何尽可能的避免用户的需求变更的方法。

• 进一步评估需求质量：这里作者给出了一个需求质量的评估清单（P40），需求分析师可以对照这个checklist来评估。
• 确保每个人都知道需求变更的代价：用客观的进度和成本去平衡用户天马行空的想法。

以及确实有了需求变更以后如何处理的方案：

• 建立一套需求变更控制程序：建立一个变更控制委员会，一来让用户知道他的需求能够被响应，二来可以通过这个程序降低变更执行的频率。
• 使用能适应变更的开发方法：推荐演进原型法，其目的是在实施的早期尽可能多的获取用户的反馈，以避免需求变更在更后续的阶段发生。其中演进交付指的是先实施一小块的需求，从用户那里获得及时的反馈，通过设计的调整再构建下一块。
• 放弃这个项目：嗯。。。虽然不太可能，但作者还是鼓励我们可以真的去思考一下取消之后我们到底会承担什么成本。以及让上层放弃这个项目可能的路径是什么，很多时候我们只是没有真正去想过这个方式。
• 把用户的关注点转移到商业价值（或者业务价值）上来：有些需求作为功能特色或者用户想证明自己的创新思维看起来不错，但当评估增加的商业或业务价值时，就会觉得糟糕透了。把用户从自我当中拉到商业世界中来。

3.5 架构的先觉条件

架构一是站在完整性和内部相关性这两个角度对于软件进行的详细定义，在完整性方面，架构定义了软件的边界，在相关性方面，架构定义了子系统间的交互关系；二是定义了软件整体层面和子系统层面的设计约束。

优秀的架构设计会考虑20个关键元素：

• 程序的组织：以概括的形式对系统做一个综述，定义系统主要的组件（组件可以事一个单独的类，也可以是一组类组成的子系统，需求中的每一个功能都要至少有一个组件去覆盖它），应该明确定义各个组件的责任；应该明确定义每个组件的通信规则。
• 主要的类：类的职责与交互；类的继承体系，状态转换以及对象持久化；曾经考虑过的类设计方案，以及选择当前组织结构的理由（这个建议真的很受益，他会让后续程序员瞬间跟上你的思路）。
• 数据设计：系统所用到的主要文件和数据表设计；定义所用数据库的高层数据结构和内容并给出解释。
• 业务规则：如果有的架构设计是专门针对某条（或几条）业务规则的，请注明。
• 用户界面设计：Web页面格式，GUI以及命令行接口等主要元素。
• 资源管理：描述一份管理稀缺资源的计划（包括数据库连接、线程等）；估算正常情况和极端情况下的资源使用量。
• 安全性：比如缓冲区的处理方法、不可信数据的处理方法、加密、错误消息细致程度等等
• 性能：定义性能目标、提供性能估计数据，以及估计的前提假设和达不到目标的潜在风险。
• 可伸缩性：即满足未来系统增长的能力，如用户数量、服务器数量、网络节点数量等增加带来的问题。
• 互操作性：与外部软硬件共享资源的共享方案。
• 国际化/本地化：字符集转换的问题
• 输入/输出：定义读取和输出策略
• 错误处理：作者定义了8个需要考虑的问题（p46）
• 容错性：定义所期望的容错种类以及策略。
• 架构可行性：对于性能、资源或者技术实现等问题要全面评估可行性，最好列出这些问题调研的方法和历程。
• 过度工程：即系统的健壮性（检测到错误后还能继续运行的能力）
• 购买决策：采购还是自建，主要考虑投入产出。
• 复用决策：对于复用组件进行说明
• 变更策略：处理变更的策略，以及处理延期的策略
• 架构总体质量：架构应当是带有少量特殊情况的精炼且完整的概念体系。

优秀的架构应该长什么样：

• 架构目标应当能够阐述清楚：比如有的系统偏重性能、有的偏重可变性、有的偏重安全性。
• 架构应当描述所有主要决策的动机：对于每一个架构设计都要避免经验主义的影响。
• 优秀的软件架构在很大程度上与机器和编程语言无关：尽可能的独立于环境去设计架构，这样就能抵抗对系统进行过度架构。
• 架构既不应该对系统欠描述也不应该对系统过度描述：欠描述导致构建缺乏指引，过度描述大部分会浪费时间，因为这是后续设计要干的事。同时要避免在某一个部分钻的太深。
• 架构应当明确地指出有风险的区域：有什么风险，为什么有风险，架构设计上已经做了哪些准备去应对这些风险。
• 架构应当包含多个视角：比如从程序员视角要更容易理解，从测试工程师视角要更容易暴露隐藏的错误等。

最后作者给出了架构设计的一份checklist（p51）。

3.6 前期准备所花的时间

前期准备工作一般会花费10%-20%的工作量以及20%-30%的时间。如果需求非常不稳定，建议将需求分析作为一个独立的项目来做，在完成需求分析以后再预估后续的时间。对于架构的设计也一样，如果是一种以前从没使用过的软件，请留出更多的时间去考虑新领域中进行设计时的不确定性。

总之，前期准备的质量是后续构建成功的必要条件。