随着软件项目规模的不断扩大，项目管理的作用变得越来越重要。如果一个需要长期维护的项目不能得到很好的管理与控制，“软件腐败”就会发生，用不了多久，我们的程序可能就会像一团拌好的炸酱面一样难以找到头绪，维护的成本也会不断增加。为了避免这种现象的发生，一方面我们需要对程序定时的进行重构，使其回到有序化的轨道上，另一方面需要良好的监控以及管理，使其尽可能长时间的保持“新鲜”而不至于腐败。

随着技术的发展，新的管理技术以及管理理念不断涌现。版本控制、单元测试、以及项目自动化这三大技术现在已经成为很多软件项目赖以成功的基石。

  版本控制

为什么要使用版本控制系统？

Ø 给团队提供一个项目级别的撤销按钮

Ø 记录着项目每时每刻的改动

Ø 使得多个程序员可以有序的同时为一个项目写代码

国内早期的版本管理多数使用Microsoft的Visual SourceSafe6.0简称VSS，使用这种管理方式多数是单线的管理方式，虽然VSS也提供一些分支与共享功能，但是它的性能低下，而且经常会出现问题，其可用性不高。其主要的版本管理模式如下图。

    图1：VSS中的代码仓库生命周期

中间的方块显示了我们代码仓库的状态，在最开始只有一个主干（标准版）程序，我们把这个程序应用于项目1的时候，可能会发现一些新需求或者新BUG。然后我们在代码仓库上进行修改，把这些改动签入了版本库，这时我们的标准版仍有可能在改动，程序员可能会为标准版添加一些新特性（用*表示改动了），这就意味着版本可能出于一种不稳定的状态，新特性可能短时间内不能达到可以发布的状态，这时给项目1的团队更新程序（即发布新版本）时就要把这些不稳定的新特性代码过滤掉，再进行发布，当多个项目同时使用这个代码仓库时，会造成了一个目录中实际叠加了多个项目的代码。这是这种早期版本控制方式的主要缺陷。在VSS之后出现的CVS（Concurrent Version System）软件统治了版本管理领域相当长一段时间，CVS针对VSS存在的问题做出了一定的改善，但是仍不能满足需求。最终Subversion（简称SVN）出现了，总结了CVS的长处，改进了不足，力图成为CVS的接班人，它也的确做到了。现在几乎主流的开源组织，以及提供网上代码仓库的网站都在使用Subversion，他们包括鼎鼎大名的Apache Software Foundation、Google Code、SourceForge.net等Subversion中分支是非常重要的概念。Subversion认为：开发者应该使用分支把与主线开发（标准版开发）具有不同生命周期的代码（如各项目的发布版）从主线中分离出去。Subversion中项目具有如下的结构。

    图2：Subversion中代码仓库的生命周期

程序员们在主干目录上进行开发。当代码已经处于比较完善的状态时，决定发布它并在项目1中使用。这时我们应该在分支目录中为主干目录创建一个分支（在Subversion中即一个拷贝）并打上一个标签（如XX月XX日发货，打标签在Subversion中也是一个拷贝），然后项目1的工作组负责对这个分支进行维护，而主要的开发团队仍在主干上进行开发。这样主干和项目分支物理上处于不同的目录，各自有独立的生命周期，程序员对主干的标准版程序添加代码不会对项目1造成影响，项目1分支中的代码将会保持相对的稳定，对项目1的修改也可以有选择的转移到标准版中（这个转移混合的过程在Subversion中是非常容易实现）。各个版本不会互相混淆，随时可以取得各个发布版本。在Subversion中，分支主要用于发布、BUG修正、以及技术试验。除此之外Subversion还提供了很多很好的特性，如：

1.所有的文件统一使用一个版本号，这样每一个版本号在项目生命周期代表一个切片，保留了一个一致性的快照。

2.支持多人同时迁出一个文件，只要不同时修改同一行，Subversion都可以智能的进行合并，如果在同一行上存在冲突，Subversion会提示你解决他。你也可以锁定这个文件以避免其他人签出。

3.一次提交不管是单个还是多个文件，都是作为一个整体提交的，在这当中发生的意外例如传输中断，不会引起数据库的不完整和数据损坏。

Subversion的理念与VSS是不同的。使用VSS的感觉像套着沉重的枷锁，而Subversion更像是是一个轻巧的拐棍，帮助你将项目不同的版本管理的井井有条。