净资产的结构

Netty的包装结构很棒。

每个程序员都应该研究它。每个系统都应该模仿它；每个项目经理都应将其打印出来，拍在墙上，然后对开发人员说：“那样。”

Netty是一个“……用于快速开发可维护的高性能协议服务器和客户端的异步事件驱动的网络应用程序框架”，但是在这里并不重要，因为我们没有对其行为进行分析。相反，请看图1。

图1：Netty的包装结构历时7年。

图1展示了Netty不断发展的软件包结构的spoiklin图（圆圈是包；直线是页面下的依赖关系；曲线是页面上的依赖关系），如果您不能立即看到它的结构如何，是，然后浏览Junit ， Struts或Ant 。

“情人眼中的优良结构”也不是唯一的情况。结构性混乱可以客观地衡量程序的结构性：结构性混乱程度越低，结构越好。 Netty的疾病远低于其他疾病，请参见表1。

程序	包装结构紊乱
蚂蚁	81％
朱尼特	76％
Struts	74％
Lucene	73％
FitNesse	61％
弹簧	35％
净额	26％

表1：本系列中所有程序的结构紊乱。

图2进一步显示了这种最终的结构异常并非偶然。 Netty在整个七年的生命周期中一直处于低水平。

图2：通过11个发布发布的Netty的结构混乱（与其他发布者进行比较）。

那么：为什么这个包结构这么好？

给定如图1所示的图，我们可以提出两个快速问题来大致评估所描述结构的优点。

在商业软件开发中，“良好的结构”仅表示“便宜的更新”。此外，有证据表明，每个了解涟漪效应的程序员都知道什么：X依赖的事物越多，涟漪效应的影响就越大，因此X的成本就越高。

因此，选择一个严重依赖其他程序包的问题（A）我们是否可以轻松地确定依赖程序包，以及（B）这些依赖程序包的整体子集有多小？

结构不良的程序会掩盖这些依赖关系，仔细检查通常会发现几乎整个系统都存在依赖关系。但是，结构合理的程序显然会提供依赖的程序包，而且数量很少。

让我们先问一个结构不好的程序的两个问题。

图3显示了Jenkins的噩梦般的90％结构混乱，然后显示了来自五个软件包（工具提示）中最依赖其他软件包的突出的传递依赖。

图3：詹金斯，哦，詹金斯。

显然，在Jenkins中跟踪依赖关系是一个挑战，许多软件包依赖于系统其余部分的75％以上。

图4重复了该实验，但是显示了五个Netty软件包的传递依赖关系，这五个软件包最依赖其他软件包： epoll，spdy，websocketx，http和nio 。

图4：以蓝色突出显示Netty中最差的传递依赖项。

与詹金斯形成鲜明对比的是，我们可以看到Netty软件包所依赖的数量以及数量。 Netty有55个软件包，但其他任何人所依赖的最大软件包只有12个，仅占系统的22％。

Netty的包装结构是否完美？当然不是。特别是内部和并发之间的循环依赖关系在该核心内部/并发/通道/缓冲区/使用程序包群集中创建了令人遗憾的强耦合。

从表面上看，Netty的类结构确实不好。 Netty的设计师在建造班级时显然放弃了一些出色的结构原理。丢人现眼。

但是看看那个包装的结构……哇。

最后，没有分析Netty的关键版本，而是提出了自己的架构观察。 Netty的架构师似乎已经决定了一个相当出色的部署策略。下载Netty既可以得到一个多合一的jar文件，也可以得到13个jar文件，其中包含系统的各个部分。大概您可以加载所有Netty或仅加载所需的部分。

一个jar文件，即“公共” jar，包含内部/并行/通道/缓冲区/ util程序包集群，而其他文件则包含“ codec”，“ tcnactive”，“ transport”等，提示后者jar是普通jar的客户，但不是彼此的客户，因此彼此之间没有依赖关系。因此，在他们的部署中，Netty的设计师可能已经将子系统的分离和封装包含在内，从而导致了这种行业领先的封装结构。

剩下的唯一问题是：为什么没有更多的项目跟随Netty的领导？为什么詹金斯有90％的结构异常？ Jenkins的设计者为什么不适当地划分他们的系统以减少包装间的耦合？为什么软件开发领域如此愿意接受这些不良结构所产生的成本？

我们不是比这个更好吗？