Blog

Blog

PHODAL

再说遗留系统重构

当你试图对工作方式进行这些改进时,政治斗争可能抬起它丑陋的头——《拥抱变革:从优秀走向卓越的 48 个组织转型模式》

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

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

可是呢,我发现很多时间重写并不能解决问题。

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

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

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

  • 创建重构防护网,保证重构过程的安全性
  • 可随时继续的重构演进策略
  • 评估
  • API 设计合理性评估
  • 模块分层架构
  • 架构合理度评估与对应的改进方案
  • 公共代码的拆分策略
  • 面向过程代码转面向对象
  • 代码坏味道识别与代码重构
  • 合适的设计模式替换旧的散弹式修改
  • ……

在先前提到的 5 种方式中,重构可以说是最难的一种。设计新的架构很容易,但是要重构到设计模式,重构到领域驱动设计,并不是一件容易的事情。

可最后,我们还会再回过头来看这些问题。我们的重点应该是:解决提出问题的人。正是那些能力不够的开发人员,导致了我们的系统需要一次大规模的重构。正确的做法,应该是在日常的开发中不断重构,并引入技术债看板,不断优化和解决这些技术债。

针对于此,我写了个指南来帮助大家重构遗留系统:https://github.com/phodal/migration

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签