單源碼庫單應用的一些考慮

前言

單源碼庫單應用是我們公司一直在執行的标準，這個标準也是由于我的堅持才一直實行到現在。因為這個标準和開發的小夥伴兒們相愛相殺過好多次，下面我關于這個标準做的總結。

開發角度

首先，很多開發都認為單源碼庫多應用的話，會提升開發速度，兩個應用有很多共同的地方，放在一個源碼庫下開發也友善，這兩個應用共享的代碼并不會被别的應用用到。

但是，我覺得兩個應用之是以劃分成兩個應用就是要獨立開發，獨立部署，獨立運作。兩個應用如果代碼都耦合在一起的話，是應用劃分的不合理，無論是應用間還是應用内的子產品間都應該是高内聚低耦合的，兩個應用的公用部分就應該放到制品庫（neuxs 或者 artifactory）做成公共的元件。如果兩個應用代碼耦合很嚴重的話，就應該合并成一個應用。

有個流傳很廣的一句話是對一個程式員最大的懲罰就是讓他維護他三個月前寫的代碼，這也從側面反映出開發不太關心非功能性需求。

運維角度

從運維的角度講，任何一個運維對象的添加都應該慎重。因為每添加一個運維對象就會增加運維系統的複雜度，如果我們不能很好的控制複雜度，那我們運維工作肯定沒法做。

就以 java 應用為例，假設應用名為app1。

• 單源碼庫單應用，源碼庫位址就是 gitlab 位址+組名+app1，pom 檔案在源碼庫的根目錄，生成的 jar 包在，target/app1.jar。
• 單源碼庫多應用，就需要知道每個應用的 pom 檔案位置和生成二進制檔案的位置，還有就是我們按照 tag 發版的話，那麼兩個應用的話我還需要刷選一下。

總的來說單源碼庫多應用給運維系統帶來的複雜度是非常巨大的。

架構角度

一個架構需要考慮開發，測試，部署，可擴張性，性能，整體的靈活（可以了解為響應變化的能力）等一共六個方面，在單源碼庫多應用這個問題上我們主要考慮開發，測試，部署和整體的靈活四個方面（兩個應用代碼都耦合在一起的話，耦合度是很高的，是以下面以耦合度來說）：

• 從開發的角度講是 OK 的，能帶來很大的便利
• 從測試的角度，耦合度高的應用可測試性通常不高
• 從部署的角度，給部署工作添加了複雜度
• 從整體的靈活的角度，耦合度降低了軟體響應變化的能力

總的來說，我們考慮這個問題要盡量考慮全面。

開發為什麼這麼在乎開發速度

首先我覺得是大環境導緻的，引用深入核心的靈活開發――ThoughtWorks五大關鍵實踐中的一段話：

需求沒有妥協的空間，設計沒有妥協的空間，導緻團隊的痛點永遠是按時傳遞，品質一定會被犧牲掉的。

總的來說這個不是技術層次能夠解決的問題，需要引用靈活的一些方法論和流程，比如 WIP 等，具體可以看看這本書裡面的靈活轉型三步走的那章。

如果一定要實施單源碼庫多應用怎麼辦

有的開發也和我說過他們單源碼庫多應用有多麼合理，我說的是可以讓他們定義一個規則，比如一個源碼庫有多少個應用，應用在源碼庫根路徑第幾級目錄等等，總之就是不可能他們說他們應用想怎麼運作就怎麼運作，一定要有規範，複雜度一定要可控，我讓他們想好了這個我們再談單源碼庫多應用的事情。

更新于20201208

在 Bob 大叔的《架構整潔之道》第 12 章元件的開頭有說到：