案头有一本《代码大全》，断断续续看完了关心的许多章节，每次阅读都受益匪浅，不过读完便是倒头便睡，没有深刻的内化。 我很喜欢这本书，职业生涯需要这样一本圣经，于是开坑代码大全的读书笔记。 除了记录c2ee中启发之处外，顺便写上自己的读书笔记。

欢迎进入软件构建的世界。全书共计7个部分，35个章节。读书方式为随机阅读，阅读前会预先提问有哪些想搞清楚的问题，记录单个章节阅读日和阅读时长，并将核心内容抄写然后评注自己的观点。

需求评审

代码大全第3章，三思而后行，前期准备。

有一些程序员确实知道如何进行前期工作，但是他们并没有做，因为他们不能够抵抗尽快开始编码的欲望，只需要做几个大项目，你就能体会到，事先做好计划能避免很多压力，让自己的经验来引导你吧。

程序员不做准备工作的最后一个原因是管理者对那些花时间进行构建活动的前期准备的程序员的冷漠，已经到了人神共愤的程度。

在一个项目开始前，起码要做到：首先要把逻辑说出来，然后再把草图画出来。然后把数据拿出来再看一看。

整个需求的流程是：

1. 需求到架构
2. 详细设计
3. 构建
4. 质量保证和系统测试

如何去面对需求变更呢？

1. 首先确保每一个人都知道需求变更的代价
2. 使用需求核对表来提供评估你的需求的质量
3. 建立一套变更控制程序
4. 使用能适应变更的开发方法
5. 放弃这个项目
6. 注意项目的商业案例

需求核对表：

• 是否详细定义了系统的全部输入，包括来源精度，取值范围，出现频率等。
• 是否定义了系统的全部输出，包括目的地精度，取值范围，出现频率格式等。
• 是否定义了详细的所有的输出格式？
• 是否定义了所有硬件及软件的外部接口？
• 是否定义了全部外部通信接口，包括握手协议，纠错协议，通信协议等等。
• 是否列出了用户想要做的全部事情？
• 是否定义了每个任务所有的数据以及每个任务得到的数据。

如何把握需求的质量？

• 需求是用用户的语言书写的吗？用户也这么认为吗？
• 每条需求都不与其他需求冲突吗？
• 是否详细定义了相互竞争的特性之间的权衡，例如见状，性与近正确性之间的权衡。
• 是否避免在需求中的规定方案？
• 需求是否足够清晰，及时转交给一个独立的小组去构建，他们也能够理解吗？开发者也这么想吗？
• 对于在开始开发之前无法获得的信息，是否详细描述了信息不完全的区域。
• 需求的完备度是否能达到这种程度，如果产品满足所有需求，那么他就是可以接受的。

系统考虑

Part6.Chap27 20190727 16min 20190728 20min

习惯开发小项目，面对大型项目的时候将会彻底失控。除了规模化的思考能力缺乏外，无形的成本也会成为主要的坑。甚至可能在项目构建过程中不断迷失。 软件构建中的系统考虑可以保障把握全局，本章节讲述程序规模对构建的影响。

Q1. 如何看待软件构建中的无形沟通成本

曾简单的读过《人月神话》，是包永红老师塞给我的。里面提到过沟通成本问题，随着沟通对象的增多，消息的扩散成本指数级的提升。 改善交流效率的最佳方式就是采用正式的文档。 我们公司目前习惯使用石墨文档交流，虽然有统一的工具，但是重要的是文档的结构安排和表述是否清晰。而且文档还需要考虑到版本管理和是否可以回溯。 文档是会遗失的，即使正在交流用的文档也会有找不到情况。 所以需要将文档放到一个大家都能想看时候就立马想到去哪看的地方，且不定期的在沟通群内重新发布。

总结就是，沟通成本越大，越需要重视文档为唯一信息源。切忌通讯工具交流一顿，没有重述到文档上。

Q2. 代码规模愈大，需求和犯错的可能就更多，如何控制错误率

1. 从项目产出率方面讲。客观规律是无法避免的，项目规模增加过程中，即使小心翼翼的构建每一个函数，也无法避免软件构建过程中的错误。 项目规模和生产率和投入人员非正比关系。 小型团队的生产率要比大型团队高出39%，一般小项目两个人，大项目三个人。
2. 从项目规模方面讲。小项目重构建，大项目重开发。
3. 区分什么是程序、什么是产品、什么是系统、什么是系统产品。程序最初做成后，只是给开发者本人使用的，没有考虑到交给别人。
4. 方法论的选择上。是选择敏捷开发还是计划驱动，并非使用所有情况，但是可以以小的方法论为起点逐步扩大到大型项目中去使用。实践中出真知，不是生搬硬套。

Part6.Chap27 20190728 20min

我们的一个中级工程师离职后，留下来一份代码，源码中存在着一个致命的bug会随着数据量的增加暴露出来。在问题终于暴露后，另一个工程师不得不深入研究源码，然后极度痛苦的修正问题。

这背后其实就是管理构建的问题。鼓励良好的编码实践，保证团队风格统一，就是为了至少做到代码可以薪火相传。设定标准，设置验收门槛是需要在构建项目中有意识的去沉淀的。

c2ee中对于编码实践技术有如下建议参考：

1. 给项目的每一部分分派两个人。两个人互为backup。至少互相认可代码是可维护的。
2. 逐行复查代码。Code Review环节不仅仅是验收，还是审核者和被审核互动学习的过程。在这个过程中，随着时间推移，可以得出小组的编码标准。
3. 要求代码签名。确定代码验收后，验收者必须给代码签字，表明其可用。
4. 安排一些好的代码示例供人参考。精准传达怎样是良好的风格，最好还是拿出真正的好菜来品尝。照葫芦画瓢是有效的学习方式。
5. 强调代码是公有财产。实质上这点建议背后是想阻止程序员将为公司的产出代码没有公开。你可不想你的同事离职后，就丢失了一些项目吧。最好的解决办法还是鼓励默认使用github类似工具。
6. 奖励好代码。
7. 一份简单的标准。简单前提下的标准，具备标准的特性，也能保证自由发挥。任何事情不要过度约束是有益的。