代码大全2（读书笔记14）

151、在与项目规模的关系方面，生产率的情况与软件质量很相似。对于小项目，影响生产率的最大因素莫过于单个程序员的技巧。随着项目规模和团队规模的增大，组织方式对生产率的影响也将随之增大。

 

152、小项目的生产率会比大项目高出2至3倍，并且最小的项目和最大的项目的生产率差距可能达到5到10倍之巨。

 

153、项目越大，复杂度也越大，也就越要求有意识地去关注方法论。建造摩天大楼的方法和搭狗窝的方法是不一样的。不同规模的软件项目也是如此。对于大项目来说，如果不有意识地去选择方法论，就将无法完成任务。成功的项目计划人员会明确为大型项目选择合适的策略。

 

154、项目落后了怎么办

缩减项目范围这一强大的技术常会人们所忽略。如果你去掉了一项特性，你就除支了相应的设计、编码、测试、和编写文档工作。你也删除了该特性和其他特性之间的接口。

　　当你最初做产品计划的时候，要把产品的功能划分成“必须有”、“有了更好”和“可选择”三类。如果进度落后了，那么就调整“可选择”和“有了更好”的优先级，并扔掉那些最不重要的功能。

    如果做不到完整地去掉某项特征，那么还可以提供一个该功能的简化版本。你可以按时地交付一个尚未进行性能高校的版本。你也可以提供一个版本，其中最不重要功能的实现相当粗略。你可以放松对速度的要求，因为提供一个速度较慢的版本会容易很多。你也可以放松对空间的要求，因为提供一个占用更多内存的版本会容易得多。

 

155、要求在任何领域里的所有微小细节上都步调一致，其收效恐怕无法弥补由此而对士气靠成的影响。如果你发现有人“不分青红皂白地使用goto或全局变量”、程序风格的可读性差、或者有其他影响整个项目的实践行为，那么就得为了提高代码质量而不怕一些摩擦了。如果你的程序员是负责任的，那么这很少会成为问题。最大的斗争往往只在编码猫鼠同乳一些细微差异上，你完全可以置身事外----只要这对项目没有损失。

 

156、有关程序员编程生产力的个体差异的最早一项研究是由Sackman\Erikson和Grant在20世纪60年代末期做出的。他们对平均工作经验为7年的专业程序员进行了调查，发现最好和最差程序员的初始编码用时比例为20：1，调试用时比例为25：1，程序规模比例为5：1，程序执行速度比便为10：1.

   尽管像25：1这样具体的比例并一是特别有意义，但是像“程序员之间有着数量级的差异”这样更一般的陈述的意义却是很明确的，并且已经被其他许多针对专业程序员的研究所证实。

 

 

157、物理环境对生产率有着巨大的影响。DeMarco和Lister向来自35个组织的166名程序员询问了其亿处的物理环境的质量。大多数雇员都对其工作环境感不到满。在此后举行的一次编程竞赛中，排名在前25%的程序员都具有宽敞、安静、更为私密的办公室，并且较少受到其他人员和电话的干扰。

 

158、在增量集成中，你一小块一小块地编写并测试你的程序，然后一次一块地将它拼接起来。在这种“一次一块”的集成方式中，遵循以下步骤。

    1、开发一个小的系统功能部件。它可能是最小的功能部件、最难的部件、关键部件、或者以上的某种组合。对它彻底地测试并调试。将它作为骨架，稍后附着肌肉、神经、皮肤等系统的其余部件。

    2、设计、编码、测试、调试某个类。

    3、将这个新类集成到系统骨架上。测试并调试“骨架和新类的结合体”。在进一步添加任何新类之前，确保该结合体能工作。如果做完了剩余的所有工作，就回到步骤2开始重复这一过程。

    偶尔，你也可能想要集成某些“大于单个类的单元”。比如，如果某个组件经过彻底测试，其中每个类经过了迷你集成，那么你可以集成这整个组件，并仍然使用增量集成的方式。随着你不断地添加部件，系统增大，却是增加；就像雪球从山上滚下来时体积和动量不断增大一样。

 

159、风险导向的集成

　　风险导向的集成也称为“困难部件优先集成法”。与三明治集成类似，它也试图避免“纯粹的自顶向下集成”或“纯粹的自底向上集成”的固有问题。巧合的是，它也趋向于先集成顶层类和底层类，将中间层类留后处理。然而，其动机不同。

　　在风险导向的集成中，需要先鉴别各个类对应的风险级别。确定哪些部件实现起来是最有挑战的，然后先实现这些部件。经验表明顶层的接口是有风险的，因此它通常位于风险清单的顶部。系统接口，通常位于继承体系的底层，也是有风险的，因此它也在风险清单的顶部。另外，你或许知道中间层有一些具有挑战的类。可能是某个实现了未被透彻理解的算法的类，或者某个具有雄心勃勃的性能目标的类。这样的类也可标为“高风险”，应及早集成。

　　余下的代码就是那些比较轻松的东西，可以等到以后再下手。其中的某些最终可能比你想象的要困难，但这是不可避免的。

 

160、格式化的基本原理指出，好的布局凸现程序的逻辑结构。

     使代码看起来有条理的最大意义莫过于展示出代码的结构。如果有某种方法能够更好地给出代码结构，而另一种方法可以使代码更悦目，那么还是选择前者为好。