技术相关

Golang 代码耦合与内聚分析

这篇文章是我让Gemini Deep Research生成的，前面写的有些啰嗦，整体看完后依然有些收获。一个工程代码做到“高内聚低耦合”其实只要做好“高内聚”，“低耦合”是其自然结果。想做到“高内聚”的最简单方法，就是坚持遵循“单一职责”原则。

如何判断代码的耦合程度？可以从函数是否方便进行单元测试的方向进行思考判断。要充分利用Go的Interface，鸭子类型的特性让Go语言天生就能很好的做到“低耦合”。

依赖注入原则，一句话概述就是：让函数的依赖都通过参数传入，而不是在函数内部创建。了解到了 Google Wire 这个自动 DI（Dependency Injection）的工具。

上面都是从代码层面，也就是偏微观的视角看这个问题。除此之外，也要考虑项目宏观上看待问题，其中之一就是包结构，应该按功能（领域）划分包，才能使得不同功能之间的耦合被最小化。

文章最后提及了终极解耦方式：事件驱动架构。此方面仍有待进一步学习。

To myself： 未来还得加强对 Interface 的了解和学习。

Increasing Cohesion in Go with Generic Decorators

读完了这篇标题名为《使用通用装饰器增强 Go 语言的内聚力》文章，也仔细看了一下仓库里的示例代码，确实是一层比一层内聚度更高了，函数职责更明确，复用性也高了。其实这里说的装饰器（@decorator）和Python中的一个原理，使用外层函数包裹内层函数，外层函数的代码执行完后就会立即执行内层函数的代码，不过这在Go语言中实现起来确实很难绷，有种写Java的代码的既视感 （又臭又长） 。而且阅读起来跳跃很大，需要在多个装饰器文件直接反复横跳，所以这种设计模式在生产环境的被接受度还是毁誉参半。

话又说回来，对于业务上那些通用的代码块，例如前置校验、后置Trace、耗时记录等等情况，都是可以被类似装饰器这种设计模式优雅处理的。可以考虑使用中间件模式、AOP等阅读更友好的设计方法。