《代码大全2》之---系统考虑

第三部分 系统考虑

本文为《代码大全2》的读书笔记，版权归代码大全所有。^_^

本文基址：http://blog.csdn.net/cugxueyu/archive/2007/12/10/1926790.aspx

 

 第27章 程序规模对构建的影响

 第28章 管理构建

 第29章 集成

 第30章 编程工具

 

第27章 程序规模对构建的影响

 

 一、  交流和规模

  ※ 项目组的成员越多，交流的路径也就越多，花在交流上的时间也就越多，因交流而出错的机会也就越大。更大的项目可以采取一些组织技术来改善交流效率，或者有意识地对其加以限制。

  ※ 改善交流效率的常用方法是采用正式的文档（文本、图形、电子格式或打印格式）。

 

 二、  项目规模的范围

  ※ 评估项目规模的方法之一就是考虑项目团队的规模。  

 三、  项目规模对错误的影响

  ※ 项目的规模既会影响错误的数量，也会影响错误的类型。

  ※ 随着项目规模的不断增大，通常更大一部分的错误要归咎于需求和设计。  

  ※ 在小项目中，构建错误大约占所有被发现错误的75%，方法论对于代码质量的影响不大，对应用程序质量影响最大的通常是编写软件的各个开发者的技能。

  ※ 在更大的项目中，构建错误占错误总数的比例逐渐下降到50%，而需求错误和架构设计的错误则填补了其中的差额。

 

 四、  项目规模对生产率的影响

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

  ※ 生产率主要取决于你所从事的软件类型、人员素质、编程语言、方法论、产品复杂度、编程环境、工具支持、计算“代码行数”方法等等很多因素。  

 五、  项目规模对开发活动的影响

  ※ 在一个项目团队中，对项目的成败影响最大的因素是组织结构。

  1、活动比例和项目规模

  ※ 项目越大，所需要的正式交流越多，所需进行的各种活动的种类也会急剧变化。 

  注释：小项目以构建活动为主，更大的项目需要做更多的构架、集成工作和系统测试工作才能成功。  

  2、程序、产品、系统和系统产品

  3、方法论和规模  

 

第28章 管理构建(Managing Construction)

 

一、鼓励良好的编码实践

 ※ 代码是构建活动最主要的产出，因此，管理构建中的一个关键问题就是“如何鼓励良好的编码实践”。

 ※ 如果项目中要制定标准，那么应该由一位受人尊敬的架构师来制定，而不是由管理者。

 

 1、设定标准的考虑事项

   ※ 标准有助于减少项目中随意出现的诸多分歧。

 2、鼓励良好的编码实践的技术

   ※ 良好的编码实践比呆板的编码标准更容易执行。

   ※ 指导原则：

>    给项目的每一个部分分派两个人

 ※ 结对编程

>    逐行复查代码

 ※ 复查会以一种微妙的方式来促成小组的编码标准。

>    要求代码签名

 ※ 代码管理方式，在认定代码完成之前，由Review人员签字认可。

>    安排一些好的代码示例供人参考

 ※ 优良管理中的一个重要方面就是清楚地表达你的目标（用一份清楚的样例说明了自己的质量目标）。

>    强调代码是公有财产

>    鼓励好代码

 ※ 运用你所在机构的奖励机制来激励良好的编码实践。

>    一份简单的标准

 ※ 管理者来适当阅读代码

 

二、配置管理

 ※ 软件项目是不断变化的，代码在变、设计在变、需求也在变。而且需求的变化会引起设计上的更多变化，设计上的变化又会引起代码和测试用例的更多更多的变化。

 

1、  什么是配置管理

  ※ 配置管理是“系统化地定义项目工作和处理变化，以使项目一直保持其完整性”的实践活动。

  ※ 有时也称“变更控制”，其中技术包括：评估所提交的更改、追踪更改、保留系统在不同时间点的各历史版本。

  ※ 软件配置管理（SCM）实施选项：

  1、需求变更和设计变更

   ※ 在开发过程中，你一定有很多关于如何改善系统的想法，如果每产生一个想法就实施相应的变更，你会发现自己走上了软件开发的treadmill（一系列似乎永不完结的工作）。

 

   ※ 控制设计变更的指导原则：

>    遵循某种系统化的变更控制手续

>    成组地处理变更请求

>    评估每项变更的成本

 ※ 请评估做这些修改所需要花费的时间，包括对修改代码做复查以及重新测试整个系统的时间。在评估耗时的时候还要把这一变更导致的连锁反映（需求、设计、编码、测试以及修改用户文档）的耗时考虑进去。

>    提防大量的变更请求

 ※ 如果变更的请求数量太大，就表明需求、架构和上层设计做得不够好，从而无法有效地支持构建活动。

>    成立变更控制委员会或者类似机构

>    警惕官僚主义，但也不要因为害怕官僚主义而排斥有效的变更控制

 

  2、软件代码变更

   ※ 版本控制软件（VSS、CVS、SubVersion、Clearcase、Git、StarTeam）

   ※ 代码控制的补充建议：

      1、工具版本（重新构造处‘创建软件的各个特定版本’的原样环境的能力）。

      2、机器配置（很多公司都因创建了标准的开发机器配置而受益）。

      3、备份计划（定期备份你的工作）（项目结束之后，要对该项目进行归档，把所有的东西保存下来: 源代码、编译器、工具、需求、设计、文档—重新创建该产品所需的一切事物）。

 

三、评估构建进度表

  ※ 软件项目管理是人类在21世纪面临的一项重大挑战。评估项目的规模和完成项目所需的工作量是软件项目管理中最具挑战性的方面之一。

 

  ※ 评估软件项目涉及的问题：

   1）、评估的方法：

>    使用评估软件

>    使用算法方法（CocomoII评估模型）

>    聘请外界的评估专家来评估有关项目

>    为评估举行排练会议

>    评估项目的每一部分，然后把他们加起来

>    让成员评估各自的任务，然后再把各任务的评估值加起来

>    参考以往项目的经验

>    保留以往项目的评估，查看其准确度，用它来调整新的评估。

     注释：参考书目：《快速软件开发》和《软件成本估算：COCOMOII模型方法》

 

   ※ 评估项目的好方法：

>    建立目标

  ※ 只需评估构建活动还是评估整个开发活动？只评估项目需要的工作量，还是把休假、节假日、培训和其他非项目的活动也算进去？需要什么样的评估准确度才能达到你的目标？乐观评估和悲观评估会产生截然不同的结果吗?

>    为评估留出时间，并且做出计划

  ※ 把评估活动看成“Mini Project”来操作。

>    清楚地说明软件需求

  ※ 在评估之前要先定义需求，或者计划出一个预估过程。

>    在底层细节层面进行评估

  ※ 评估要建立在对项目各项活动做出详细考查的基础之上。

>    使用若干不同的评估方法，并且比较其结果

>    定期做重新评估

 

   2）、评估构建的工作量：

     ※ 构建能给项目进度造成多大范围的影响，部分地取决于“构建”在项目中所占的比例（构建所占的比例随着项目规模的不同而变化）。

 

    ※ 对进度的影响：

> 对软件项目进度影响最大的是所开发的程序的规模。

> 其他影响软件项目工作量的因素：

 例如：集中开发VS分散开发、数据库大小、满足项目需要的文档、平台稳定性、过程成熟度、对软件工具的使用、需求开发者的经验和能力、程序员的经验和能力、团队的动力、管理的质量、重用代码数量、人员流动性、需求变更、客户关系的质量、用户对需求的参与度、客户对此类应用软件的经验、程序员对需求开发的参与度、文档量、项目目标等。

 

四、度量

  ※ 度量软件项目的根本原因：

  1、任何一种项目特征都是可以用某种方法来度量的，而且总会比根本不度量要好得多

   ※ 度量结果也许不会完全精确，度量也许很难做，而且也许需要持续地改善结果，但是它能使你对软件开发过程进行控制，而如果不度量就根本不可能控制。

   ※ 为了评价软件开发方法，你就必须对它进行度量（进行量化），类似“这种新方法看上去生产率更高”的说法是欠妥的。

 

  2、留心度量的副作用

   ※ 度量会对动机产生影响，所以要谨慎地选择哪些环节需要被度量。

 

  3、反对度量就是认为最好不要去了解项目中到底在发生什么

   ※ 通过度量，你至少打开了一扇能看到项目的这一环节的窗户。

   ※ 有用的软件开发的度量环节。

 

五、把程序员当人看

  ※ 程序员的信仰问题

>    编程语言

>    所进风格

>    大括号的摆放位置

>    所用的IDE

>    注释风格

>    效率和可读性的取舍

>    对方法的选择—例如：极限编程、Scrum、渐进交付

>    编程工具

>    命名习惯

>    对goto的使用

>    对全局变量的使用

>    度量，特别是有关生产力的度量，如每天编写的代码行数。

 

六、管理你的管理者

  ※ “管理你的管理者”意味着，你需要告诉他应该这样做而不应该那样做，其要诀在于：你要表现得使你的管理者认为他仍然在管理你。

 

第29章 集成(Integration)

  ※ 术语集成指的是一种软件开发行为，将一些独立的软件组件组合为一个完整的系统。

  ※ 构建次序同集成的关系

 

1、  集成方式的重要性

  ※ 集成在开发人员完成开发者测试之后才进行的，而且集成过程是与系统测试一道进行的，所以集成有时也被认为是一种测试行为。

  ※ 但是基于集成本身的复杂，因此应该把集成看成一项独立的行为。

 

  ※ 从周到的集成中，你能预期获得下列好处：

·      更容易诊断缺陷

·      缺陷更少

·      脚手架更少

·      花费更少的时间获得第一个能工作的产品

·      更短的整体开发进度表

·      更好的顾客关系

·      增强士气

·      增加项目完成的机会

·      更可靠地估计进度表

·      更准确的现状报告

·      改善代码质量

·      较少的文档

 

2、  集成频度-阶段式集成还是增量集成

  ※ 程序集成方式：阶段式集成和增量集成。

  ※ 阶段式集成

     遵循步骤或阶段：

     1、设计、编码、测试、调试各个类（“单元开发”）。

     2、将这些类组合为一个庞大的系统（“系统集成”）。

     3、测试并调试整个系统（“系统瓦解”）。

  ※ 增量集成

     遵循步骤或阶段：

     1、开发一个小的系统功能部件，将它作为骨架，做功能的添加。

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

     3、将这个新的类集成到系统骨架上，测试并调试“骨架和新类的结合体”。

  ※ 增量集成的益处

     1、易于定位错误

    2、及早在项目里取得系统级的成果

    3、改善对进度的监控

    4、改善客户关系

    5、更加充分地测试系统中的各个单元

    6、能在更短的开发进度计划内建造出整个系统

 

3、  增量集成的策略

  ※ 使用增量集成时，就得仔细安排计划了，大多数系统要求先集成某些组件，再集成其他组件，因此，为集成做好计划也会影响到为构建作计划。

 

  ※ 集成策略：

  1、自顶向下集成

  2、自底向上的集成

  3、三明治继承

  4、风险导向的集成

  5、功能导向的集成

  6、T-型集成

 注：像软件设计方法一样，更多的是启发而非算法，请不要像教条一样遵循前面提到的任何过程，而应该为特定项目剪裁一套独一无二的策略。

 

4、  Daily Build与冒烟测试

 ※ DailyBuild和冒烟测试都是软件集成的好方法，每天将各个源文件编译、链接并组合为一个可执行程序，然后对这个程序进行冒烟测试，即执行一种相对简单的检查。

 

 ※ Daily Build详情：

  1）、每日构建（Daily Build）

   ※ 每日构建最关键的部分是“Daily/每天”，可以把Dailybuild视为项目的脉搏。

  2）、检查失败的build

   ※ 好的build应该：

·      成功地编译所有文件、库和其他组件。

·      成功地链接所有文件、库和其他组件。

·      不包含任何“使程序无法启动，或者操作起来全凭运气”的毁灭性bug，换而言之，好的build应该能通过冒烟测试。

  3）、每天进行冒烟测试

   ※ 冒烟测试应该从头到尾地演练整个系统。

  4）、让冒烟测试与时俱进

   ※ 项目开始，冒烟测试可能仅仅测试一些简单的事情，但随着系统的开发，冒烟测试应该变得更加彻底。

  5）、将DailyBuild和冒烟测试自动化

  6）、成立Build小组（例如：WindowsNT首次发布）

  7）、仅当有意义时，才将修订加入Build中

   ※ 当开发人员有一套具有一致性的状态的代码时，再进行集成或Build。

  8）、但是别等太久才将修订加入进来

   ※ 如果某个开发人员连续两三天都不Checkin他做的改动，那么这名开发人员所做的工作就是由风险的。

  9）、要求开发人员在把他的代码添加到系统之前，进行冒烟测试

  10）、惩罚破坏build的人

   ※ 项目开始就应该清楚：保持build的健康是本项目优先级最高的事情之一。

  11）、在早上发布build

  12）、即使有压力，也要进行DailyBuild和冒烟测试

 

  哪种项目能用DailyBuild过程：

  ※ 某些开发人员说，每天进行build是不切实际的，因为项目太大了。

  ※ Windows2000发布时，每天要完整build一次，耗时要19小时，但是开发团队还是想法设法每日都build。项目越大，增量集成就越重要。