再说遗留系统重构
source link: http://www.phodal.com/blog/rethinking-legacy-system-refactoring/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
当你试图对工作方式进行这些改进时，政治斗争可能抬起它丑陋的头——《拥抱变革：从优秀走向卓越的 48 个组织转型模式》
4 年前，也就是 2016 年，我一直在思索着如何更好的构建软件？如何更好的重写软件系统？思索出了 RePractise 七步曲，顺带着写了那本《全栈应用开发：精益实践》。书中，对于遗留系统的建议，便是 重写 。
而在我的最近一本书《 前端架构：从入门到微前端 》中，我提及到了五种前端架构的改进方式：更新、迁移、重构、重写、重搭。重写，依旧是我推荐的主要方式，技术栈老旧、旧有代码不规范。
可是呢，我发现很多时间重写并不能解决问题。
我总以为，编写软件的的人会随着年龄的增长，写出更好的软件系统。然而，软件开发者在经历到了 3 ~ 5 年的开发之后，有些成为了技术管理者，写不下去的转行了，还有的成为了销售……，还有如那个不断接锅的 Tech Lead。就好像韭菜一样，总可以吃掉新鲜的，总会由新的人来开发新的系统。所以，《重构：改善既有代码的设计》总是能割到一波又一波的韭菜 —— 那个会重构的人，代码写得少了。
时过境迁，我对软件开发又有一些新的领悟：重构比重写更有挑战性。或许是重写和新写没有区别，或者是经历了一个个系统的重构过程，我大抵是明白了： 哪来的和旧系统划清界线 。系统腐烂时，没有人能说清整个系统，甚至于一半的功能都相当的困难。与此同时，或许系统的用户对系统的功能比你更加了解。因为，你会从他们那收到 bug 的反馈：以前不是有这个功能吗，非常好用。
从旧系统中汲取知识，一个逃离不了的话题，一个永远的痛。系统重构并不是一个简单的活，我们要不断地平衡：业务开发与重构过程，并尽量保证业务优先。它涉及到一系列的软件开发实践：
- 创建重构防护网，保证重构过程的安全性
- 可随时继续的重构演进策略
- 评估
- API 设计合理性评估
- 模块分层架构
- 架构合理度评估与对应的改进方案
- 公共代码的拆分策略
- 面向过程代码转面向对象
- 代码坏味道识别与代码重构
- 合适的设计模式替换旧的散弹式修改
- ……
在先前提到的 5 种方式中，重构可以说是最难的一种。设计新的架构很容易，但是要重构到设计模式，重构到领域驱动设计，并不是一件容易的事情。
可最后，我们还会再回过头来看这些问题。我们的重点应该是：解决提出问题的人。正是那些能力不够的开发人员，导致了我们的系统需要一次大规模的重构。正确的做法，应该是在日常的开发中不断重构，并引入技术债看板，不断优化和解决这些技术债。
针对于此，我写了个指南来帮助大家重构遗留系统： https://github.com/phodal/migration
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK