拿Java来说，构建一个项目的问题有一下这么几个：

1. 项目的组织方式
2. 项目的源代码控制策略
3. 项目的依赖控制（工程之间的依赖以及第三方库的依赖）
4. 项目的构建方式
5. 项目的构建和发布周期

        现在，有一些人还是在使用IDE来进行项目的配置管理的，它的缺点是什么呢？

1. 一般的IDE都拥有项目组织的功能。但是，可惜的是。IDE自带的项目组织功能往往比较弱，IDE采取的项目组织方式都是平行式的，没有项目的层次感，必须通过逐级命名来体现，比如foo项目下，有两个子项目，于是分别命名为foo.bar和foo.demo，同理再深一层为foo.bar.web等，项目完全平行化管理（结构未必一定是平行的，但是对于IDE而言，它们是平等的）
2. 现在流行的IDE对源代码控制工具都有非常不错的支持
3. IDE对同一个工作区里的项目依赖的控制作的非常不错，但是形式相对单一
4. 一般都是采用IDE自行手工构建，某些IDE可以给你提供Ant脚本（比如NetBeans），如果采用复杂的构建策略，那么要做很多手工的操作
5. 没法实现自动化构建，随着项目的增大，构建成本越来越大，构建和发布周期倾向于延长

       现在，大多数的Java开发人员都采取了使用Ant脚本进行构建的方式。因为Ant脚本：

1. 不会影响你的项目的组织方式，你可以随意的按照任何方式组织你的项目
2. Ant对源代码控制工具有很好的支持
3. Ant可以明确的管理和控制项目的依赖，通过Ivy可以自动下载项目依赖
4. 自动化批处理的方式
5. 支持构建服务器，可以实现每日构建

        但是，Ant脚本也不是一点儿问题也没有。首先，Ant脚本的重用性不好。一般意义上的Ant脚本重用，就是Copy&Paste。Ant对此没有什么封装。其次，Ant使用起来也比较困难，XML格式的脚本不是十分的好写（有了Eclipse支持以后，强了很多），作为脚本语言，Ant非常的不完善（连字符串处理的功能都非常弱，这一点Ant-Contrib提供了一些好一点儿的支持）。Ant的扩展机制完全基于Java，不能做到即时修改。

        除了Ant，在Java中，还可以采用Maven进行项目的构建。Maven项目是一个非常出色的项目。首先，它体现了Apache资深开发人员的项目组织和管理智慧。另外，它以统一有效的方式实现了项目的整个构建生命周期。Maven的黑盒化操作也给项目的配置管理减轻了负担。如果采用了Maven的话，项目的组织方式、项目的构建方式、项目的发布控制全部迎刃而解。而且你所作的扩展，也是以插件的方式来透明化的起作用的。重用性比Ant高很多。使用起来也非常简便。

       但是，Maven也并不是没有缺点。首先，Maven的项目组织方式是固定的，虽然这种固定的方式确实非常有道理。但是，如果与现有项目不兼容或者与IDE的项目组织方式不兼容的话，那么就完全不起作用了。比如Eclipse的Plugin项目，PDE的项目组织格式就与Maven2的项目格式完全不兼容。而且，Maven2自身的Manifest文件生成功能比较弱，对于OSGI项目而言，根本没有可用性（因为要造成重复工作）。由于Maven采用的是黑盒操作方式。操作不透明。你如果想作一些简单的自定义操作，也必须写一个Maven的插件。插件的测试、调试和修改都要比Ant困难得多。

       那么有什么好办法呢？我推荐采用Ruby。

       首先，Ruby是一种脚本语言，支持的环境有很多，而且还可以采用JRuby来运行。而且，Ruby支持一个类似Make语法的脚本语言，那就是Rake。

       Rake脚本其实就是标准的Ruby脚本，拥有所有Ruby拥有的特性（面向对象等）。而Ruby也有非常好的依赖控制系统Gem（我个人认为比目前的Maven的依赖控制系统要好）。由于Ruby是标准的解释型语言，所以操作都是非常透明的，也可以做到即时修改的效果。所以，用来作构建脚本是非常合适的。

      但是，怎么用它来构建Java项目呢？现在已经存在一个基于Rake的Java构建系统了，那就是：Raven。

      Raven除了提供一些处理Java的Rake Task之外，它还提供了对Maven Repository的Gem封装，这样，你就可以采用Gem的方式来获取Java的项目依赖了。

      Rake是我所看到的第一个用面向对象语言来写构建脚本的。但是，它也并不是完全没有缺点的，对Java的支持太少，就是一个很讨厌的缺点。

      如果想要采用Rake，而且还要做到象Maven那样好，那么至少要有以下几个功能（除去Raven已经提供的功能）：

1. 新项目的Archetype功能
2. Java项目构建生命周期模型
3. IDE支持
4. 根据源信息生成项目信息网站

     目前我能想到的办法只有一个，就是自己写（呵呵）。大家有什么高见？

1.     什么是软件项目开发过程模型

项目开发过程模型就是对于项目开发过程的概念建模，从而能够实现在理论上对于软件项目开发过程进行量化分析。

软件开发过程模型以 Rational Unified Process （简称 RUP ）为代表，如下图

图 1 、 Rational Unified Process

但是也并不是只有 RUP 一种，比如 Agile Unified Process ( 简称 AUP)

图 2 、 Agile Unified Process

总体来说， RUP 是最细化的项目开发过程模型，不管你采用什么样的开发方式，整个开发过程的每一个过程你都是无法逃掉的（我们后面会讨论这个），因为这代表了整个软件开发实践的客观规律，只是在定义上有所不同，侧重点上有所不同，对于迭代的看法有所不同罢了。

2.     为什么要关注软件项目开发过程模型

如同它的概念所示，软件项目开发过程就是对软件项目开发过程的概念建模，从而能够实现在理论上对于软件项目开发过程进行量化分析。

那么，这种量化的分析到底有能有什么好处呢？

我们在引子里说过：任何的软件项目都有它存在的目的，都是为了解决一些现实中的问题。可以把这个成为这个项目的目的，可以把需要解决的问题的需求称作这个项目的需求。

而对于商用（尤其是企业级应用）软件项目开发而言，最基本也是最重要的目的就是以最小的成本，在项目交付的期限内，提供稳定的、可靠的软件，用以解决用户提交的所需要解决的问题，并且如有可能，必须为现实生活中问题的变更引起的用户需要解决的问题的变更从而要求的软件功能的变更做好准备。

l         为了能够把客户的问题描述清楚，必须进行业务建模和需求收集；

l         为了能够把收集完的问题需求转变成为可以信息化解决的问题并且解决，必须对其进行软件化设计并进行实现；

l         为了保证软件产品的质量，必须进行足够多的测试（看看硬件厂商是怎么测试的？）；

l         为了能够让软件产品正常运转，必须进行软件的部署；

l         而在软件开发的过程当中，对于项目的管理、代码的管理、还有资源的管理，在哪一个软件项目开发中能缺少？

综上，对这些过程的建模和定量的分析，并且确定在整个开发过程中各个阶段所占的份额和所拥有的重要性，对于保证项目（尤其是大项目）的平稳开发和增强项目开发管理有着重要的作用。

并且，确定了项目开发过程模型，对于确定项目管理方式和提供技术、工具支持有着非常重要的作用。

3.     接下来要讨论的

既然我们已经有了一个明确的定义，并且能够把它分解成为几个部分（当然，我们将会看到，这些部分本身也是十分复杂的）。那么，看上去下一步，我们的任务就是一步一步的分析每一个部分。

但是，且慢，这些部分有些是没法讨论的（比如业务建模，它与用户的域专家有关，或者跟一些国家、国际标准有关，跟计算机软件开发没太多的关系——除非是 IDE 之类的），有些是仁者见仁、智者见智的部分（比如设计和实现），有一些可以不必花太多口舌去讨论（比如软件项目的部署和资源管理），这一点 AUP 给我们开了个好头，我们现在需要讨论的就是：

l         需求分析

l         测试

l         配置管理

l         项目管理

但就是这么几个，就足够我们讨论的。事实上，如果能够对这些问题都全面的分析并且提出自己的见解和解决方案的话，分量足够一个博士论文（起码重量上差不多），也许那样我可以出本书，呵呵，玩笑。

我只能尽力的往下分析，但是，我更希望的是大家能够有所反馈。因为，在软件设计中很多问题都是隐藏的（像地雷一样），直到你踩上它为止，你都不会发现它。

我很希望能够有反馈使我避免低级的错误。

任何的软件项目的开发都必然离不开了解需求、根据需求进行设计、根据设计进行实现这些过程。不管是多大的项目，也不管是采用何种开发方式。

 但是，设计的方式却有多种，没有谁会规定，只有采用UML图进行建模才叫设计。也没有谁规定，只有“设计”好了的项目才能开始代码实现。

一个人几天就可以完成的项目和几个小组好几个月才能完成的项目相比，它们面临的实际中的开发问题，和开发结束后面临的维护问题都是不可同日而语的。

而且，技术的角度上看，适合大的项目的开发方式也未必一定适合小的项目。

好了，说了这么多，我只是想说：

综上所述，软件开发过程是一个非常复杂的问题，对于做技术的人来说（尤其是做计算机软件技术的人），解决问题的方式只有一种，分析问题、根据问题设计解决方案、然后实现解决方案来解决问题（解决方案未必一定是软件）。