2016/6/27

康威定律 Conway's Law


Conway's law 是 1967 年一位 computer programmer Melvin Conway 說的一段話,在 1968 年的 National Symposium on Modular Programming 會議中,正式被命名。


康威定律 Conway's Law


Conway's Law 的內容如下:organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations


中文翻譯有人這樣寫:


人力組織的架構往往決定了設計的層次。


也有人這樣寫:


公司開發的產品和服務其實都是公司自身組織架構、溝通與工作方式的反映。


設計系統的組織,其產生的設計和架構等價於組織間的溝通結構。


OSI 的 co-founder Eric S Raymond 曾說,如果有四個小組在實作 compiler 的時候,最終我們會得到一個需要四個步驟的 compiler。


角色和職責 Role and Responsibility


每個架構師都應該研究下康威定律 這篇文章中,談到了作者對於架構設計以及演化的一些概念。


架構其實是發現利益相關者(stakeholder),然後解決他們的關注點(concerns)。架構師的首要任務是盡最大可能找出所有利益相關者,業務方,產品經理,客戶/用戶,開發經理,工程師,項目經理,測試人員,運維人員,產品運營人員等等都有可能是利益相關者。


  1. 每個系統都有一個架構
  2. 架構由架構元素以及相互之間的關係構成
  3. 系統是為了滿足利益相關者(stakeholder)的需求而構建的
  4. 利益相關者都有自己的關注點(concerns)
  5. 架構由架構文檔描述
  6. 架構文檔描述了一系列的架構視角
  7. 每個視角都解決並且對應到利益相關者的關注點。


架構主要關注非功能性需求(non-functional requirements),即所謂的-abilities。


  1. Easy to separate - Autonomy
  2. Easy to understand - Understandability
  3. Easy to extend - Extensibility
  4. Easy to change - Changeability
  5. Easy to replace - Replaceability
  6. Easy to scale - Scalability
  7. Easy to recover - Resilience
  8. Easy to connect - Uniform interface
  9. Easy to afford - Cost-efficiency

最小可用產品(Minimum Viable Product, MVP): 做出最小可用產品,盡快丟給用戶試用,快速獲取客戶反饋,在此基礎上不斷迭代和演化架構和產品。



Over Engineering: 產品架構和用戶之間沒有形成有效的反饋閉環,架構師想的和客戶想的不在一個方向上,通過最小可用產品,快速迭代反饋的策略,可以避免這種問題。



圖像化組織結構


Manu Cornet: Organizational Charts


Manu Cornet 畫了一組美國科技公司的組織結構圖,亞馬遜等級森嚴且有序;谷歌結構清晰,產品和部門之間卻相互交錯且混亂;Facebook架構分散,就像一張散開的網絡;微軟內部各自為政;蘋果一個人說了算,而那個人路人皆知;龐大的甲骨文,臃腫的法務部顯然要比工程部門更加重要。



接下來大陸跟進,畫了許多大陸 IT 公司的組織圖。


瘋狂的架構——國內六大著名科技公司組織結構圖一覽


如果康威定律真的成立,很難想像每個公司的系統有著跟組織圖一樣的關係,


好的架構源於不停地進化及演變,而非設計


宜人貸系統架構——高並發下的進化之路


58同城沈劍:好的架構源於不停地演變,而非設計


網站在不同的階段遇到的問題不一樣,而解決這些問題使用的技術也不一樣,流量小的時候,主要目的是提高開發效率。隨著流量變大,使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷地提升網站穩定性。


系統架構缺少的東西


在系統的正向回饋循環中,最重要的是建立一個測試的程序,如果認定系統架構有著不斷演化的過程,系統會不斷地改變,那麼就必須要正視演化的步驟,最重要的就是測試。


但是系統在一開始開發時,不僅資料的變化大,系統的存取介面也會不斷地調整與修改,這時候,就會形成一個氣氛,那就是不撰寫測試的程式,而是直接在存取介面上進行測試,最終就是在使用者介面上進行測試。


但是使用者介面測試卻是一個最難以自動化的測試,尤其在做手機 APP 軟體更是如此,沒有一個方便的工具,可以自動化使用者介面測試,或者說,要達成自動化的 UI 測試,會需要使用更多的 programmer resource,公司能不能、要不要花費這樣的成本是個根本的大問題。


專案最需要的,是在一開始就建立好更新的流程,除了 Server 及 Client 的獨立更新,這個更新包含了 Server 跟 Client 的對應更新的方法,另外還有測試環境跟正式環境的切換方法,再加上現在的 ios APP 上架跟測試有時間差,這會造成更多更新的問題。


建立自動化測試、完整的更新程序,最後還有自動化部署跟監控系統的問題。這也是 DevOps 所關心的問題,有了完整的人力資源,隨著業務量的提升,就需要建立這些方面的處理方案。


References


很威的康威定律 (Conway's Law)


Conway's Law 康威定律


不會帶團隊的領導者,只能自己幹到死


半個世紀過去了,康威定律依然適用

沒有留言:

張貼留言