Oh!Coder

Coding Life

读《代码大全(第二版)》笔记(六)

| Comments

本周读了本书的第六部分,此部分的主题为系统考虑。本部分分为四个章节,分别描述了程序规模对构建软件的影响,对构建的管理,系统的集成,以及相关的编程工具。

还是老样子,下面对每一章的内容进行简要的摘录。

第二十七章——程序规模对构建的影响

本章开始描述了交流与规模的关系,提出(Page.650)…二者的关系并不是加性的而是乘性的。即交流路径的条数大致正比于人数的平方。

根据项目规模的不同,会对错误产生不同的影响。(Page.651)项目的规模既会影响错误的数量,也会影响错误的类型。坦白说,这句话中所说的项目规模会对错误数量产生影响很自然可以想到,但是说也会影响错误的类型,我之前是没有想到的。

书中谈到项目规模对生产率影响一节时,引用到这样一句话,我觉得对于移动互联网的开发也是蛮适合的。这句话是这样说的(Page.653)…,完成项目的小型团队的生产率摇臂大型团队高出39%,那么这些团队各有多少人呢?答案是,小项目两个人,大项目三个人(1984)。之前看《打造Facebook》那本书的时候,作者提到在Facebook内部开发一个新项目,一般人数也很少。例如他自己主导开发的那个项目,一开始也只有三个人。

对于项目规模对开发活动的影响一节中,文中指出(Page.655)规模相近的项目会执行相似的活动,但是随着项目规模不同,其所需要进行的活动的种类也会有明显的差异。最后谈论了一下不同级别的规模与方法论之间的关系。其实,本章讲的都比较概括,不过中心思想很明确,主要就是描述了因为程序规模的不同对于构建软件不同方面的影响。

第二十八章——管理构建

本章主要讲了对于软件开发过程中的项目管理。

在编码方面,提出了一些建议,其中对于定制标准方面,书中给出了一条建议,我觉得可以直接用于实践,

(Page.662)如果项目中有人要制定标准,那么应该由一位受人尊敬的架构师来做,而不应该由管理者来做。在软件项目中,“专家层”起的作用至少与“管理层”相同。

其实,像这种直接面向技术层面的问题,管理者或许没有资深的技术人员更专业。对于良好的编码实践要比呆板的标准更容易实行。书中给出了几条建议(Page.662~Page.664)。

  • 给项目的每一部分分派两个人
  • 逐行复查代码
  • 要求代码签名
  • 安排一些好的代码示例供人参考
  • 强调代码是公有财产
  • 奖励好代码
  • 一份简单的标准

上面的建议的好处也比较明显,就不展开说了。

接下来讲到配置管理,什么是配置管理?

(Page.664)配置管理是“系统化地定义项目工件(project arifacts)和处理变化,以使项目一直保持其完整性”的实践活动。它的另一种说法是“变更控制”。其中的技术包括评估所提交的更改、追踪更改、保留系统在不同时间点的各历史版本。

对于构建过程中需求的变更和设计的变更,书中给出了一种方法是,

(Page.666)…,记下所有的想法和建议,不管它实现起来有多容易。把它记录下来,直到你有时间去处理它们。到那时,把它当做整体(group)来看待,从中选中最有益的一些变更来加以实施。

即便如此,对于软件的变更也会是一大难题。估计很多朋友都在网上看到过一些有趣的漫画,内容大概是项目经理让程序员不停的改动需求,直到程序员崩溃…。书中对此现象的评价说(Page.667)缺乏规范的变更控制是当今软件业面临的主要管理难题之一。看来,变更是一个世界性的难题,呵呵。

对于软件代码变更的管理,书中提到了版本管理软件的使用。版本管理软件不但可以有效的管理代码变更,还可以对代码起到备份的作用,不会轻易丢失代码。

对于评估构建的进度方面,书中提到了一些评估项目的方法(Page.671~Page.672)。

  • 建立目标
  • 为评估留出时间,并且做出计划
  • 清楚地说明软件需求
  • 在底层细节层面进行评估
  • 使用若干不同的评估方法,并且比较其结果
  • 定期做重新评估

具体就不展开说了,都比较容易理解。

对于项目进度影响最大的原因是(Page.674)…所开发的程序的规模。这一点很容易理解,呵呵。

在度量这一节中,文中提出了对项目进行度量的两个根本原因。

  • (Page.677)任何一种项目特征(attribute)都是可以用某种方法来度量的,而且总会比根本不度量好得多。
  • (Page.678)反对度量就是认为最好不要去了解项目中到底在发生什么。

其实,关于度量,我自己的理解是,需要有一个大致的标尺来丈量项目的进度,但也不应该过于依赖这种度量,要张弛有度,保证项目不偏离大方向。

本章后面部分讲述了一些管理方面的经验。例如如何和你的管理者沟通等等。其中有很多建议实践性很强,并且针对性也很强,需要有相应的环境为基础,所以在此就不罗列了,没太大意义。

第二十九章——集成

本章讲述了几种软件集成的方式,但各有利弊,无银弹。

对于集成的方式,分为两种:阶段式集成和增量集成。

首先从阶段式集成开始介绍。阶段式集成的另一个名称是“大爆炸集成”。阶段式集成面临的问题,摘用书中的一句话描述,

(Page.691)阶段式集成的一个问题是,当第一次把系统中的类放到一起时,新的问题会不可避免地大量浮现,而问题的成因可能是方方面面的。

书中说,对于(Page.692)…,对微型程序——而言,阶段式集成或许是最佳方式。其实也可以看出,阶段式集成非常的不常用。下面介绍增量集成。

在增量集成中,可以一次一块地将程序模块拼接起来。对于增量集成的好处,书中列出了几条(Page.693~Page.694):

  • 易于定位错误
  • 及早在项目里取得系统级的成果
  • 改善进度的监控
  • 改善客户关系
  • 更加充分地测试系统中的各个单元
  • 能在更短的开发进度计划内建造出整个系统

其实,我感觉这些条条框框基本上也记不太准确,可以作为参考吧。对于增量集成的策略,书中提到了几种,下面一一说明。

自顶向下集成

故名思义,在自顶向下的集成中,首先编写并集成位于层次体系(hierachy)顶部的类。此种策略,除了具有增量集成的一般优点以外,能相对较早地测试系统的控制逻辑,能够在项目早期完成一个能部分工作的系统。

但是除了优点以外,当然还有缺点,在纯粹的自顶向下集成将棘手的系统接口的演练留到最后才进行。书中给出的最终意见是(Page.696)实现纯粹的自顶向下集成也是近乎不可能的。

自底向上集成

在自底向上的集成中,需要先编写集成位于hierarchy底部的类。关于这种方法的优缺点,书中说(Page.697)它能讲错误的可能来源限制到“正在被集成的那一个类”上,因此容易定位错误。但同样,缺点是(Page.697)它将重要的高层系统接口集成工作留到最后才进行。

三明治集成

关于这种方法,(Page.698)首先是集成层次体系(hierachy)顶部的高层业务对象(business-object)类。然后集成底部的与设备接口的类和广泛使用的工具类。这些高层类和底层类是三明治的那两片面包。这种集成方法避免了纯粹的自底向上或自顶向下集成的僵化做法。先集成通常比较棘手的类,降低了后期的风险。

风险导向的集成

风险导向的集成也称为“困难部件优先集成”。它和三明治集成类似,也是趋向于先集成顶层类和底层类,讲中间层类留后处理,但是它们的出发点不同。其实不同点主要就在于,风险导向的集成偏向与先把风险高的部件进行集成。

功能导向的集成

顾名思义,也就是一次集成一项功能。(Page.701)纯碎的功能导向的集成和纯碎的自顶向下或自底向上集成一样苦难。通常需要先集成某些底层的代码,之后才能集成某些重要的功能。

T—型集成

对于这种集成方法,是选中某个特定的“竖直块/vertical slice”,对它及早开发并进行集成。对于这个功能模块,是从头到尾的进行完成,而且过程中应该能找出系统设计所做的假设中的全部主要问题。这种方法,通常和“风险导向的集成”或“功能导向的集成”结合使用。

本章最后,还提到了两种方法,一种是daily build,另一种是冒烟测试。对于这两种方法就不展开说了。

第三十章——编程工具

从标题也可以看出,本章主要围绕着工具展开,其中包括设计工具、代码管理工具、编程工具等。整个章节大概翻了一下,基本都是介绍性的说明了一下功能,或者是作用等,这里就不多说了,没有太大的意义,因为每个人的工作习惯都不一样,而且随着时间的推移,很多工程上的方法也都在不断的变化,所以感觉这部分没有太大的参考价值。

Comments