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的設計者為什么不適當地劃分他們的系統以減少包裝間的耦合？ 為什么軟件開發領域如此愿意接受這些不良結構所產生的成本？

我們不是比這個更好嗎？

摘要

如果每年獲得當今使用的最佳Java程序包結構獎，Netty將會連續七年獲得該獎項。

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

總結

以上是生活随笔為你收集整理的净资产的结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。