凈資產滾動率

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

凈資產滾動率

總結

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

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