随着时间的推移，软件项目会变得越来越大，项目中组件之间的依赖关系也会变得越来越错综复杂，项目的维护也会变得越来越困难。
Plumbr（Java内存泄露检测器）开发团队的一篇博文揭示他们这个项目在开发过程中，其代码复杂性是如何演变的。
本文中的这些代码依赖图是该团队在项目开发过程中使用Structure 101来 生成的。通过Structure，开发者可以定义一个规则来约束代码之间的交互和依赖关系，从而简化开发和重构过程中的代码复杂度管理。但在Plumbr 项目一开始，并没有使用Structure，只使用了其中的Restructure产品来可视化项目中的依赖。但在后面项目越做越大时，团队才开始考虑使 用Structure。
Restructure使用如下两个指标来表示代码的质量：
- Tangle（混乱度）：用来表示代码构件（比如包、类）之间的关系是否错综复杂
- Fat（肥胖度）：用于表示单独的类、包是否庞大且杂乱
严格来说，并不是Tangle和Fat数值小就意味着你的代码库比较好。但是这两个指标确实能为你的代码优化工作带来一些帮助，比如规模较小的单个代码片 （Fat数值小）更容易让人理解，依赖关系少（Tangle数值小）的代码更具可预测性，这样的代码中的bug就会更少，代码也更容易维护。
下面就来看看Plumbr项目代码的复杂性的演变。
故事始于2011年初，那时刚开始创建代码库。从下面的截图中可以看到，代码的Tangle数非常低（图左上角色谱中的小黑点），可以说这为将来的开发工作打下了一个坚实的基础。但实际情况是，项目团队仅仅只写了几千行源代码，还没来得及写更多东西。
但是只过了6个月，就呈现出了不同的画面。如下图所示，Fat数依然很低，但是依赖关系已经开始变得混乱（看小黑点的纵坐标轴）。
又过了6个月，可以看到项目代码Fat数依然很低，Tangle数依然很高。但是你可以看到一些包（allocation、io、lifecycle）现在已经从混乱的代码库中独立了出来。其实，该团队在这个时期的后段使用了Structure 101来管理代码。
又过了半年时间，事情似乎走向了极端。现在除了依赖关系异常混乱外，代码的Fat情况也相当严重。这时项目团队开始全面使用Structure 101产品来分析下面这张图片，并问自己一些有实际意义的问题，比如：
- 为什么report代码要依赖一个引用包？
- 为什么在文件系统工具和日志包之间有这么一个强周期性依赖？
当然，即使没有Structure 101这个工具，也应该问自己一些类似的问题。但不可否认，该工具对问题进行了可视化，对于优化代码有很大的帮助。
#p#
发现问题后，项目团队就开始采取措施进行优化。下面这张图片大约是半年前的，可以看到，所有添加的新代码已经变得整洁，比如同级组件（fs、http等）之间的依赖关系现在已经得到了改善。
下面这张图片是一周前的。虽然代码库比半年前增长了25%，但是Tangle数已经成功地从39,000减少到了16,000，代码变得更加整洁、结构更加自然了。另外，项目团队的开发水平也有了一定的提高。
结论
项目代码复杂性的管理要贯穿项目始终，这样到项目后期，维护起来也不会特别困难。或者你可以制定一些依赖规则，然后在开发过程中强制执行。
这个故事是一个很好的样本，展示了一个小团队如何在一个相对短的时间内创建一个混乱的代码库。你也可以设想一下，如果一个10人开发团队开发一个预期寿命为10年的项目，最终的项目依赖关系图会是什么样的呢？
