一、 軟件工程中技術架構和組織架構的關系

不知道你有沒有觀察過：通常系統架構和組織架構是相似的。比如說前后端分離的架構，那么在組織上一般也會分前端組和后端組；而微服務架構，則分組是和服務相關的，可能一個組就是負責一個微服務。

其實組織架構和技術架構相似這個現象不是偶然的，這個現象背后有個定律叫康威定律 (Conway’s Law)。康威（Melvin Conway）博士在 1967 年提交的一篇論文《How Do Committees Invent?》中最有名的一句話是：

Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations. — Melvin Conway

如果對這句話翻譯一下，它的意思是：

你設計的軟件系統架構，會以某種方式反映出構建軟件背后團隊的組織架構，你在設計軟件的系統架構時，同時也在設計你的組織架構，反之亦然。也可以簡單理解為：組織架構的設計等同于系統架構的設計。

如果你拿康威定律去驗證你現在的團隊組織架構，或者你熟悉的其他團隊的組織結構，你會發現運行良好的項目，都很好地符合這條定律。那些大型復雜的單體軟件系統，背后也對應著一個龐大的開發團隊，那些應用微服務的項目，背后都是一個個的小組。

看完康威定律再回過頭來看微服務，你會發現，微服務架構的設計，不僅僅是一個對服務拆分的架構設計，同時也是對組織架構拆分的設計。

當你在設計系統架構的同時，把組織架構的設計也考慮進去，很多問題也就迎刃而解了。比如說你開發團隊 30 個人，要使用微服務的架構，那么拆成 3～5 個微服務是比較合適的。因為每個小組 10 個人左右，每個小組維護 1～3 個微服務，是相對比較合適的配比。

然后你再看那些應用微服務失敗的案例，比如說一個小開發團隊，做出 100 多個微服務的架構，那團隊維護這些服務的成本一定是相當高的，最終會難以維持。

還有一些傳統大型企業，團隊構成是按工種劃分成不同團隊的，開發一個團隊、測試一個團隊、運維一個團隊，那么推行微服務阻力會非常大，因為這樣的組織結構和微服務的組織結構是不兼容的。

對于微服務的組織結構，需要按服務劃分團隊，團隊成員有開發、測試和運維，一起組成一個小團隊，圍繞著服務不斷迭代，這樣效率是最高的。

總結

• 站在軟件工程的角度去看技術：技術服務于架構設計，架構設計服務于業務，業務服務于商業。也就是本質上來說，技術是為項目服務的工具。

• 不管是現在還是將來，你總是免不了要去面對新技術。從技術角度去看新技術，也許你會興奮，也許你會抵觸，但是如果你跳出技術角度之外，站在軟件工程的角度去看新興技術，你會有不一樣的收獲。

• 技術架構等同于組織架構，當你在設計系統架構，你同時也在設計你的組織架構，反之亦然。當你糾結微服務的拆分粒度，不妨看看你的組織架構是不是能和微服務架構匹配。

• 最后，技術是工具。技術服務于架構設計，架構設計服務于業務，業務服務于商業。對新技術，保持學習和了解，知道新技術能為你解決項目中什么問題，就像工具一樣，選擇合適的技術，讓技術為架構服務。

總結

以上是生活随笔為你收集整理的软件工程中技术架构和组织架构的关系的全部內容，希望文章能夠幫你解決所遇到的問題。

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