改进旧代码库的推荐路线：走向可扩展可维护系统的11条经验(2)

如果上述工作都已经完成,你可以再次拥有可靠且可维护的代码库,您可以选择更改数据库 schema 甚至替换数据库.已经完成的上述工作都将有助于您以无负担的方式进行变革,而无需担心任何意外,您可以使用新的代码和所有的测试来测试新的数据库,以确保您的迁移没有任何问题.

在路线图上前行

恭喜,到这里您已经走出了丛林,现在已经准备好可以实施任何新功能了.

不要尝试彻底重写

彻底重写是一种几乎保证会失败的项目.一方面,你是在未知的领域开始,你甚至会不知道要重构什么,另一方面,你也将所有的问题推到最后一天,就在你用新系统启用之前的那一天.很悲剧的是,那也是你失败的时刻.业务逻辑的假设最终会证实存在问题,那时您将突然了解到为什么旧系统会用某种奇怪的方式来工作,最终也会意识到能将旧系统放在一起工作的人也不都是白痴. 如果你真的想要将公司(以及你自己的信誉)带向一个泥潭,就来一个彻底大重写吧,但如果你足够聪明,彻底重写系统通常不会成为桌上的一个讨论选项.

替代方案：迭代式改进

要解开这些线团最快方法就是从你已经理解的代码入手(它可能是一个外围设备,但也可能是一些核心模块),并在它的旧的上下文的范围内尝试逐步改进.

如果旧的构建工具不再可用,您将不得不使用一些技巧(见下文),但至少在您开始更改时,尽可能多地保持旧的系统工作.一个典型的提交通常只包含数行代码.

发布!

所有修改尽可能发布到生产环境,即使修改的代码是最终用户不可见的,因为当你对系统了解不足时,只有生产环境才会告诉你新的修改哪里会有问题.如果这个问题只是在小的改变之后出现,你将获得几个优势：

• 很容易弄清楚出了什么问题
• 您将处于改善流程的良好状态
• 您应该立即更新文档,以记录获得的新见解

合理使用代理服务器

如果您正在重构一个 Web 系统,感谢上帝,你可以在最终用户和旧系统之间部署一个代理服务器.您可以精确控制每个 URL 哪些请求进入旧系统,哪些请求路由到新系统,从而可以更轻松,更精细地控制运行的内容.

如果您的代理足够强大,您甚至可以控制将某个 URL 一定百分比的流量发送到新系统,以便观察新系统的运行情况.如果您的集成测试也能够连接到这个代理那就更好了.

很有道理,但这一切需要太多的时间!

那么这取决于你如何看待它.如果按照这些步骤确实存在不少工作,但是它的确有效,而且这个过程的任何优化都让你进一步彻底了解整个系统.我个人在这方面也有一个很好的声誉,我真的不希望这样的工作中出现任何负面的问题.

有时候如果公司系统已经出现问题,而且可能会影响客户时,如果按照这个流程可能使事情好转,我宁愿完全控制和和使用这个过程,而不是为了表面的节省几天或几周的时间的方式.如果你更多地是牛仔的做事方式,你的老板也同意 —— 那么也许那是可以接受的高风险方式,但是大多数公司宁愿采取稍慢一点,更稳健的重构之路.

原文链接：https://jacquesmattheij.com/improving-a-legacy-codebase
文章来自微信公众号：高可用架构

（编辑：ASP站长网）