净资产滚动率

Netty的包装结构很棒。

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

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

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

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

并非只有这样的情况：“情人眼中有良好的结构。” 结构性混乱提供了程序结构的不良程度的客观度量：结构性混乱程度越低，结构越好。 Netty的疾病远低于其他疾病，请参见表1。

表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的设计师为什么不适当地划分其系统以减少包装间的耦合？ 为什么软件开发领域如此愿意接受这些不良结构所产生的成本？

我们不是比这个更好吗？

摘要

如果每年获得当今使用的最佳Java包结构的奖项，Netty将会连续七年获得该奖项。

翻译自: https://www.javacodegeeks.com/2017/01/the-structure-of-netty.html

净资产滚动率