遗留系统的现代化演进是一门艺术。
在日常的软件开发里,我们经常会遇到一系列的问题,诸如于:
应对于这些问题,其中的一个解决方案就是:自动化的工具,有些人喜欢称之为器。支撑这些工具的便是一系列的原则与模式,将它们融入到工具之中。另外一个解决人成长的方案就是:元元(meta-meta),这是另外一个故事。
遗留系统是常态。在咨询团队里,我们所遇到的系统里多数是是遗留系统,来到一个新项目时,可能就需要对他们快速的分析,以提供洞见 —— 写 PPT 汇报。所以,在过去的几年里,咨询团队也沉淀了一系列的遗留系统分析和重构的工具,比如新哥的 Tequila、正在开源的架构分析和守护工具 ArchGuard 等等。除此,在有些重构项目里,还要编写定制的工具来进行分析,诸如于先前覃宇和俊斌等所写的「移动应用遗留系统重构」 系列。
技术热情发电。对于 Thoughtworker 而言,写工具的最大挑战并不在技术上,而是版权问题:你的工具是否受客户启发?不过,在这里我们开发写的主要是代码分析工具,基本上是不存在这方面的问题的。除此之外,另外一个挑战则是:你需要拿自己的业余时间来完善工具。你不能用客户 billable 的时间来做这样的事。
既然要用自己的时间来开发,还和项目没有关系,这种用爱发电的事情,用开源的方式最合适了。
从对于使用工具的结果来看,我们需要这个现代化工具是:
这里定义的遗留系统现代化工具包含了这么几部分:语法分析、结果及可视化、自动化重构、架构守护。
对代码进行语法分析,生成特定的语言的数据结构。常用的工具有:Antlr、Ctags、TreeSitter、Doxygen、CodeQuery 等。一个大致的对比(拍脑袋订的)如下表所示:
工具 | 精准度 | 开发难度 | 跨语言学习成本 | 添加新语言成本 | 可自动化重构 |
---|---|---|---|---|---|
语言编译器 | 完美 | 低 | 高 | - | Yes |
Antlr | 极高 | 中 | 中 | 中 | Yes |
Ctags | 中 | 低 | 低 | 高 | Yes(成本高) |
TreeSitter | 高 | 高 | 中 | 高 | Yes(成本高) |
Doxygen | 中 | 低 | 低 | 高 | No |
CodeQuery | 高 | 中 | 中 | 高 | Yes |
通常来说,我们会出于以下的一些情况,来对遗留系统进行可视化:
这一步是可选的,它取决于我们的场景。通常来说,编写这样的功能主要弥补是现代化的 IDE 无法完成的工作,诸如于:
编写架构的守护规则,以对于系统的架构进行守护,用的工具有:ArchUnit、ArchGuard 等。在参考了 ArchUnit 的语法之后,我们也设计了一个多语言的架构守护工具:Guarding。
后续,我们将针对于这四部分的每一部分,展开详细的介绍。在开发这些工具的过程中,它们也不断地 push 着我进一步学习语言背后的东西,如编译原理(语言的前端部分),理解构建系统(build system)等。
为了更有针对性地对遗留系统进行现代化,最近我们创建了一个新的组织:Modernizing,集合了先前开发的一系列工具。并创建了:awesome-modernization 用于对其它的一系列相关的工具进行收集。
在 Modernizing 里,针对于单个编程语言的工具有:
针对于多语言的工具,我们有:
除此,还有一个在 Inherd 开源小组下开源的:Coco,它主要是通过代码的物理属性:修改频率 + 目录 + 行数来分析系统的工具。以及现在紧锣密鼓开源中的 ArchGuard。
我们使用一系列不同的语言和工具来开发这些软件,因为不同的场景之下,都会有不同的选择。
现有的工具都是分散的,不同工具之前的数据格式不尽相同,缺乏统一的数据格式。在输出格式不统一时,我们就难以进行标准的可视化,诸如于我们正在构建 codecity 用于在元宇宙里,对遗留系统进行可视化,又或者是正在从 ArchGuard 中拆分的前端可视化部分,以用于复用。理想的情况下,它应该像是一个 pipeline 架构的系统,由一系列的 pipe 和 filter 所构成。
围观我的Github Idea墙, 也许,你会遇到心仪的项目