问老旧架构是边造轮子边优化，还是直接重构?

我觉得这个问题我们用一辆新旧车打比方最合适了，假如你有一辆旧车（老旧架构）。 如果边造轮子边优化呢，就像是你这辆车有些零件坏了或者不太好使，你就一个一个地去换更好的零件来让车能接着好好开。这样做的好处是车子（系统）一直能跑，不会一下子就瘫在那儿，业务不会受到太大的影响。而且你在换零件（优化）的过程中，还能慢慢了解这辆车（架构）到底是咋回事，不至于手忙脚乱。不过呢，这也有个麻烦的地方，就是你换来换去，可能最后发现这些新零件和旧零件拼在一起，还是有点小毛病，而且可能因为一直修修补补，有些地方还是挺乱的。 要是直接重构，就像是你不要这辆旧车了，重新造一辆新车。这样做如果成功了，那车（系统）就会非常棒，很符合现在的需求，而且也很整齐干净。但是风险也大啊，你在造车（重构）的时候，车肯定是开不了的（系统可能得停摆一段时间），这对业务影响就很大。而且造车的时候你要是有个小失误，说不定整辆车都报废了（重构失败）。 所以到底是边造轮子边优化还是直接重构，得看这辆车（老旧架构）现在有多破。要是还能开，业务也还能勉强维持，那可以先边造轮子边优化；要是这辆车已经破得不行，老是出大问题，业务都快进行不下去了，那可能就得咬咬牙直接重构了。

在考虑这个问题之前，可以再往前一步，请回答下老旧架构有什么问题，为什么要去优化或者重构它呢？

一切的优化和重构都是有代价的，有代价就要有人来买单，业务是不是认可这个工作的投入产出？

如果业务觉得现在的系统也能跑，问题也不大，可以苟着，那这个代价就要技术来承担，技术做这个事情的动力又是什么？

如果一路推导到最后就是这个事情要搞，大家达成了一致，那再来思考你问的这个问题。

我的建议是大部分情况下选择边造轮子边优化，而不是直接重构。有以下原因：

• 业务是在发展的，不可能停下来等你做完重构，过程中不提需求，这时如果是新老两套系统，这个需求可能就要做两遍。如果业务都不发展了，系统老就老了，也都不用重构。
• 技改需要投入产研资源，这些资源做了技改就没办法承接业务需求，会影响业务需求交付，而在业务视角，能接受技术做技改，但因为要做技改而大量影响业务需求，这个是接受不了的。
• 技改是伴随风险的，大系统分批改造上线，逐步迭代相比一次性改造上线的风险更加可控，而且能更快看到效果或者发现问题。

得视具体情况而定。

如果老旧架构的问题不算特别严重，业务依赖它的地方多且复杂，重构风险大、成本高，那可以先边造轮子边优化，逐步替换一些关键模块，在不影响整体稳定运行的基础上慢慢改善性能、拓展功能。

但要是老旧架构已经严重阻碍业务发展了，比如难以满足新功能需求、性能瓶颈太突出，而且团队有足够的人力、时间以及对业务理解较透彻，那直接重构可能更合适，虽然短期内投入大，但长远来看能打造出更契合业务且高效的架构。

所以要综合考虑业务需求紧迫性、现有架构复杂程度、团队资源等等多方面因素来考量。