Blog

Blog

PHODAL

谈系统重构的未来:重构工具 Coca 一周年

一年前,在公司大佬的指点之下,我开始写系统级重构工具 Coca (https://github.com/phodal/coca) 。哦,不,不对,是刚开始学习 Golang,因为我的第一次提交是从一个 Go 的 hello, world 写起的。

commit a685d69080a7abde684e1d0707cbf410092e3173
Author: Phodal HUANG <h@phodal.com>
Date:   Tue Oct 22 23:01:19 2019 +0800

    first commit

commit c6b5a0c7f174c6a0ba233a1356aca5c370ba4315
Author: Phodal HUANG <h@phodal.com>
Date:   Tue Oct 22 23:06:04 2019 +0800

    learn: add hello world

时过境迁,这个小工具已经不小了 —— 即使是这个项目的作者,我也要看我写的 README,才会想起来有这么一些功能。这一年来,根据我的一些工作上的需要,陆陆续续地也添加了一些颇为有意思的特性。这些小特性除了不限制编程语言,还可用于指导重构,还可以用于写 PPT 的时候讲述故事:

  • 高频修改文件查找
  • 包结构分析(不限于 Java,大部分的语言是以目录划分包结构的)
  • Todo 分析(可结合历史)

当然了,如果你的系统是 Java 语言主导的话,那么 Coca 能提供更强有力的支撑,具体见:https://github.com/phodal/coca 。只是呢,不管我们使用的是什么工具,我们方法论都是类似的。也因此《系统重构与迁移指南》(https://migration.ink/) 成为了系统重构不可多选的材料,Google 『系统重构』 和 『重构工具』会有惊喜。

系统的必然之路:系统重构 or 重写

没啥说的,部分的系统都是要被重构或者重写的。那么另外一部分呢?他们被淘汰了——要么是产品,要么是公司,笑~。

真相就是这么简单。如果系统不被指南,和进行频繁的代码级重构的话,那么系统被取代的速度就更快了。

重构 vs 重写

关于系统级别的重构,我们先要讨论的第一个问题其实蛮简单的:我到底是要重构还是重写?选择哪个主要取决于:你要的是技术挑战,还是业务挑战?

哦,不,不对,它取决于你要的是 KPI 是技术 KPI,还是非技术 KPI? 说白了,就是价值决定了一切。

对于重构而言,我们所要面对的是技术挑战;对于重写而言,我们所面对的是业务挑战。

重构的技术挑战

我们所面临的主要技术挑战是:

  1. 是否能确保过程的安全性?如何设计测试防护网
  2. 是否能想到更好的设计来取代现有的方案?
  3. 如何做一次有效的分析与评估?
  4. 如何渐进式的重构系统?如何保持小的、快速的提交
  5. 怎样支持未来业务的可扩展?即,支撑业务可扩展性
  6. 是否寻找最合适的重构技巧?比如通过 IDEA 的重构
  7. 如何让重构技能被传承?即,多数团队成员都能快速上手
  8. ……

重写的业务挑战

与重构不同的事,重写时的挑战主要是来自于梳理现有业务:

  1. 如何体系化的整理现有的业务?
  2. 如何剔除已淘汰的业务?
  3. 如何确保主干业务的完整性?
  4. 是否能确保细小的业务功能不被遗失?
  5. 能否设计出更完善的业务知识管理体系?

系统重构的未来

在 Coca 编写完成之后,我发布了《系统重构与迁移指南》一份短小、精悍的重构手册。从这个手册快速的自然增长率(GitHub star 指标,没有经过大量宣传),并且已经在 Google 的相关关键字下(如系统重构、重构策略等)排名第一,我发现了人们缺少一份这样的指南和工具。

所以,在未来一定会有更多的相关工具诞生,并配套有大量的实践指南。

方法论支撑

在开始重构之前,我们需要设计出可行的重构方案,这也就是方法论的支撑。

对于重构的方法论来说,实现上我们已经可以在市面上找到大量的相关书籍,只需要结合起来看就可以了:

  • 《重构与模式》
  • 《设计模式:可复用面向对象软件的基础》
  • 《重构:改善既有代码的设计》
  • 《领域驱动设计:软件核心复杂性应对之道》
  • 《修改代码的艺术:构建易维护代码的 9 条最佳实践》
  • 《代码整洁之道》
  • 《架构整洁之道》
  • 《数据库重构》
  • 《遗留系统重构指南》
  • 《前端架构:从入门到微前端》

工具支撑

市面上,已经充斥着大量代码级重构的工具,如 JetBrians 系列的 IDE。但是,对于系统级重构来说,基本上很少有工具可以直接能支撑现有的系统,哪怕是 Coca 也是有限的支持。主要原因就是:大部分的内部系统都绑定了组织中的模式。特别是对于大型组织来说,它们往往配套开发了自己的底层架构和 API。

也因此,对于系统级别的重构来说,我们要优先考虑的是定制一个工具,又或者是基于开源工具进行扩展。

操作指南支撑

同样的,我们也很难在市面上找到这样的指南,因为对于大部分的公司和团队来说,重写是更好的 KPI,而重构并不会带来如此丰富的价值。除此呢,对于有过重构经验的团队来说,他们也不一定会共享出自己的经验——受能力和保密协议影响。

于是乎,我开始不断丰富我的指南《系统重构与迁移指南》。

其它

软件开发总成本 = 开发成本 + 维护成本;软件维护成本 = 理解成本 + 修改成本 + 测试成本 + 部署成本。—— Ken Beck

关于我

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

微信公众号: 与我沟通

标签

最近的一些事

  • 最近我和我的同事们,一起在创建一个新的编程语言:Charj 。它是一个使用 Rust 编写的描述式、中间编程语言。GitHub: https://github.com/charj-lang/charj

    Nov. 14, 2020, 9:27 p.m. | China