这样的项目还有价值重构吗?

12-06-25 liujian1979
如果有这么一个项目你该如何去重构呢?

1.三个独立的项目使用一个数据库。数据库没有E-R实体模型,没有设计文档,也没有任何关系图,表之间没有外键关联(意味着逆向工程不可用),所有表关系、数据完整性和约束全部由存储过程控制(10年前这么干过,但今天居然又看见了,感概啊!)。

2.项目没有设计文档,只有一个接口文档,接口中有部分参数意图不明,也没有人能够解释意图不明的参数出现的理由

3.代码中没有任何注释,主要靠英文名字去猜。框架运用的是spring+mybatis,但spring+mybatis使用方式居然使之无法使用事务。也不支持任何的对象缓存,也没有设计查询缓存的调用。

4.也没有做到接口与实现类的一一对应,很多实现类调用一个接口,增加耦合度不利于扩展,而且需求变更接口一动全得动

5.代码中全是警告,没有工整性,代码俨然就是给机器读的,难于阅读和理解。

我在想这样的项目个人认为已经失去了重构的意义,因为需要动的地方太多,首先数据库、设计、代码基本都没有任何留用的价值。但公司领导一直发出的信息就是“数据库尽量延用!程序接口尽量延用”。我感到可怕,这样的项目有太多风险不可控了,怎么延用啊?

真正的重构首先要:基于代码易读、工整、严谨,代码测试的完善,数据库设计的合理和科学。其次就是才能按模块的逐步重构和修改。

数据库的混乱、代码基于机器可读,这样的项目还有重构的价值吗?

              

5
gameboyLV
2012-06-25 22:24
先按照核心业务进行领域建模,然后在把现有的代码按模块封装起来,作为领域服务,这样整个项目就能跑起来了

以后有时间再将老代码的逻辑重新实现,作为unitofwork。

liyao0409
2012-06-25 22:34
不应该轻易放弃以前的成果,虽然不容易维护,可能如果重写会丢掉业务中的一些精华。应该尽量修改,而不是重来

liujian1979
2012-06-27 09:44
这个项目的初衷是不让外界了解数据库的任何东西,对外提供API调用,但实质做成除了数据库的DBA没有人了解数据库表结构和表的关联关系,这个对做服务器端应用层的开发人员造成很大障碍。任何对数据库的操作都调用存储过程,这种障碍必须打破!

chanball
2012-06-27 13:01
2012-06-25 11:18 "@liujian1979"的内容
真正的重构首先要:基于代码易读、工整、严谨,代码测试的完善,数据库设计的合理和科学。其次就是才能按模块的逐步重构和修改。 ...

这是理想状态下的重构,事实上有多少项目是这样呢

猜你喜欢
2Go 1 2 下一页