今天要說說這兩個定律，乙個是墨菲定律，另外乙個是康威定律。
有人說:在系統設計時，可以以「墨菲定律」作為警醒。
墨菲定律:
任何事物都沒有表面看起來那麼簡單。
所有的事都會比你預計的時間長。
可能出錯的事總會出錯。
如果你擔心某種情況發生，那麼他就更有可能發生。
還有些時候在與安卓方面對接的時候總覺得**會有問題，但是當時測著卻沒有問題，上線以後，不免擔心起來，最後果然還是應驗了墨菲的那句話,"如果你擔心某種情況發生，那麼它就更有可能發生"。
還有人說:在系統劃分時，應該考慮康威定律。
康威定律:
系統架構是公司組織架構的反映。
應該按照業務閉環進行系統拆分／組織架構劃分，實現閉環／高內聚／低耦合，減少溝通成本。
如果溝通出現問題，那麼應該考慮進行系統和組織架構的調整。
在合適時機進行系統拆分，不要一開始就把系統／服務拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高。
"應該按照業務閉環進行系統拆分／組織架構劃分，實現閉環／高內聚／低耦合，減少溝通成本"。這不免讓人疑惑，業務閉環是什麼？簡而言之的說，就是你要想清楚你的盈利模式。
根據盈利模式進行系統拆分和組織架構劃分，所謂的系統拆分為的是對應不同的人群提供不同的服務，簡單舉個例子，比如去國家圖書館看書，對應不同的人群有不同的看書地方，比如大人、小孩、殘疾人、老年人等等。殘疾人失明，通過盲文閱讀，但是有的殘疾人失明又失去雙臂，但是耳朵卻很靈，聽書就比較適合他。從系統的拆分歸類劃分業務，然後進行組織架構劃分，誰擅長那些業務就由誰負責。
「高內聚和低耦合」，更是專案靈活變化的關鍵。最好的狀態就是像水一樣，放在圓的容器就是圓的，放在方形的容器就是方的，適應變化，並不會出現前期以牽一髮而動全身，但是這僅僅只是理想的開發狀態。現實卻因為溝通的原因和各種其他的原因在執行這個原則時出現阻礙。
我個人最推崇的就是最後這句話,"在合適時機進行系統拆分，不要一開始就把系統／服務拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高"。
比如最近我在做業務拆分時，我並不會將業務拆的非常細或者是直接拆完上分布式，因為那樣成本會非常高，拆的細意味著每個人維護多個系統，上分布式，目前的業務也沒有多大必要。
記得有位哥們說的好，不要為了分布式二分布式。
我目前拆分的，僅僅只是將乙個拆分成兩個，乙個是後台系統，乙個是專門作為共享xx系統直接對接客戶端。後台可通過ajax直接獲取共享xx系統的相關資料。之前都是在乙個系統，這個人改點東西或者上點新功能，那個人刪點東西改點東西，最後全部都在乙個專案上，即增加專案的複雜性，又增加了溝通的成本。所以才決定進行系統拆分，當需求非常強烈，專案面臨不得不拆分的場景時，我想這就是合適的時機。另外還是那句話不要拆的非常細，拆個大概，總的來說，就是兩者系統不包含彼此的相關**，可惜的是我目前還是沒有做到這一點，因為a系統可以完全不依賴b，但是b在某些**中卻依賴a。這是乙個很操蛋的問題。不過也不算很嚴重，至少目前分離出來後，沒有發現什麼大問題，測試也一切正常。
資料庫表設計 基本思路
好的資料結構會影響速度。好的資料庫表設計會影響資料庫操作效率。特別是資料多的時候，如果表的結構不好的話操作的時候條件 where後的內容 會變的非常複雜。sql是關聯式資料庫中用到的一種語言。所以，為了簡化sql，表的關係 內部和外部 要盡量設計的合理。下面有幾個可以參照的步驟 1 找出那個表要描述...
Monte Carlo方法的基本思路
monte carlo方法的基本思路 1 針對實際問題建立乙個簡單且便於實現的概率統計模型，使所求的解恰好是所建模型的概率分布或其某個數字特徵，比如是某個事件的概率，或者是該模型的期望值。2 對模型中的隨機變數建立抽樣方法，在計算機上進行模擬試驗，抽取足夠的隨機數，並對有關的事件進行統計。3 對模擬...
系統設計和系統劃分有定律可循
今天要說說這兩個定律，乙個是墨菲定律，另外乙個是康威定律。有人說 在系統設計時，可以以 墨菲定律 作為警醒。墨菲定律 任何事物都沒有表面看起來那麼簡單。所有的事都會比你預計的時間長。可能出錯的事總會出錯。如果你擔心某種情況發生，那麼他就更有可能發生。任何事物都沒有表明看起來那麼簡單 比如在做系統分析...