3.4 风险：低品质的软件

作者: （美）Paul M.Duvall Steve Matyas Andrew Glover著 . 出处:机械工业出版社 　2008-04-21 16:04　   砖    好    评论  条 　进入论坛

阅读提示：《持续集成》第3章为您介绍的是利用CI减少风险,本节主要讲述的是风险：低品质的软件。

3.4   风险：低品质的软件

有缺陷，然后就有了潜在缺陷。如果软件设计得不好，不遵守项目的标准，或者维护起来很麻烦，这些就是潜在缺陷。有时候人们称之为代码或设计的气味—“某些事情不对的一种征兆”。一些人相信，低品质的软件只是把项目的成本延迟了（延迟到交付之后）。它可以成为延迟的成本，也可以在您把软件交付给用户之前就带来许多其他问题。过度复杂的代码，不遵守架构的代码和重复的代码常常会导致软件中的缺陷。在这些代码和设计气味成为缺陷之前就把它们找出来，可以节省大量的时间和金钱，并得到高品质的软件。我们在这一节将讨论几个这样的场景。

在一个项目中，我们不知道软件的可维护性如何，除非我们每天都用人工复查所有源代码。我们不能够确定正在开发的软件的品质趋势。许多项目成员觉得他们“没有时间”提高软件的内在品质，也不知道如何开始。某些项目有编码标准文档，但很少有人看，也很少有遵守。另一些项目根本没有标准。在某些项目中，软件的无序性是很明显的，因为我们担心所做的变更会破坏软件。

场景：坚持编码标准

下面是一段关于遵守编码标准的典型对话。

Brian（开发者）：我发现读您的代码很困难。您在上个月开始工作的时候，有没有读过那份30页的编码标准文档？
Lindsay（开发者）：我用的是我在前一个工作中使用的风格。我写的代码比较复杂，所以您理解起来可能比较困难。
Brian：写一些别人没法对付的代码并不会使您显得更聪明，只会降低您的价值。我花了较长的时间来复查和更新这些代码。请您尽快看一下编码标准文档。首先，您可以把您原来的代码重新整理一下，然后利用编码标准完成新的代码。

解决方案

我们没有写30页的编码标准文档，而是创建了一个一页纸的带注释的类，包含了所有编码标准。我们利用自动化的审查工具来强制执行编码标准，这些工具在构建脚本中运行，由CruiseControl发起。在主要采用Java的项目中，我们利用Checkstyle和PMD来报告不满足已知标准的代码。我们以HTML报告的形式展示这些信息，并把它集成到了CruiseControl CI服务器中。在新的项目中，如果有违反编码标准的代码，我们就不会让构建通过。

场景：维持架构

没有遵守预期设计的源代码更加难以维护。您是否遇到过这样的项目，在开始时建立了非常优雅的软件架构，最后却变成了“一个大泥球”？也许架构师利用UML建模工具设计了整个系统，然后说“按照这个参加架构来做。”这可能很极端，但像所有事情一样，总有一些灰色的因素在其中。

计划的架构和实际的架构之间存在差异，这可能会带来问题。例如，假定您有一项架构指南说：“数据层永远都不应该调用业务层。”也许架构师使用一个UML建模工具，利用正向工程将基于这个架构的模型转换成了源代码。但是，随着时间推移，代码发生了改变，架构与最初的设计也发生了偏离。例如，假设一个新的开发者加入到项目中，发现业务层里有一些有用的方法，然后从数据层调用了它。这破坏了项目的架构。如何能够确保这样的事情不会发生？

Jenn（架构师）：您们遵守了架构吗？我在一个控制器代码中发现一些问题，其中您们直接调用了数据层中的一个组件。
Mark和Charlie（开发者）：（不知所措的表情）。
Jenn：我创建这些UML图的目的是让所有人都遵守已经建立起来的软件架构。你们没有遵守已经建立了几个月的协议。

Charlie：我在项目开始时还看那些图，但自那时起架构已经发生了几次变化，很难再对得上了。

解决方案

添加自动化的审查工具来判断是否遵守了项目的架构标准。例如，您可以添加一项规则，规定控制器类永远也不能直接调用数据访问对象。您可以利用JDepend或NDepend这样的依赖分析工具来生成架构遵守情况的报告。可以在每次集成构建时运行这样的工具。

场景：重复的代码

重复的代码使代码变得更难维护，增加了软件的成本。在我们遇到的所有项目中，复制粘贴代码都是一项风险。实际上，有许多知名的软件开发工具，其中有25%的代码是重复的。我们在一个公司里对所有软件开发项目进行了分析，发现平均有45%的重复代码。当您有许多类似代码的副本需要维护时，就会带来问题。例如，一个系统有5个类似代码的副本存在于不同的子系统中。我们假定您有一些代码检查当前登录的用户的权限。开发者没有把它写成一个方法，而是在需要授权给用户时就复制粘贴一段代码。当开发者创建他们自己的逻辑而不是使用通用的功能时，您会发现另一种形式的代码重复。这些代码不是逐字逐句地复制粘贴的，但还是会产生代码复制同样的效果。

Mary（开发者）：您知道怎样才能遍历User对象的集合吗？
Adam（开发者）：我知道。我上周写了一些代码干这事。您可以在User包中找到。
Mary：太好了！我可以把这些代码复制一下，用在这里。谢谢。

事情就是这样的，代码重复在延续。除非您知道重复的情况在加重或减轻，并且知道哪里发生了重复，否则很难确定面对的是什么问题，哪儿需要重构。

解决方案

要提出一个解决方案，您首先需要评估问题。您可以加入PMD的CPD或Simian 静态分析工具，进行自动化的审查并报告重复的源代码。我们将这些审查工具作为构建过程的一部分，这样就能够随时运行。利用这些工具，我们确定了重复代码的位置，然后将这些代码提取成为公用组件。利用这种方法，我们能够持续监视代码的重复程度，减少系统中重复代码的数量。

在一般的情况下，我们会发现多个类中存在同样或类似的代码。请按照下面的步骤来消除重复的代码。
1. 利用Simian或PMD的CPD等代码重复分析工具来分析代码。将它纳入到您的构建脚本中。
2. 通过重构将这些代码放到一个方法或一个组件中，然后在需要的地方进行调用，从而消除重复的代码。
3. 将代码重复审查工具放入CI系统中，持续运行代码重复审查。这让您能够知道代码重复程度随时间的变化情况。

第7章详细介绍了可以执行的审查以及在何时、以怎样的频度来执行审查。

回书目   上一节   下一节