最近看到了两篇文章,都是说系统重构/改造/升级的。一篇是《互联网架构实践:给飞机换引擎和安全意识十原则》,另一篇是《知乎社区核心业务 Golang 化实践》。这两篇虽然侧重点不同,但都涉及到一件事情:重构项目的项目路线。第一篇文章提出了三种重构方式:彻底重新做,直接从前到后抛弃老系统;大规模重构,保留对用户的这层皮,后面从服务到数据全部替换;小规模重构,保留对用户的这层皮以及数据结构,逐一替换核心逻辑到微服务。虽然原文是根据重构的彻底性来说的,但这三个划分其实也是三种项目路线。知乎的Golang改造选择了“大规模重构”的思路:保持新服务对外暴露的协议(HTTP 、RPC 接口定义和返回数据)与之前保持一致(保持协议一致很重要,之后迁移依赖方会更方便);并且在重构早期新的服务没有自己的资源,使用待重构服务的资源。然后通过功能验证、灰度放量等方式逐步将老服务切到新服务上。
如果是我,我也会选择这样的路线。因为我以前用第一和第三种方式做重构时,都遇到了很大的问题。
先说第三种方式。小规模重构会面临进退维谷的两个问题。如果我们没有一个完整的业务和系统架构设计,那么零敲碎打的重构改造对系统的优化作用和性价比实在有限:船都进水了,刷刷甲板擦擦灯罩也改变不了什么。而如果我们拿出了完整的架构设计,小规模重构往往就满足不了整体重构的需要,而必须升级为大规模重构了。所以,小规模重构在整个系统的层面上比较鸡肋;它比较适合于针对某个单独功能点的优化。当然,这种方式也并非一无是处。它能够延缓系统腐化的趋势,也能帮助项目团队提高能力和增加经验。总之,在系统架构稳定之后或是大规模重构之前,小规模重构还是大有可为的。我之前参与过的一个重构项目中,项目团队在系统级别的重构完成之后,还在持之以恒地对一些小功能、小细节进行重构,就我所知,这个系统目前无论在业务上还是在技术上,都非常的健康。
对系统级重构来说,小规模重构有点像缘木求鱼,虽然抓不到鱼,倒也没有什么大的坏处。彻底重做却有点像饮鸩止渴,很多时候不仅无法达成目标,还会埋下重大的隐患。最主要的隐患是新系统的技术、业务架构都要在全部开发完成后才能得到验证。这会导致风险都被压缩到了测试和验收阶段这两个阶段中:这时已经是上线前的倒计时阶段了,加上开发阶段在所难免的延期,时间往往非常紧张。在这样短的时间内尝试检查和解决大量风险,其中的问题是不言自明的。有个同事总结说,这个时候发现问题了,系统上线要延期;没发现问题,往往更要延期——因为积压了太多的功能和代码需要测试验收,没有问题比有问题更让人觉得心慌。此外,新系统上线之前老系统发生业务需求变更也是不容忽视的一个问题。新需求会扩大新系统的范围,进而影响开发、测试和验收的工期,最糟糕的情况下还可能迫使新系统修改技术或业务架构:这样的后果就不堪设想了。我参与和见识过两个这样的项目,在团队成员辛苦忙活了半年、一年以后,系统却因为种种问题、风险而一再延期。
曾经有同事在讨论中提出用最快的速度、最短的时间把新系统推上线。这样,测试验收的时间比较充足;通过快速试错的方式来修改发现的问题;而且这样还可以避免出现第二个问题。这样做似乎可行,但我认为这种“快速试错”的方案并不可取。首先,老系统为什么会腐化到非重构/重做不可的地步的?长期地只重速度不重质量、“先上线再说”的开发模式难辞其咎。在市场快速扩张、业务快速增长阶段这样取舍还情有可原,在专门拿出时间精力来做重构时仍然一味地“唯快不破”,岂不是要重蹈覆辙、欲速而不达?其次,快速试错是在市场方向、业务需求不明朗的情况下,有一丝“无奈的”试探性做法。但对业务系统重构项目来说,功能需求和性能指标都可以从老系统中总结、提炼出来。在可以看清楚道路的情况下还要闭着眼睛“快速试错”,非常的得不偿失。
彻底重做的方式有点类似瀑布式开发模式,可能只适合于一些规模较小、功能简单或者功能长期不变的系统。对大型的、复杂多变的业务系统来说,更合适的方式应该是更接近敏捷开发的大规模重构。这种重构的路线可以参考《知乎社区核心业务 Golang 化实践》。与小规模重构相比,大规模重构有一个更加全局的、完备的规划,每一个模块、每一个功能的重构既是对原有功能的优化改造,同时也是更大蓝图中的一块拼图。与彻底重做相比,大规模重构更加的敏捷:新系统的风险和问题会在逐步替换的过程中暴露和解决,从而避免了近在咫尺时才发现冰山的可怕场景。而且,在重构过程中遇到新需求,我们也有了更好的解决方案:我们可以先对相关模块做重构,然后在重构后的基础上做新需求。这样技术业务两不误,开发和产品也皆大欢喜。
哲学中有一个“忒修斯之船”的命题:把忒修斯乘坐过的船上的每一块木板都换成新的,最后这条船还是忒修斯的那条船吗?相比这个哲学命题,我更喜欢研究如何对那条船进行翻新修缮:小规模重构就像是在风雨飘摇的大海上刷洗甲板、修理护栏;彻底重做是在船坞里建造一条新船;大规模重构则是在航行过程中把小木船逐步升级改造成大航母。就我而言,无论是期望还是经验,我都愿意选择大规模重构的方式。
联系客服