原文发表在《 MSDN 开发精选》，如有商业站点转载请联系杂志社或者我本人，可以从 这里 下载，如果有兴趣的读者，可以去购买这个杂志阅读，下面提到的一些软件如果涉及到版权问题，均和本文无关。同时感谢杂志社的霍泰稳先生，正是他对于我的穷追不舍才让 我憋完此文 。对于小型软件开发团队的探讨，也希望能够和各位交流，我的 Email: liuruhong at gmail.com
懒惰化、标准化、自动化——工具化
——利用合适的工具构建流水线软件过程
Eric Liu at 2005年5月
Eric 是一家小公司的开发部经理，同样也是一名普通的开发人员。这是一家提供网站服务的公司，理所当然的， Eric 这个部分的主要工作是基于网站应用的开发，就如目前主流应用的推介的做法，所有的应用是分层设计的，理所当然的有数据访问层、业务逻辑层和表现层。 Eric 所带的几个开发人员也没有任何与众不同之处： A 君比较 熟悉数据库和业务逻辑层的编写，但是对于 Web 表现层的了解太太有限； B 君对于 JavaScript 、 HTML 、 CSS 等等有比较多的了解，但是对于组件层的开发还略显生疏； C 君非常 熟悉业务，但是对于具体实现技术的了解有限； D 君。。。。
这个一个普通得不能够再普通的团队，不论在技术还是在协作上都没有太多的出彩之处。而就是这样一个组建不久的团队， Eric 的任务是带领他们在三个月之内完整整个应用网站的开发，并且保证完工的东西能够适应未来发展的变化。
我想在大多数人看来，如果保证软件架构的向前扩展性和兼容性，这是一个软件 架构师应用 考虑的问题，而不应该把他降解到普通开发人员的身上，道理是正确的，可是可行性是不高的，在国内的软件开发中，谁都明白很多时候软件过程的各个角色重叠和冲突的可能性是很大的，很少有团队能够不打折扣的分离出这些岗位。比方来说，应该将系统 架构师 和系统分析员这两个角色分离，让架构师专注于技术和业务的可实现性规划，而系统分析员在 架构师 工作的基础上，将技术和业务转化成面面俱全的应用。现实的说，没有多少公司可以在一个项目中同时建立这两个角色。
对于 Eric 而言，一切困 挠无法 幸免，在小型开发团队中，角色的相对模糊和对于结对协作的高要求是同时出现的，这个也就是矛盾本身。如果说 RUP 或者其他软件过程最大的贡献是分离和定义角色，并且指明了各个角色的职责和如何互动，这个一切的基础是在于相对稳定的目标上的角色清晰化。那么 XP 编程恰恰相反，他强调变化，并且拥抱变化，业务导向 (Business Oriented) 的开发方式同样决定了无法严格界定岗位。
正是因为如此， Eric 的团队必须解决几个问题：
n 如何高效的编写出应用需要的代码？
n 如何保证不同开发人员的代码具有统一的规范性和 可 阅读性？
n 如何在业务变动的情况下快速适应变化
n 如何保证代码质量？
n 是否需要版本控制？
n 如何进行错误跟踪和回馈
n 。。。。
一切正如本文题目所言的：懒惰化、标准化、自动化，方才可能构建出流水线的软件过程，这就是 Eric 这个团队所要解决的问题，答案是简约有效的——工具化， 让工具 替你完成一切可以完成的工作。
因为 Eric 的开发团队采用了 ASP.NET 作为网站应用的构建技术，因此下面提到的一些工具有些来自开源社区，有些是共享软件，当然也有一些商业软件。这里不是要求你使用所有的工具，也不是说必须使用那个工具，只是一一展示利用各种工具能够让你省却你曾经以为不可能缩减的工作。我不想 去熬述软件开发 过程的各个环节，毕竟那样的课题不是这点文字可以解决的，我想讨论的是一个标准的网站应用开发的各个环节你可能使用的工具。而一个网站开发过程不外乎需求——数据库设计——建模——实现——测试——部署这样粗线条的东西。
Visio( for Enterprise Architect 2003)
有很多种理由去推荐这个工具，如果你从事 VS.NET 开发，这是最好的数据库工具，也是最容易使用的数据库建模工具，或许你已经习惯了 Power Designer 或者 ERWin 这样的数据库建模工具，会觉得 Visio 太多简单。可有些时候反过来想“ simpleness is beautiful ”，如果你是一个数据库建模的初学者，那么请相信我的建议，如果你是一个资深的建模人员，也请认真考虑你们手头的工具是否太过复杂，特别是应用在团队中的沟通时。除了支持主流的数据库如 Oracle 、 SQL Server 、 Access ，你完全可以通过安装自己的数据库驱动来实现 Visio 对于其的支持，当然了，作为 Office 家族的一员， Visio 的另外一大优势就是你可以通过宏或者 VBA 自动化你的 IDE 。
我这里推荐的是 Vs.NET 自带的 Visio 版本，相对于 Office 系列，总体有一个版本号的延迟，如 VS.NET 2003 自带的是 Office XP 版本的 Visio ， Office 2003 的 Visio 版本集成在了 Visual Studio 2005 Beta 版中，相对于专业版，企业版提供了强大的脚本生成功能。
CodeSmith
在 .NET 之下，如果说 CodeSmith 是最好的代码生成工具一点也不为过，而在 Eric 的团队中，也对 CodeSmith 的威力推崇到极致。如果你做过基于数据库应用的开发，相信会对那些重复的数据库操作语句头疼不已，太多的属性字段，太多的更新、太多的插入，太多太多。。。。
我相信你不会陌生下面这样的代码
这是一个最普通的数据库操作封装，如果你在应对频繁的数据库操作，类似这样的代码将是无比琐碎。其实如果仔细想想，这样的代码是否在不同的类中都会出现，固定化的属性访问，一成不变的数据库操作，相信你写过这样的代码，更加相信你不愿意写这样的代码。这个工具理所当然的成为了 懒惰人 的工具。基于模板和 ASP.NET 语法的特性一定会让大多 .NET 开发人员喜欢。在 Eric 的团队里头，大多的数据库访问类（也就是设计领域熟知的数据访问层（ DAL ），也有人简单的称之为 Business Object ）都是利用这个工具生成的，其中带来的好处是极大程度的减少不必要的开发工作量，同时因为模板生成的代码是统一规范的，能够维持代码风格的一致性。这个工具可以从 http://www.codesmithtools.com 下载，有三十天的免费使用，样例文件中包含了大量的模板，包括集合、数据库和 XML 等等各个方面，也包含了 CSLA.NET 的完整模板。
Rational XDE Plus for VS.NET
其实在这里介绍一个这样的重量级软件不是那么合适，但是如果你用过 Rose ，用过 Together ，你绝对无法忍受没有他们的建模方式，虽然 VS.NET 已经足够好用，但是我还是强烈推荐他作为你建模过程的首选工具（前提是你们的公司有能力去支付价格不菲的软件授权费），通过 CodeSmith 生成的代码并无法尽善尽美，在数据依赖的基础之上你还要去定义对象动作，定义关系，定义依赖，定义他们的活动时序图。或者你会告诉我没有必要将 UML 搞得如此晦涩难懂，在小型团队的开发过程中没有必要使用这样的大家伙， XP 极限编程对于几个人的团队再适合不过，但是你依旧需要一个概括性的抽象视图：或者类图，或者部署图，或者你期望的其他视图，不管如何，这个时候你需要一个工具能够来做这些事情， Visio 可以导出 UML 图，但是 XDE 做的更好，最重要的是对于代码和模型， XDE 提供了无缝的双向工程。这个意味着你可以利用 CodeSmith 生成的代码转换成 UML 图，然后根据你的业务需要修改 UML ，然后再次生成代码，等到交付到开发人员手中需要实现的代码时，需要做的工作已经很少 很少 ，要做的事情已经很好。“卓越的本质就是每件事情做得都比其他人好一点点”， XDE 就是一个这样的工具。对于 此如果 有兴趣的读者可以在 IBM Rational 的网站上找到相关的下载，当然了，这是一个比较昂贵的软件。
NDoc
Eric 的团队依旧很懒惰，很不愿意编写程序文档， 很许多 人坚持的观点一样“代码就是文档”，但是从 几千几万 行的代码中去阅读确实不是一件容易的事情。如果你熟悉 C# ，应该知道 VS.NET IDE 对于其提供了 XML 注释的支持，对于使用 VB.NET 的朋友，在 SourceForge 也可以找到相关的辅助工具。一个良好的设计一定会有良好的代码注释，那么怎样提取这些代码注释，然后用统一的文档来展现呢？
也许你熟悉了 CHM 格式的文档，也许熟悉 Java Doc 风格，也许熟悉 MSDN 风格，如果专门花费时间来制作这些程序文档是耗时耗力的事情。 NDoc ，从 Java Doc 借鉴过来的一个工具就是来解决这个问题的，它可以从 C# 生成的 XML 注释文档和程序集提取相关信息，然后根据你的需要生成指定格式的文档。如此一来，你还需要专门的文档人员来帮你写程序文档吗？
NUnit
如果不知道如何测试自己的代码，那么你绝对不是合格的程序员，如果你不了解测试驱动开发，那么你也不是合格的程序员。这话或者太绝对和偏激，但是 TDD 已经成为一种推荐的开发方式，“测试先行”也得到越来越多开发人员的接受。如果你以前对于一些业务代码的测试是利用控制台或者测试网页来完成的话，那么我建议你一定要先去看看这个工具—— NUnit ，创意依旧来自于软件过程更加成熟的 Java 社区，相信你看看所有的绿灯亮起的时候，你会有一种无比的成就感。可以从 http://www.nunit.org 得到相关的软件。
SourceGear Vault or VSS
别告诉我你没有用过版本控制工具，假若如此，那么将给软件开发过程引入无尽的风险，没有版本比较，没有代码追朔，没有项目分支，团队的开发人员将陷入协作的灾难之中。作为老牌的版本控制工具 Visual Source Safe 没有作为我的首选推荐，原因在于除了版本相对老化（ 6.0 以后没有大的更新），最主要的因素在 Internet 时代居然只能够通过局域网共享访问的方式来实现代码库的访问。或者恰恰因为如此，也造就了版本控制工具的百花齐放，除了大名鼎鼎的 CVS ，但是这个在 Java 世界如日中天的家伙却不是那么适合 .NET 开发，或者是因为和 VS.NET IDE 集成不够的原因，或者是因为两个社区不同的问题。幸运的是，在 .NET 下面除了 VSS 6, 我们还有很多选择，如 VSS Remoting 或者 SourceGear 的 Offsite ，他们都在 VSS 的基础上提供了 Internet 远程访问的能力。
在这里推荐 Vault 的理由很多，因为它基于 SQL Server ，因为它使用 .NET 编写，因为它采用 XML Web Services 作为通信协议，当然还有一点别忘记了， SourceGear Vault 提供了免费一个月 10 用户的试用授权，如果不怕麻烦的话，您也可以每个月更新 License 。在使用习惯方面和传统的 VSS 区别不大，没有太多的学习代价，另外还提供了 Web 访问代码库的功能。可以从 http://www.sourcegear.com /vault 的到相关的下载
SourceGear Dragnet
这是最后一个工具，一个大多人忽视的环节。你是否在最后的测试阶段和需求还有测试人员牵扯不清，也没有一个定量的指标去衡量软件开发质量，这个时候缺陷管理也就是我们通常意义的 BugTrack 就显得至关重要，作为和 Vault 同一个公司的产品，除了 Dragnet 正是针对如此问题而提出的解决方案。除了基于 Web 和 .NET 之外， Dragnet 做到了和 Vault 的无缝集成，开发人员可以在 VS.NET 的环境中直接更新各个错误。
工具为本？人为本？
不要期待工具可以解决你所有的问题，问题因人产生，工具因为问题创造，但是在开发过程中如果能够有效的利用一些工具减少不必要的重复或者提高团队协作，何乐而不为呢？随着 Visual Studio 2005 的临近，我们看到了另外一种选择—— Visual Studio Team System ，这个 VS.NET 的第三个版本将前所未有的强调软件工具化和开发协作化，或者，再过几年， Eric 的团队不用那些组合工具，但是想法依旧没有变。
做你自己的软件，懒惰一点，规范一点，自动一点，只有你意识到使用工具多一点，才可能构建出流水线的软件过程。