Like Share Discussion Bookmark Smile

J.J. Huang   2020-05-18   Java 阿里Java開發手冊   瀏覽次數:次   DMCA.com Protection Status

《阿里Java開發手冊》 | 工程結構 - 二方庫依賴

【強制】定義GAV遵從以下規則:

  • 1.GroupID 格式:com.{公司/BU }.業務線 [.子業務線],最多 4 級。
    說明:{公司/BU} 例如:alibaba/taobao/tmall/aliexpress 等 BU 一級子業務線可選。
    正例:com.taobao.jstorm 或 com.alibaba.dubbo.register
  • 2.ArtifactID 格式:產品線名-模組名。語義不重複不遺漏,先到中央倉庫去查證一下。
    正例:dubbo-client / fastjson-api / jstorm-tool
  • 3.Version:詳細規定參考下方。

【強制】二方庫版本號命名方式:主版本號.次版本號.修訂號

  • 1.主版本號:產品方向改變,或者大規模 API 不兼容,或者架構不兼容升級。
  • 2.次版本號:保持相對兼容性,增加主要功能特性,影響範圍極小的 API 不兼容修改。
  • 3.修訂號:保持完全兼容性,修復 BUG、新增次要功能特性等。
    說明:注意起始版本號必須為:1.0.0,而不是 0.0.1。
    反例:倉庫內某二方庫版本號從 1.0.0.0 開始,一直默默“升級”成 1.0.0.64,完全失去版本的語義訊息。

【強制】線上應用不要依賴 SNAPSHOT 版本(安全包除外);正式發布的類庫必須先去中央倉庫進行查證,使 RELEASE 版本號有延續性,且版本號不允許覆蓋升級。
說明:不依賴 SNAPSHOT 版本是保證應用發布的冪等性。另外,也可以加快編譯時的打包構建。


【強制】二方庫的新增或升級,保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變,必須明確評估和驗證。
說明:在升級時,進行 dependency:resolve 前後訊息比對,如果仲裁結果完全不一致,那麼通過 dependency:tree 命令,找出差異點,進行 <exclude> 排除 jar 包。


【強制】二方庫裡可以定義枚舉類型,參數可以使用枚舉類型,但是接口返回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象。


【強制】依賴於一個二方庫群時,必須定義一個統一的版本變數,避免版本號不一致。
說明:依賴 springframework-core,-context,-beans,它們都是同一個版本,可以定義一個變數來保存版本:${spring.version},定義依賴的時候,引用該版本。


【強制】禁止在子項目的 pom 依賴中出現相同的 GroupId,相同的 ArtifactId,但是不同的 Version。
說明:在本地調試時會使用各子項目指定的版本號,但是合併成一個 war,只能有一個版本號出現在最後的 lib 目錄中。曾經出現過線下調試是正確的,發佈到線上卻出故障的先例。


【推薦】底層基礎技術框架、核心資料管理平台、或近硬件端系統謹慎引入第三方實作。


【推薦】所有 pom 文件中的依賴聲明放在 <dependencies> 語句塊中,所有版本仲裁放在 <dependencyManagement> 語句塊中。
說明: <dependencyManagement> 裡只是聲明版本,並不實作引入,因此子項目需要顯式的聲明依賴, version 和 scope 都讀取自父 pom。而 <dependencies> 所有聲明在主 pom 的 <dependencies> 裡的依賴都會自動引入,並預設被所有的子項目繼承。


【推薦】二方庫不要有配置項,最低限度不要再增加配置項。


【推薦】不要使用不穩定的工具包或者 Utils 類。
說明:不穩定指的是提供方無法做到向下兼容,在編譯階段正常,但在運行時產生異常,因此,盡量使用業界穩定的二方工具包。


【參考】為避免應用二方庫的依賴衝突問題,二方庫發布者應當遵循以下原則:

  • 1.精簡可控原則。移除一切不必要的 API 和依賴,只包含 Service API、必要的領域模型對象、Utils 類、常數、枚舉等。如果依賴其它二方庫,盡量是 provided 引入,讓二方庫使用者去依賴具體版本號;無 log 具體實作,只依賴日誌框架。
  • 2.穩定可追溯原則。每個版本的變化應該被記錄,二方庫由誰維護,源碼在哪裡,都需要能方便查到。除非用戶主動升級版本,否則公共二方庫的行為不應該發生變化。

心得

看完這篇「二方庫依賴」後,必須要注意版號的定義規格,然後還有 jar 相互依賴的關係,基本上有做變動,一定要做好良好的測試,避免造成其他依賴的專案因為這個更新發生例外。

結語

文章越看越多,技術越學越多,就會發現自己的不足;技術學到後面都會想要將基礎再重新在打得更加扎實。

以前在開發覺得理所當然的事情,例如:命名規則、命名規範,照著別人怎麼說就怎麼做的想法,並沒有好好去想為什麼要這樣設計和規範。
於是乎同事們推薦《阿里巴巴Java開發手冊》來做閱讀,書中提到種種規範《正確範例》、《錯誤範例》還有解釋定義說明;我相信在閱讀完這一系列後,一定會更加扎實且實在。

如對此書有興趣,建議去購買官方認證的書籍,給予官方支持。

註:如有侵權,通知即刪。


註:以上參考了
Alibaba-Java-Coding-Guidelines Github
Alibaba-Java-Coding-Guidelines English Version