#构建之法读书笔记(第3,4章)
1. 个人能力的衡量与发展
第三版构建之法对应3.1 节。
一点思考: 在对话中，讨论到软件工程师的能力和篮球运动员的能力的数据统计。 对于篮球运动员来说，有出场数、首发数、分钟、命中率……等。 对于软件开发工程师来说，有计划、开发、报告……等。 但是我觉得需要注意以下的区别:
- 篮球运动员的数据由其他人统计，程序员的数据，需要自己统计。
- 篮球运动员的统计数据比较客观，程序员在做自己统计的时候客观会比较难一些。
- 篮球运动员的统计比较容易制定标准(是否算进球，是2分还是3分)，程序员的标准相对比较灵活(用不太好的方式，快速解决问题HardCode;用较好的方式，考虑作为参数，在解决问题上花费了比较多的时间配置文件。如何衡量)。
- 篮球运动有裁判，具体的规则很明确。写程序虽然也有代码整洁之道，KISS，DRY原则，但没有裁判。
2.稳定交付
第三版构建之法对应3.1节, 代码按时交付。
一点思考: 在工作中，任务大致分为这几种:
- 调研性质。公司之前没有此方面的技术积累，需要进行调研。
- 之前已经有人做过了，有经验可以参考。
- 之前没有其他公司做过，可以参考的资料很少。
- 工程性质。公司已经有了很多的经验积累，主要的工作量就是写代码和测试了。
- 维护性质。公司有一些老代码，老项目还在运行，用户反馈问题，需要维护。 不同的任务的时间估计会有很大的不同，时间预估分析的时候，是否考虑过这个问题。
3.思维误区
第三版构建之法对应于3.2节。
一点思考:
关于过早优化 对于快速变化的部分，就像给快速发育的小朋友买衣服和鞋子。
- 买的刚刚合适，小朋友长得很快，可能很快就要买新的了。
- 买的太大了，小朋友过了很久还是显得有点大，衣服都要穿破了，还是不合适，显得大，优点浪费。 所以这个部分需要经验丰富的人做指导会更好一些;如果没有经验丰富的人，实行敏捷开发，小步快跑。
过早扩大化/泛化 所有优秀的架构和平台，几乎都是演化而来，直接设计出来的几乎没有。不要在一开始就想着平台化，框架化。 对于软件开发来说，第一个目标是要先做到基本功能可用。在写代码的时候注意模块化，函数功能的单一化,为以后架构的修改做准备。 对于架构，要逐步演化，小步优化，要不等到最后可能积重难返，只能重来。
4.全才，专才。
第三版构建之法对应于3.3节。
一点思考: 前段时间网上有个词很火—– “全栈工程师”。 我的理解是这样，闻道有先后，术业有专攻,不太建议适合做全栈。 有人会说，项目有需要怎么办呢？我想到的解决方案是:如果公司遇到了一个问题，公司里没有人在这个领域比较熟悉，可以请一个在此领域比较熟悉的人作为顾问或者兼职，将他的技能快速复制到自己的能力里，快速完成任务。 举例:每一种框架都在发明属于自己的编程语言。 很多框架在细小的地方，一个配置文件不对，会导致整个运行不起来，参考OpenStack。这个时候最快的解决方法是找个对OpenStack特别熟悉的工程师，来讲解对应的地方。
5.代码复审
第三版构建之法对应于4.4节。
一点思考: 在公司经历过一个时长一天的代码复审。审核员:CTO,架构设计者。被审核:我，代码实现者。 CTO和我花了一天的时间，对代码从头到尾进行了一次审核。在编写代码过程中，我对架构的设计进行了适当的简化。审核的过程中，我对这件事情向CTO进行了说明。 所以我们在审核代码的过程中，对原有设计中针对以前设计的代码进行了优化和删除。对现有的架构设计的代码，进行了整理和完善。 整个过程中我的收获:
- 学习到了CTO在设计这个程序的过程中，对于每个问题是怎么思考的。
- 代码规范、程序结构怎么样可以看起来更清晰。
- 结构的设计需要遵循的规则，方便以后进行扩展和修改。
6.是否保存老代码
第三版构建之法对应于4.4.3节。
一点思考: 关于在代码中保存不用的老代码，我目前就是这样的作法，公司也采用了这样的方案。 主要原因是提交代码过了几个版本以后，就不太容易记住老代码在哪个版本做了删除，之前的版本有。 如果是对于3—5个地方，都有老代码，在几次提交中进行的删除，随着提交的进行，其对应关系就更难找了。 如果有更好的办法来进行老代码的恢复，我会采用。要不可能还是注释掉是最容易的办法。
7.结对编程。
第三版构建之法对应于4.5节。 一点思考: 关于结对编程:结对编程最好是两个水平差不多的程序员合作，基础是保证每个人即使独立完成也没有什么问题,否则还是传帮带好一些。 代码复审的化:至少需要有一个经验比较丰富的工程师,否则代码评审的意义不大。
个人观点，欢迎讨论、批评指正。