今天要說說這兩個定律，乙個是墨菲定律，另外乙個是康威定律。
有人說:在系統設計時，可以以「墨菲定律」作為警醒。
墨菲定律:
任何事物都沒有表面看起來那麼簡單。
所有的事都會比你預計的時間長。
可能出錯的事總會出錯。
如果你擔心某種情況發生，那麼他就更有可能發生。
還有些時候在與安卓方面對接的時候總覺得**會有問題，但是當時測著卻沒有問題，上線以後，不免擔心起來，最後果然還是應驗了墨菲的那句話,"如果你擔心某種情況發生，那麼它就更有可能發生"。
還有人說:在系統劃分時，應該考慮康威定律。
康威定律:
系統架構是公司組織架構的反映。
應該按照業務閉環進行系統拆分／組織架構劃分，實現閉環／高內聚／低耦合，減少溝通成本。
如果溝通出現問題，那麼應該考慮進行系統和組織架構的調整。
在合適時機進行系統拆分，不要一開始就把系統／服務拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高。
"應該按照業務閉環進行系統拆分／組織架構劃分，實現閉環／高內聚／低耦合，減少溝通成本"。這不免讓人疑惑，業務閉環是什麼？簡而言之的說，就是你要想清楚你的盈利模式。
根據盈利模式進行系統拆分和組織架構劃分，所謂的系統拆分為的是對應不同的人群提供不同的服務，簡單舉個例子，比如去國家圖書館看書，對應不同的人群有不同的看書地方，比如大人、小孩、殘疾人、老年人等等。殘疾人失明，通過盲文閱讀，但是有的殘疾人失明又失去雙臂，但是耳朵卻很靈，聽書就比較適合他。從系統的拆分歸類劃分業務，然後進行組織架構劃分，誰擅長那些業務就由誰負責。
「高內聚和低耦合」，更是專案靈活變化的關鍵。最好的狀態就是像水一樣，放在圓的容器就是圓的，放在方形的容器就是方的，適應變化，並不會出現前期以牽一髮而動全身，但是這僅僅只是理想的開發狀態。現實卻因為溝通的原因和各種其他的原因在執行這個原則時出現阻礙。
我個人最推崇的就是最後這句話,"在合適時機進行系統拆分，不要一開始就把系統／服務拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高"。
比如最近我在做業務拆分時，我並不會將業務拆的非常細或者是直接拆完上分布式，因為那樣成本會非常高，拆的細意味著每個人維護多個系統，上分布式，目前的業務也沒有多大必要。
記得有位哥們說的好，不要為了分布式二分布式。
我目前拆分的，僅僅只是將乙個拆分成兩個，乙個是後台系統，乙個是專門作為共享xx系統直接對接客戶端。後台可通過ajax直接獲取共享xx系統的相關資料。之前都是在乙個系統，這個人改點東西或者上點新功能，那個人刪點東西改點東西，最後全部都在乙個專案上，即增加專案的複雜性，又增加了溝通的成本。所以才決定進行系統拆分，當需求非常強烈，專案面臨不得不拆分的場景時，我想這就是合適的時機。另外還是那句話不要拆的非常細，拆個大概，總的來說，就是兩者系統不包含彼此的相關**，可惜的是我目前還是沒有做到這一點，因為a系統可以完全不依賴b，但是b在某些**中卻依賴a。這是乙個很操蛋的問題。不過也不算很嚴重，至少目前分離出來後，沒有發現什麼大問題，測試也一切正常。
小結:讀書好，多讀書，讀好書，我覺得很重要，作為程式設計師我覺得眼界不應該侷限於程式設計技術和計算機等等，應該多讀讀其他領域的書籍，比如歷史、軍事、管理、生物、物理、數學、文學等等。看起來也許是無用，其實是大有裨益的。另外也要培養自己多方面的興趣愛好，比如毛筆字、畫畫、養花、登山、跑步、唱歌等等。我覺得作為乙個程式設計師可以讓自己生活的非常漂亮。即能學習使我快樂，又能生活如此多嬌。
系統設計和系統劃分的基本思路
今天要說說這兩個定律，乙個是墨菲定律，另外乙個是康威定律。有人說 在系統設計時，可以以 墨菲定律 作為警醒。墨菲定律 任何事物都沒有表面看起來那麼簡單。所有的事都會比你預計的時間長。可能出錯的事總會出錯。如果你擔心某種情況發生，那麼他就更有可能發生。任何事物都沒有表明看起來那麼簡單 比如在做系統分析...
讀書筆記《微服務設計》 康威定律和系統設計
康威定律 任何組織在設計一套系統時，所交付的設計方案在結構上都與該組織的溝通結構保持一致。1 松耦合組織和緊耦合組織 緊耦合組織的乙個例子是商業產品公司，松耦合組織典型代表是分布式開源社群。組織的耦合度越低，其建立的系統的模組化就越好，耦合也越低。2 netfflix和amazon 組織和架構應該一...
008 32位系統和64位系統有什麼區別
32位系統和64位系統有什麼區別？1 處理資料的能力 32位和64位表示cpu一次能處理的最大位數，理論上來說，64位系統處理的資料效率比32位更高，相當於 單車道和雙車道開車似得，雙車道單位時間可以有更多的車輛通行。但需要記憶體跟上，而且程式本身也是64位編譯才能發揮64位系統的優勢。2 支援的記...