1488_人月神话阅读笔记_胸有成竹

有这么好的口碑，无需怀疑，这本书肯定是一本好书。但是由于语言的差异，可能我目前看的这一本中文译本或许少了很多原有的意思。我们选择是吃快餐还是吃精品菜，有时候需要忍受中间的收益差异。不过，看下来这本书的原著版本还是有必要去重新阅读一下的。

开篇的标题是胸有成竹，但是从内容看是没有什么这方面的体现的。我觉得或许为了保持章节标题的一致性，勉强凑了一些中国式的词语来说明。从本意上来看，章节的标题是发号施令。而从内容看，主要是谈一些经验数据。

实践是最好的老师，但是笨蛋则只看经验。其实，这里有一个类似的表达，不能够一业不专也不能够只专一业。其实，这个引入语跟章节的内容是契合的，整个章节的谈论点其实就是经验数据。

计划时间在现实执行中出现很大的偏差，除了预估技术的不准确之外其实也有很多外部影响的因素。计划、文档、测试、集成以及培训等。其实，这里面的一些工作也可以去进行粗略的预估保证计划的准确性。我真正看见的其实是会议、假期、高优先级等对工作的影响。另外，复杂度的不同对于代码生产效率来说也有很大的影响。

这里的统计数据中得出来的结论是开发多少条指令需要多少时间，其实一个项目运用多少条指令这个也是难于评估的。

由于看完了全篇后才进行的笔记梳理，这里面的一些观点我在前面的条目中提及了。有一个没有提及的则是最后的这一个标注：那就是交互的接口数量有时候也会影响开发的效率，其实这样的交互不仅仅是上面说的系统，也包括人员的交流。或许，把部分功能集中化、模块化是减少这样因素的很好的方法。

这里给出了几个效率相关的数据，这几个数据可能无法直接套用，但是类似的评估方法是可以参考的。在实际的操作中，我们应该尝试去积累自己的数据，避开开篇引言中提到的笨蛋行为。

开发语言对于开发效率的影响是巨大的，现在我接触的汽车电子软件开发中基于模型的开发模式，也就是MBD模式算是一个很典型的例子。但是，在这样的效率模式诱惑前我们也得冷静分析权衡，毕竟这样的开发可能会有更高的资源消耗以及较低的优化水平。如果精研一款产品，或许这个只能够作为中间的阶段出现。