代码改变世界

《人月神话》读书笔记(2)-week3

2018-03-21 20:15  ccj1998  阅读(181)  评论(3编辑  收藏  举报

为了确保团队中的每个人都能保持系统概念上的完整性,关于项目的书面规格说明是必不可少的。手册要描绘用户可见的一切,但不应支配实现的过程。光有规格说明也是不够的,会议也是必要的。书中提到的周例会会迅捷地给出一些问题的决策,但一些堆积的小问题会逐渐影响工作进度,这时候就应召开级别更高的月会或年会。

书中举例了巴比伦塔建造失败的例子来说明团队中交流的重要性。说明手册固然是个好东西,但是随着工程进度的推进难免会有一些新的想法,工作手册的及时更新就十分重要。此外,由于查看更新是一件非常麻烦的事情,故对变更的简单总结也很重要。对于较大型的项目,技术主管和产品负责人往往不是同一个人。在产品负责人作为总指挥,技术主管充当其左右手的模式下,声明技术主管的技术权威是非常重要的。当然,对小型团队,技术主管做总指挥,产品负责人做左右手也是不错的选择。巴比伦塔建造的失败,就是交流和组织失败的结果。

系统编程需要多长的时间?这是一个重要但难以估计的问题。一个非常重要的事实是:

工作量=常数*指令的数量^1.5

即对单个程序员来说,程序的规模越大,程序员的代码生产率就越低。所以在考虑系统编程时间耗费的时候,应考虑规模与时间的指数关系,而不是线性关系,这一点至关重要。另外书中指出,使用适当的高级语言,编程的生产率可以提高5倍。

    作为项目经理,规模控制是必须的一部分。对于程序所耗的内存,应衡量它带来的易用性和性能是否值得。编程人员应学会技巧和战略上的突破来降低算法的复杂度。