23、代码依赖的深入剖析与可视化

代码依赖的深入剖析与可视化

1. DRY 原则的边界

DRY（Don’t Repeat Yourself）原则深入人心，开发者看到相似代码时，会喊出“重复代码”并进行重构，避免在多处修复相同的 bug。然而，DRY 原则可能会过度应用。每次重构代码时，会引入物理依赖，若代码库其他部分依赖此代码，就会产生耦合。一旦重构的核心代码需要更改，可能影响大量代码。

应用 DRY 原则时，不要仅因代码看起来相同就去重，只有当代码因相同原因需要更改时才进行去重。否则，重构后的代码可能因某个原因需要更改，但该原因与依赖它的其他代码不兼容，就需要在去重后的代码中添加特殊逻辑处理特殊情况，这会增加代码复杂度，降低可维护性和复用性。

2. 逻辑依赖

逻辑依赖是指两个实体有关系，但代码中无直接关联，这种依赖是抽象的，有间接层，只在运行时存在。以披萨制作系统为例，有三个子系统相互交互，若用箭头表示依赖关系，箭头为导入或函数调用时是物理依赖，也可在运行时不通过函数调用或导入来连接子系统。

假设子系统分布在不同计算机上，通过 HTTP 通信。披萨制作完成后，披萨制作器通过 HTTP 通知餐桌管理服务的代码如下：

def on_pizza_made(order: int, pizza: Pizza):
    requests.post("table-management/pizza-made", {
        "id": order,
        "pizza": pizza.to_json()
    })

此时，物理依赖从披萨制作器到