懒惰化、标准化、自动化——工具化
——利用合适的工具构建流水线软件过程
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作为网站应用的构建技术，因此下面提到的一些工具有些来自开源社区，有些是共享软件，当然也有一些商业软件。这里不是要求你使用所有的工具，也不是说必须使用那个工具，只是一一展示利用各种工具能够让你省却你曾经以为不可能缩减的工作。我不想去熬述软件开发过程的各个环节，毕竟那样的课题不是这点文字可以解决的，我想讨论的是一个标准的网站应用开发的各个环节你可能使用的工具。而一个网站开发过程不外乎需求——数据库设计——建模——实现——测试——部署这样粗线条的东西。
有很多种理由去推荐这个工具，如果你从事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版中，相对于专业版，企业版提供了强大的脚本生成功能。
在.NET之下，如果说CodeSmith是最好的代码生成工具一点也不为过，而在Eric的团队中，也对CodeSmith的威力推崇到极致。如果你做过基于数据库应用的开发，相信会对那些重复的数据库操作语句头疼不已，太多的属性字段，太多的更新、太多的插入，太多太多。。。。
我相信你不会陌生下面这样的代码
这 是一个最普通的数据库操作封装，如果你在应对频繁的数据库操作，类似这样的代码将是无比琐碎。其实如果仔细想想，这样的代码是否在不同的类中都会出现，固 定化的属性访问，一成不变的数据库操作，相信你写过这样的代码，更加相信你不愿意写这样的代码。这个工具理所当然的成为了懒惰人的工具。基于模板和ASP.NET语法的特性一定会让大多.NET开发人员喜欢。在Eric的团队里头，大多的数据库访问类（也就是设计领域熟知的数据访问层（DAL），也有人简单的称之为Business Object）都是利用这个工具生成的，其中带来的好处是极大程度的减少不必要的开发工作量，同时因为模板生成的代码是统一规范的，能够维持代码风格的一致性。这个工具可以从http://www.codesmithtools.com 下载，有三十天的免费使用，样例文件中包含了大量的模板，包括集合、数据库和XML等等各个方面，也包含了CSLA.NET的完整模板。
其实在这里介绍一个这样的重量级软件不是那么合适，但是如果你用过Rose，用过Together，你绝对无法忍受没有他们的建模方式，虽然VS.NET已经足够好用，但是我还是强烈推荐他作为你建模过程的首选工具（前提是你们的公司有能力去支付价格不菲的软件授权费），通过CodeSmith生成的代码并无法尽善尽美，在数据依赖的基础之上你还要去定义对象动作，定义关系，定义依赖，定义他们的活动时序图。或者你会告诉我没有必要将UML搞得如此晦涩难懂，在小型团队的开发过程中没有必要使用这样的大家伙，XP极限编程对于几个人的团队再适合不过，但是你依旧需要一个概括性的抽象视图：或者类图，或者部署图，或者你期望的其他视图，不管如何，这个时候你需要一个工具能够来做这些事情，Visio可以导出UML图，但是XDE做的更好，最重要的是对于代码和模型，XDE提供了无缝的双向工程。这个意味着你可以利用CodeSmith生成的代码转换成UML图，然后根据你的业务需要修改UML，然后再次生成代码，等到交付到开发人员手中需要实现的代码时，需要做的工作已经很少很少，要做的事情已经很好。“卓越的本质就是每件事情做得都比其他人好一点点”，XDE就是一个这样的工具。对于此如果有兴趣的读者可以在IBM Rational的网站上找到相关的下载，当然了，这是一个比较昂贵的软件。
Eric的团队依旧很懒惰，很不愿意编写程序文档，很许多人坚持的观点一样“代码就是文档”，但是从几千几万行的代码中去阅读确实不是一件容易的事情。如果你熟悉C#，应该知道VS.NET IDE对于其提供了XML注释的支持，对于使用VB.NET的朋友，在SourceForge也可以找到相关的辅助工具。一个良好的设计一定会有良好的代码注释，那么怎样提取这些代码注释，然后用统一的文档来展现呢？
也许你熟悉了CHM格式的文档，也许熟悉Java Doc风格，也许熟悉MSDN风格，如果专门花费时间来制作这些程序文档是耗时耗力的事情。NDoc，从Java Doc借鉴过来的一个工具就是来解决这个问题的，它可以从C#生成的XML注释文档和程序集提取相关信息，然后根据你的需要生成指定格式的文档。如此一来，你还需要专门的文档人员来帮你写程序文档吗？
如果不知道如何测试自己的代码，那么你绝对不是合格的程序员，如果你不了解测试驱动开发，那么你也不是合格的程序员。这话或者太绝对和偏激，但是TDD已经成为一种推荐的开发方式，“测试先行”也得到越来越多开发人员的接受。如果你以前对于一些业务代码的测试是利用控制台或者测试网页来完成的话，那么我建议你一定要先去看看这个工具——NUnit，创意依旧来自于软件过程更加成熟的Java社区，相信你看看所有的绿灯亮起的时候，你会有一种无比的成就感。可以从http://www.nunit.org 得到相关的软件。
别告诉我你没有用过版本控制工具，假若如此，那么将给软件开发过程引入无尽的风险，没有版本比较，没有代码追朔，没有项目分支，团队的开发人员将陷入协作的灾难之中。作为老牌的版本控制工具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 的到相关的下载
这是最后一个工具，一个大多人忽视的环节。你是否在最后的测试阶段和需求还有测试人员牵扯不清，也没有一个定量的指标去衡量软件开发质量，这个时候缺陷管理也就是我们通常意义的BugTrack就显得至关重要，作为和Vault同一个公司的产品，除了Dragnet正是针对如此问题而提出的解决方案。除了基于Web和.NET之外，Dragnet做到了和Vault的无缝集成，开发人员可以在VS.NET的环境中直接更新各个错误。
工具为本？人为本？
不要期待工具可以解决你所有的问题，问题因人产生，工具因为问题创造，但是在开发过程中如果能够有效的利用一些工具减少不必要的重复或者提高团队协作，何乐而不为呢？随着Visual Studio 2005的临近，我们看到了另外一种选择——Visual Studio Team System，这个VS.NET的第三个版本将前所未有的强调软件工具化和开发协作化，或者，再过几年，Eric的团队不用那些组合工具，但是想法依旧没有变。
做你自己的软件，懒惰一点，规范一点，自动一点，只有你意识到使用工具多一点，才可能构建出流水线的软件过程。
刘如鸿(Eric Liu)发表于 2005年06月21日 14:41:00
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。