敏捷方法中有没有关于维护一个web系统的

两年前的一个web系统现在要进行维护，有些功能要添加
该系统构建时没有单元测试，不是TDD开发的
核心是自己设计的一套基于Servlet的小型框架，该框架内有许多JDBC存取数据库操作
该系统是基于该框架的实现各部分功能

我的想法是对整个系统先建立单元测试，然后一点点开始重构
还有，是从底层（该框架）开始重构
还是从JSP页面往下开始重构比较好

还有因为还有一程序员是添加功能的，那么在为原来建立单元测试时变重构边添加有没有问题

说的比较乱，总之就是如何为一个老的系统添加，同时使之利于将来的维护

用敏捷的方法重做一个

时间只有3个月，人员只有两个，不现实吧

我的问题是咱给它加上单元测试再重构成本和时间来不来得及
或者要重构的类就先优先加上测试

根据我的经验，如果你这样做来得及的话
重做就一定来得及

关键是你对系统的理解和把握
如果按照你的做法：要重构的类就先优先加上测试
你理解前任所编写的类及它和系统间的交互就要费很大的功夫

我以前接手一个项目也和你同样的想法

没有单元测试的程序并不一定就写的很差。
根据我的经验，重做一个系统总是比修改一个（已经能正常运行的）系统要花更多时间。比你原来以为要花的时间多得多。
不用给所有的类都加上单元测试，对增加新功能会影响到的类加上单元测试就可以了，毕竟时间有限.

我最近也在做这样一个项目。
这样的系统，一般原有功能也能正常运行。
但需要添加新功能和维护。而原开发的人员，
基本也不在了。文档资料，残缺不全。


推到重写一个完整可用的系统，一般不太可能。
接手的人大多并不非常了解老系统，
各种资料也不会很完整。一般来说，公司也不会同意。

对老系统写测试用例也是挺花时间的,全部覆盖我觉得
也未必有足够资源。

我的做法是，需要对哪一个部分添加新功能就先对
这部分原有程序加自动测试用例。
用例加完就开始重构。
重构完了原有程序，基本就整理完了这部分的程序结构，就比较容易加新功能了。
然后加新功能的测试用例，再实现新功能
，并重构以达到代码标准。

楼上二位误解我的意思了
我说的重做不是完全推倒重做
而是始终保持有一个可用版本的情况下
依次摘出系统中与其他部分耦合最小的部分
逐步重构
实际上最后还是全部重做了

这就不是个技术问题，而是个商业问题了。

flyingbug是怎么说服公司去资助这样一个
只是改善内部质量，而没有明显商业增值的项目呢？

有时候是被迫的，因为由于种种原因
过去的系统继续扩展和维护的成本太大（原负责人离职）
这实际上也是有增值的
另外在这个期间，我们也同时对控制方式和界面都进行了改进

当然这样做也是需要勇气和政治手腕的
选好操作时机，做好充分准备，就能达到目的