随着时间的推移，软件项目将越来越大，组件之间的依赖性在项目中将变得越来越复杂，项目的维护将变得越来越困难。

（Java内存泄漏检测器）开发团队的博客文章揭示了开发过程中代码复杂度是如何演变的。

本文中的代码依赖图是由团队在项目开发过程中生成的，通过结构，开发人员可以定义一个规则来限制代码之间的相互作用和依赖关系，从而简化开发过程中的代码复杂性管理。但是，在PulBR项目开始时，不是使用结构，而是使用重组的产品来可视化项目中的依赖关系。然而，当后来的项目越来越大时，团队开始考虑使用结构。

严格来说，不是一个小的纠缠和胖意味着你的代码库更好。但是这两个度量有助于优化代码，例如，代码小块（小脂肪值）更容易理解，更少依赖（小纠缠值）代码更可预测，因此有更少的代码。代码中的缺陷，代码更容易维护。

故事开始于2011年初，当时代码库刚刚创建。正如你从下面的截图中看到的，代码中的缠结的数量非常少（图左上方的字符谱中的小黑济南网站优化点），这可以为未来的发展打下坚实的基础。但现实情况是，项目团队只写了几千行的源代码，还没有时间写更多的内容。

但仅仅6个月后，出现了一个不同的画面。如下图所示，脂肪数仍然很低，但依赖性开始变得混乱（见小黑点的纵坐标轴）。

6个月后，我们可以看到项目代码的脂肪数仍然很低，缠结数仍然很高。但是您可以看到一些包（分配、IO、生命周期）现在与混乱的代码库分离。事实上，团队使用结构101来管理LATT中的代码。呃，这个时期的一部分。

经过半年的工作，事情似乎走向极端。现在，除了依赖关系的混乱，代码的脂肪也相当严重。此时，项目团队开始充分利用结构101的产品来分析下面的图片，并问自己一些实用的。问题，如：

在发现问题之后，项目团队开始采取措施来优化它。正如你在六个月前看到的那样，所有新增的代码都已经清理完毕，对等组件（FS、HTTP等）之间的依赖性得到了改善。

一个星期前的图片，虽然代码基数比六个月前大25%，但是纠结数从39000减少到16000，使代码更干净、更结构化，而且项目团队的开发水平也得到了提高。d.

项目代码复杂度的管理应该贯穿项目，因此在项目结束时维护起来并不特别困难，或者您可以在开发过程中制定一些依赖规则并加以执行。

这个故事是一个小团队如何在相对短的时间内创建一个凌乱的代码库的一个很好的例子。你也可以想象如果一个10人开发团队开发了一个预期寿命为10年的项目，更终的项目依赖图会是什么样子。（编译）/ Wang Guo reviEW／张红月

你如何在项目开发中领先，而不是被项目中的其他东西拖垮你想听听丹尼尔的技术分享这段经历吗请关注CSDN和程序员杂志8月30日至31日联合举办的SCDC（中国软件开发者大会）。