高内聚

最近一季度KPI中,增加了一项单元测试覆盖率

在之前工作经历中,也有过类似情况,老板开始关注单元测试情况了,就会加上覆盖率这个绩效指标,不管以前如何应对,还是再次关注了一些对于测试的文章,TDD虽然没有大流行,但这个概念还是常被人提起

这张图是在一篇文章中看到的

好写单测的系统往往比不好写单测的系统更加健壮,如果一个系统大部分代码都可以写无 Mock 单测,那么它看起来就像左图一样,外部调用只是薄薄的一层,可以随意更换。

如果你的系统大部分代码都一定要 Mock 才能测试的话,或者根本无法测试的话,就像右图一样,说明你的业务根本就没有自己的核心逻辑,而是和各种外部调用缠绕在一起

这张图让我有很多的感触,值得整理一下思绪

领域模型

这张图跟整洁架构图特别像

中心是核心的业务逻辑,依赖路径是由外向内,外围千变万化,但内核是不变的

不管是设计,还是编码,亦或是UT,都需要这样的思路;需要高内聚,核心业务代码不能分散,集中,有中心脉络

我们有时过多注重了技术层次,比如MVC,我们更多的是关注各层技术变化速率而分层,而忽略了业务层次变化

结合之前分析的《DDD分层》,也应该是三层,但不是MVC,面是是输入、领域、输出三层,类似端口适配器架构

向心力

这可能跟图的形状有关,因为是圆形。所以想到了向心力这个词,业务逻辑要内聚,单元测试也要内聚,当然了,单元测试的内聚是由于业务逻辑的内聚。

而这种高内聚,正合了向心力。没有向心力就是一群散沙,设计是,架构是,团队亦是

功夫在诗外

以前还写过一篇《功夫在诗外》,为了专业有所精进,就去看了很多专业无关的书,似乎方向搞错了,灵感不是平白无故地出现的,而是长年持续思考累积,再因为偶尔一件诗外之事激发,贯穿了之前的整个思考过程

以前看整洁架构那张图怎么没有如此些感悟呢,因为作为一名程序身在其中,但当看到测试内容时,因不是测试人员,身在事外看事,就有了感悟,所以功夫不能完全花费在诗外,也不能离诗过远,才能带来灵感

朱兴生 wechat
最新文章尽在微信公众号『码农戏码』