重构的一点看法

如果有这么一个项目你该如何去重构呢？

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

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

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

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

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

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

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

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