即便我们的大多数项目可能面临类似的问题，我们还是缺少明确的方法来解决它们。在软件开发的职业生涯期间，笔者使用了一些方法来解决困扰大部分开发项目的重复出现的问题，这些方法确实有助于有效地执行项目。笔者在文中介绍了项目执行方面的三个最佳实践，其中几个可以认为是成熟的模式：

● 使用模板代码；

● 编写高效的开发手册；

● 执行自动化代码检查。

使用模板代码

示例代码可以帮助开发人员编写非常高效的代码。经常困扰软件开发项目的因素有以下一些。

技术在变化。事实证明，很难找到在新技术方面颇有经验的能够胜任的技术人员。另外，开发新手可能缺乏编写高效代码的经验。模板代码则为开发人员提供了良好的参考点（reference point），从而简化了学习新技术的过程。

学习及使用新技术需要时间，如果处理不当，可能会导致一片混乱。因此可以为开发人员提供模板代码，作为编写代码所用的参考点，从而在开发方面尽快上手，而不是迫使开发人员自己学习新技术。

许多项目人手有限，而且必须在很紧迫的期限内完成。参与项目的每个人都不应该从事重复性工作。高级技术人员在设计阶段也许可以帮得上，不过等到实际实施时，程序员通常只能靠自己了。细小的问题可能会被忽略，到后来却发现已经造成了混乱。Javadoc有几次遵循了标准化的格式和指导准则？代码有几次遵循了明确定义的习惯方法和最佳实践？可视化框架（visual framing）比技术书籍或者参考手册更有效，因此，模板代码能够助一臂之力。

许多软件项目不但很庞大，而且分散在各地。有时候，项目在世界上不同地方开展。如果项目眼看就要完成，谁都不希望客户惊讶地发现代码没有满足他们的预期目标。应该早在开始构造软件之前，就将示例代码发送给客户评审，并且记录反馈意见。这些示例代码应当切合实际、具有代表性，而不只是“Hello World”这样的程序。

开发人员通常都有一大堆参考手册、标准和框架，帮助自己顺利完成项目。但是，即使已经在设计当中，编码习惯方法也不是显而易见的。可视化框架可以提供帮助。除非开发人员有实际的代码示例，否则他们对于拟议项目的解释可能会略有不同。一个项目有可能用不同方式来实现，示例代码可以实现特定的编码习惯方法，从而提供帮助。

为了编写示例代码，需要召集一队专家（技术专家和功能专家），从待开发应用软件的问题领域确认简单及复杂的用例。并且基于现有设计，请这些专家提出实现方法即模板。下面笔者列出了编写这部分代码的一些技巧：

● 代码应当包含立即可用的构建和部署脚本。否则，时间就会白白浪费在构造阶段解决这些问题上。

● 项目的基本目录结构应当为开发人员备好，基本目录结构可能含有项目中使用的各种库。

● 模板代码应当遵循将在项目中使用的命名规范、编码风格、标准和框架。

● 模板代码应当遵循明确定义的Javadoc模板（譬如基于Eclipse的Javadoc模板），这种模板可以让开发人员知道如何编写Javadoc。编写良好的Javadoc很重要，这是因为它们通常是现有代码的维护和改进团队惟一可以使用的文档。

● 编程语言中明确定义的编码习惯方法应当用于模板代码，这有助于开发人员编写高效代码。

● 模板代码应当定义使用框架的标准方法。对开发新手来说，在最初的构造阶段编写针对特定框架的实现类可能是件困难的任务。示例代码有助于理解这些概念。即使某个框架方面有许多文档资料，要弄清楚如何有效编写代码也并不总是件易事。

● 模板代码还应当展示如何使用JUnit或者其他测试框架编写测试用例。

● 为了避免客户最后大吃一惊，客户的技术团队也应当检查这些代码，这样他们更清楚在构造阶段结束后获得的代码质量。

● 模板代码应当包括端到端的用例，也就是从表示层到数据层。

● 应当详细介绍模板代码，好让开发人员熟悉它们的细节。开发人员应当明白每一层需要做哪些工作，还要知道使用了（或者可以使用）哪些编码习惯方法和最佳实践以及原因。

有效的开发手册

假设我们必须执行一个庞大的项目，经常需要30人到50人。不是所有的开发人员都掌握了要用到的技术和标准。一个项目可能涉及不同的技术及专有框架，它们可能用于将来的Java Enterprise Edition项目。如何在开发人员之间转移这么庞大的知识量是一大难题。这里有一些事项需要注意：

许多大项目的开发时间很长（一两年）。一个不争的事实是：软件行业的人员流失率相当高。这是基本事实，也是一个挑战。招聘新人可能很容易，但是转移知识却是项艰巨任务，要是项目时间紧张，更是如此。

一些开发人员可能不具备预期的技能水平。如今，及时找到技能娴熟的开发人员相当困难。如果项目期限很急，这些开发新手就没有时间去学习那些厚厚的技术书籍或者参考手册。有些人可能非常聪明、能干，会另外抽出时间去学习及运用这些概念，但不能保证所有人都是如此。

维护一个刚完工的软件项目也是一大难题。开发周期结束后，客户的IT团队可能会自己维护代码。对这些人来说，熟悉技术架构、对架构进行改动可能是一项重大任务。除非转移知识的方式有了明确规定，否则IT团队在一开始仔细查阅代码和设计文档时可能会经常碰壁。

开发手册应当能解决上面提到的问题。那么，我们如何编写有效的开发手册呢？

以下是编写有效的开发手册的一些技巧:

● 开发手册应当包含构建开发环境所必要的所有相关信息。

● 语句应当简洁、易读。如果阅读的人发现手册读起来费解，这是编写者而不是阅读者的失败。

● 开发手册应当包含大量示例。示例可以清楚地表明手册内容。

● 请一位不熟悉项目中所用技术的开发人员来检查手册。这样一来，如果手册内容让人困惑或者含糊不清，可以在其他人使用之前写清楚。

● 作为低层设计阶段的一部分，手册应当准备好。而且在构造阶段开始时，手册可随时供人使用。

● 手册应当包括多少信息？如何在信息过多和信息过少之间求得平衡？开发人员不喜欢读厚厚的手册。但同时，开发手册中不能遗漏必要的信息，以免许多地方含糊不清。要认真考虑开发人员的实际需求，而不是单单考虑可以提供的所有信息。在编写手册时应当使用简单直观、逐步渐进的方法。

● 开发手册应当界面直观，而不是内容分散、凌乱。手册内容的组织方式应当与现实中开发项目时需要阅读信息的先后步骤一致。譬如说，在Java企业项目中，开发人员首先会构建开发环境，然后开始为表示层和应用数据层编写代码。手册应当遵循这样流程的步骤。

● 确保手册不会让开发人员觉得困惑。譬如说，如果开发人员在编写Struts动作类时需要使用特定的XDoclet标记，他就应当明白项目中使用的标记、意义及使用方法。如果想了解详细信息，他总是可以参阅参考手册。

下面我们看一个Java企业项目所用的实际开发手册是什么样的，它应当包括以下细节：

● 构建细节：每当开发新手加入项目，他必须构建开发环境，之后才能开始工作。别以为开发人员明白项目大大小小的细节。譬如说，要是项目结合使用Eclipse和Weblogic来创建Web应用，开发新手甚至可能不清楚Eclipse或者Weblogic为何物。因此，构建细节应当是开发手册的第一部分。只要稍具Java基本知识的开发新手应当能够很容易按手册构建开发环境。

● 表示层细节：开发人员在处理用例时，通常从表示层开始着手。应当在开发手册中给出创建表示组件的特定步骤。譬如说，如果某项目使用Struts作为表示框架，手册中应当包含定义编写动作类和表单类的步骤。如果项目使用XDoclet来创建struts-config.xml及其他配置文件，手册中也应当包含这些步骤。还应当包含Java服务器页面（JSP）方面的类似步骤。按照模型－视图－控制器模式，JSP页面不应当含有任何Java逻辑。但是对初学或者中级开发人员来说，如何使用JSP标准标记库（JSTL）来真正做到这点可能是个比较大的问题。手册中用一些实际示例表明如何在JSP页面中使用JSTL也有所帮助。

● 业务层细节：业务逻辑可以用无状态Enterprise JavaBeans组件、基于Spring的组件或者简单的普通Java对象来编写。手册提供了项目中使用的业务组件的框架代码以及实际示例。

● 数据层细节：手册为编写Java数据库连接性（JDBC）、Hibernate或者基于框架的其他任何数据访问对象（DAO）提供指导准则，然后包含项目中使用的步骤及最佳实践，这最终取决于项目使用的持久性机制。

● 其他细节：手册提供了有关内部/外部组件的信息，不管J2EE项目中使用哪一层。有可能包含日志、电子邮件组件、审查和安全等信息。另外，在项目后期阶段，手册可能包含介绍如何扩展一些业务需求的章节。譬如说，如果使用了批处理框架，如何对其进行扩展获得新的批处理等。

自动化代码检查

代码检查是另一个问题。如果大批量地生成代码，就需要不断检查代码。即使可能已经为代码检查定义了一套规则，还是有许多问题没有办法在这些规则中加以描述及限制。根据个人的能力和经验，每个人都有自己的代码检查方式。另外，有些问题很小，无法逐行检查。如果需要检查的代码很多，这些小问题可能会在某个地方被忽略。如果错误隐藏在集成开发环境（IDE）本身里面该怎么办？有些工具有助于查找这些问题，用不着手动查找。

● Eclipse IDE的设置

有时候，IDE设置可以提供帮助。譬如说，可以修改Eclipse IDE里面的参数选项。万一代码出现了问题，可以显示警告。图1是在Eclipse中改变参数选项的示例。

图1 Eclipse Javadoc设置

如果仔细看一下，就会发现Eclipse会在IDE本身里面显示警告，这样开发人员就可以改正。万一项目标准很严格，就会显示错误，迫使开发人员改正问题。

● Jlint

同样，名为Jlint的一个工具可结合Eclipse使用，查找代码中的细小问题。可以采用以下步骤来使用Jlint：

首先，下载jlint插件和二进制代码，把二进制代码解压缩到C:\lint文件。另外把插件解压缩到Eclipse插件目录。

然后，运行Eclipse, 进入“窗口”菜单，先后选择“参数选项”、Java和Jlint，把Jlint位置设为C:\jlint\jlint.exe。

最后，用鼠标右键点击“资源”视图中的Eclipse项目，然后选择Jlint。工作区构建完毕后，就会出现黄色的警告标记。

图2 是Eclipse中有关Jlint设置的示例。

图2 Eclipse Jlint配置

● Lint4j

如果不依靠IDE，可以使用Lint4j的Ant脚本来发现代码中的问题。需要为这个脚本指定以下参数：

lint4j.dist.dir：安装lint4j发布包的目录

packages：Lint4j检查的Java软件包

ignorePackages: lint4j忽略的Java软件包

以下是Jlint的Ant构建脚本的示例：

< ?xml version="1.0"?>

< project name="Lint4j" default="lint4j" basedir=".">

< property name="lint4j.dist.dir" value="C:/tools/lint4j-0.8.2"/>

< property name="lint4j.level" value="5"/>

< property name="lint4j.exact" value="false"/>

< taskdef name="lint4j" classname="com.jutils.lint4j.ant.Lint4jAntTask">

< classpath>

< pathelement location="${lint4j.dist.dir}/jars/lint4j.jar" />

< /classpath>

< /taskdef>

< target name="lint4j" description="Run Lint4j on your source">

< lint4j ignorePackages="" packages="com.domain.*" level="${lint4j.level}" exact="${lint4j.exact}">

< sourcepath>

< dirset dir=".">

< include name="**/src" />

< /dirset>

< /sourcepath>

< classpath>

< pathelement location="C:/bea/weblogic81/server/lib/weblogic.jar" />

< fileset dir=".">

< include name="**/*.jar" />

< include name="**/*.zip" />

< /fileset>

< fileset dir="ejblib">

< include name="**/*.jar" />

< /fileset>

< fileset dir="lib">

< include name="**/*.jar" />

< /fileset>

< /classpath>

< formatters>

< formatter type="text" />

< formatter type="text" toFile="./target/lint4j.log"/>

< /formatters>

< /lint4j>

< /target>

< /project>

● Checkstyle

代码检查的另一个工具是CheckStyle，它遵循Java开发高手普遍采用的重要的Java编码准则来检查代码。它也可以结合Ant脚本使用。CheckStyle的选项配置起来具有很大的灵活性，可用来支持几乎任何编码标准。提供的示例配置文件支持Sun的编码规范。这个Ant脚本可以让代码检查同编译过程一起完成，以便开发人员了解这些错误，并加以改正。

结论

软件开发项目中通常面临的问题大多数是重复出现的。在如今充满竞争的世界——缩短开发时间、降低开发成本的压力很大，所以没有时间为每个项目重新设计解决方案。

本文没有提供解决所有软件执行问题的办法，它只是向前迈出了一步。本文旨在演示了使用最佳实践作为软件开发的高效工具。事先知道这些软件执行方面的最佳实践和模式，就可以准备好解决项目生命周期过程中可能出现的任何障碍。这也让项目经理、架构师和开发人员能够把精力集中在“实际”的开发，而不是应对意料不到的情况。（沈建苗 编译）

链接:模板代码的好处

● 开发人员获得了开始编写代码的参考资料。

● 客户与开发人员就代码的预期质量达成共识，从而避免了通常因双方误解而出现的那些问题。

● 开发人员拥有了开始编写代码的框架代码（skeleton）。

● 开发人员更容易掌握框架以及将使用的任何外部API或者组件，提高了工作效率。

● 开发人员用不着不断从事重复性工作。大多数最佳实践和编码习惯方法都摆在了他们面前，这再次可以提高工作效率。

（计算机世界报 2006年09月25日 第37期 B29、B30）