代码腐烂的元凶：不是技术债务，是耦合

你以为系统崩是因为代码烂？错了。问题在模块之间的关系——而这个关系，有个听起来很无害的名字：耦合。

很多程序员以为代码质量差是"写的问题"。其实大部分系统死掉，不是因为某个人写了烂代码，而是因为模块之间的关系乱成了一团毛线。你改一个模块，另一模块莫名其妙挂了。再改，再崩。最后没人敢动。

这就是耦合在作祟。

七种耦合，从"完全不熟"到"直接私奔"

耦合听起来抽象，其实就是问：两个模块之间，谁知道谁多少？

按严重程度，从低到高排是这样的：

两个模块完全不直接通信，必须通过主模块转发。比如A模块和B模块完全不直接说话，都找C协调。

这种情况独立性强，但实际系统里几乎不存在。因为完全解耦意味着没有直接调用，这在真实业务里是不可能的。

A调用B，只传参数。比如getUserName(userId)，只传一个ID，返回名字。

简单数据往来，不牵扯复杂结构。这种耦合是工程实践中应该追求的日常状态。

A调用B，传递的不是简单参数，而是一个数据结构或对象本身。

比如传一个User对象，而不是userId。表面看是"一次传完省事"，但这意味着A需要知道B期待什么格式。一旦B改了User结构，A也得改。

你以为自己是在传数据，其实你是在传一个定时炸弹。

一个模块直接告诉另一个模块"你应该怎么做"。比如传一个控制标志isAdmin=true，B看到这标志就知道该做什么逻辑。

这时候两个模块不是"我给你数据、你处理"，而是"我在指挥你"。

所有模块都访问同一个全局变量。比如大家都在读CONFIG.settings。

这事儿太常见了——CONFIG对象到处扔，到处改，到最后没人知道谁改的、为什么改。

几个模块共享一个全局数据结构，比如同一个共享内存区域或全局数据库表。

一个模块写了，另一模块立刻能读到。听起来爽，但只要有一个模块修改了数据格式，其他全部中枪。