再说遗留系统重构

4 年前，也就是 2016 年，我一直在思索着如何更好的构建软件？如何更好的重写软件系统？思索出了 RePractise 七步曲，顺带着写了那本《全栈应用开发：精益实践》。书中，对于遗留系统的建议，便是重写 。

而在我的最近一本书《前端架构：从入门到微前端》中，我提及到了五种前端架构的改进方式：更新、迁移、重构、重写、重搭。重写，依旧是我推荐的主要方式，技术栈老旧、旧有代码不规范。

可是呢，随着岁月的流失，我发现重写并不能大部分的解决问题。

我总以为，编写软件的的人会随着年龄的增长，写出更好的软件系统。然而，软件开发者在经历到了 3 ~ 5 年的职业编码之后，有些成为了技术管理者，写不下去的转行、在线炒粉去了，还有的 return true 成为了销售……，剩下的，还有那个不断接锅的 Tech Lead（还在继续写代码）。就好像韭菜一样，总可以吃掉新鲜的，总会由新的人来开发新的系统。所以，《重构：改善既有代码的设计》总是能割到一波又一波的韭菜 —— 那个会重构的人，代码写得少了。

时过境迁，我对软件开发又有一些新的领悟：重构比重写更有挑战性。或许是重写和新写没有区别，或者是经历了一个个系统的重构过程，我大抵是明白了：哪来的和旧系统划清界线 。系统腐烂时，没有人能说清整个系统，甚至于一半的功能都相当的困难。与此同时，或许系统的用户对系统的功能比你更加了解。因为，你会从他们那收到 bug 的反馈：以前不是有这个功能吗，非常好用 —— 用户可能会骗你，他/她经常用那个功能，但是那个功能是存在的。

从旧系统中汲取知识，一个逃离不了的话题，一个永远的痛。系统重构并不是一个简单的活，我们要不断地平衡：业务开发与重构过程，并尽量保证业务优先。它还涉及到一系列的软件开发实践：

也因此，在先前提到的 5 种方式中，重构可以说是最难的一种。设计新的架构很容易，但是要重构到设计模式，重构到领域驱动设计，重构到整洁的架构，并不是一件容易的事情。你需要持续不断地练习，但是这样的机会并不多。

可重构到最后，我们还会再回过头来看这些问题。我们的重点应该是：解决提出问题的人。正是那些能力不够的开发人员，导致了我们的系统需要一次大规模的重构。

那么，正确的做法，应该是在日常的开发中不断重构，并引入技术债看板，不断优化和解决这些技术债。故而，技术债管理优于重构。