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）。架構師的首要任務是盡最大可能找出所有利益相關者，業務方，產品經理，客戶/用戶，開發經理，工程師，項目經理，測試人員，運維人員，產品運營人員等等都有可能是利益相關者。
- 每個系統都有一個架構
- 架構由架構元素以及相互之間的關係構成
- 系統是為了滿足利益相關者（stakeholder）的需求而構建的
- 利益相關者都有自己的關注點（concerns）
- 架構由架構文檔描述
- 架構文檔描述了一系列的架構視角
- 每個視角都解決並且對應到利益相關者的關注點。
架構主要關注非功能性需求（non-functional requirements），即所謂的-abilities。
- Easy to separate - Autonomy
- Easy to understand - Understandability
- Easy to extend - Extensibility
- Easy to change - Changeability
- Easy to replace - Replaceability
- Easy to scale - Scalability
- Easy to recover - Resilience
- Easy to connect - Uniform interface
- Easy to afford - Cost-efficiency
最小可用產品（Minimum Viable Product， MVP）: 做出最小可用產品，盡快丟給用戶試用，快速獲取客戶反饋，在此基礎上不斷迭代和演化架構和產品。
Over Engineering: 產品架構和用戶之間沒有形成有效的反饋閉環，架構師想的和客戶想的不在一個方向上，通過最小可用產品，快速迭代反饋的策略，可以避免這種問題。
圖像化組織結構
Manu Cornet: Organizational Charts
Manu Cornet 畫了一組美國科技公司的組織結構圖，亞馬遜等級森嚴且有序；谷歌結構清晰，產品和部門之間卻相互交錯且混亂；Facebook架構分散，就像一張散開的網絡；微軟內部各自為政；蘋果一個人說了算，而那個人路人皆知；龐大的甲骨文，臃腫的法務部顯然要比工程部門更加重要。
接下來大陸跟進，畫了許多大陸 IT 公司的組織圖。
如果康威定律真的成立，很難想像每個公司的系統有著跟組織圖一樣的關係，
好的架構源於不停地進化及演變，而非設計
網站在不同的階段遇到的問題不一樣，而解決這些問題使用的技術也不一樣，流量小的時候，主要目的是提高開發效率。隨著流量變大，使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC等方式不斷地提升網站穩定性。
系統架構缺少的東西
在系統的正向回饋循環中，最重要的是建立一個測試的程序，如果認定系統架構有著不斷演化的過程，系統會不斷地改變，那麼就必須要正視演化的步驟，最重要的就是測試。
但是系統在一開始開發時，不僅資料的變化大，系統的存取介面也會不斷地調整與修改，這時候，就會形成一個氣氛，那就是不撰寫測試的程式，而是直接在存取介面上進行測試，最終就是在使用者介面上進行測試。
但是使用者介面測試卻是一個最難以自動化的測試，尤其在做手機 APP 軟體更是如此，沒有一個方便的工具，可以自動化使用者介面測試，或者說，要達成自動化的 UI 測試，會需要使用更多的 programmer resource，公司能不能、要不要花費這樣的成本是個根本的大問題。
專案最需要的，是在一開始就建立好更新的流程，除了 Server 及 Client 的獨立更新，這個更新包含了 Server 跟 Client 的對應更新的方法，另外還有測試環境跟正式環境的切換方法，再加上現在的 ios APP 上架跟測試有時間差，這會造成更多更新的問題。
建立自動化測試、完整的更新程序，最後還有自動化部署跟監控系統的問題。這也是 DevOps 所關心的問題，有了完整的人力資源，隨著業務量的提升，就需要建立這些方面的處理方案。
沒有留言:
張貼留言