PS:本文只是先开个头,思考如何应对这种挑战。
如果只是从系统来考虑,标题里虽然说的是 “分布式” 规范治理,但是更多的时候是指多仓库的规范治理。而多仓库本身也充斥着一些不合理性,诸如于一个代码仓库内,可能包含着多个模块,如 monorepo。从这个角度来看,只是讨论分布式系统,可能有一些单薄。但是呢,我们在写规范,针对的是系统吗?难道不是团队中的开发人员?所以,我们所想的治理的是分布式协作的规范性问题。
对于软件研发来说,效能的提升是一个非常宏大的史诗级话题,在这个话题里,规范的建立是一个非常有效的方案 —— 当且仅当,我们建立了配套的相关执行机制和工具。在确保了拥有统一规范的情况下,A 团队的开发人员,可以快速地到 B 团队开发,而不需要一些额外的讨论。简单来说,规范就是一种用于规模化提升效能的模式。
多年前,对于软件开发的规范,我们主要依赖于口头约定 + code review,这依赖于团队拥有比较好的技术能力。应对于规模化时,这样的模式是无法实施的。特别是开发团队质量不齐的情况下,依附于个人的自觉,已经难于控制团队的质量。特别是,我们会因为越来越多的 quick fix,导致一次又一次性破坏系统的规范。
人们开发了一系列的 Lint、Checkstyle、守护工具,以确保我们设计的规范能被实施下去。诸如于:
于是,在单体系统里,上述的一系列情况得到了有效的改善,但是我们来到了微服务时代、微前端时代等,整体又发现了一系列的变化。为了应对于这种变化,我们还需要一些额外的工具,以确保这些规范化的工具能被安装和使用。
在那之前,让我们先总结一下规范工具化的时机,以明确我们应该在哪个时机来应对分布式下的挑战。
从模式上来说,我们通常会在如下的一些时机里,来检查软件是否符合规范。(按顺序排序)
从执行顺序来时机来说,越往前便意料着越能及早的发现错误,成本也越低。当然了,每种不同的时期,都应该有各自的重点。
时机 | 关注点 | 工具示例 |
---|---|---|
创建态 | 代码规范内建、规范执行机制、分层规范等 | 应用脚手架 |
开发态 | 代码规范 | CheckStyle 的 Intellij IDEA插件 |
测试态 | 代码规范、分层架构、API 规范等 | ArchUnit |
集成态 | 质量门禁 | Sonarqube |
运行态 | 服务依赖 | Skywalking |
当然了,还有一些是跨越了多个不同的时机,诸如于契约测试,它是在开发时期定义的,但是可能会在测试态、集成态才验证的。然而,在过程中,很大一部分的内容都是在代码中,由开发人员控制的。作为一个开发者,也是一个 hacker,我们会习惯性的:
这样一来,哪怕我们做了再好的规范设计,代码不,没有 code review 的保障,那么系统就会被进一步地腐化。
现在,让我们回到先前我们定义的分布式场景,思考一下如何在这种场景下,构建规范工具化?
对于这些规范来说,它们的工具化思路类似于,我们在《代码分析与自动化重构》所说的:源码分析 → 构建模型 → 识别模式 → 得到结果。为了支撑到分布式场景,一些潜在的方案便是:
去年,在设计 Guarding 这个多语言的架构守护工具时,其与 ArchUnit 相比的场景是:多语言、多代码库。与 ArchUnit 相比,Guarding 推荐的这种守护方式是:
当然了,它更多的是在测试态、开发态来解决问题。理想情况下,应该包含 IDE 插件,在开发时能提醒开发人员,系统架构有哪些问题。
虽然,我们可以构建一个基于“分布式”场景的规范,但是从某种意义上来说,这些规范是一种约束。对于开发人员来说,我们需要一种更好的指导指标,而不是我们破坏了哪些规则。所以,我们应该考虑架构适应度函数的方式,从多个不同的维度,来帮助开发人员:
也因此,从这个层面来考虑,单体系统里的 Sonarqube 就是一个非常好的工具。
最后,回到我们所推崇的敏捷实践,个体和互动高于流程和工具。让架构和系统知识能在团队中流动起来,远远比工具更加重要。