在書中，我們經常能夠看到這樣那樣的法則、定律。然而真正經歷過這些事，回過頭來進行深度思考的時候，才越來越覺的這些定律、法則的道理之處。下邊簡述了一些自己感悟比較深刻的定律，當然還有很多，不斷學習，不斷經歷，不斷感悟，不斷成長吧。
一，在系統設計時，應該多思考「墨菲定律」：
1，任何事都沒有表面看起來那麼簡單；
2，所有的事都會比你預計的時間長；
3，可能出錯的事總會出錯；
4，如果你擔心某種情況發生，那麼他就更有可能發生。
二，在系統劃分時，也要思考「康威定律」：
1，系統架構是公司組織架構的反映；
2，應該按照業務閉環進行系統拆分/組織機構劃分，實現閉環/高內聚/低耦合，減少溝通成本。
3，如果溝通出現問題，那麼就應該考慮進行系統和組織架構的調整；
4，在合適時機進行系統拆分，不要一開始就把系統/服務拆分得非常細，雖然閉環，但是每個人維護的系統多，維護成本高。
三，在工期估算時考慮「霍夫斯塔特定律」：
實際花費的時間總是比預期的要長，即便你考慮到了本條定律。
四，在功能設計時考慮「伯斯塔爾定律」：
又稱健壯性法則：傳送是要保守，接收時要大方。
類似於乙個社交原則「對自己嚴格，對他人寬容」。
傳送是保守：告訴我們編寫**盡可能符合規範標準，讓別人很容易接收、解析、理解……
五，在變動專案安排時，考慮一下「布魯克法則」：
追加人員到延遲的專案更會影響專案的進度。
新員工的引入往往會帶來的問題：
1，新員工不可能馬上投入專案，他們需要經歷一些培訓。
2，需要在原本的員工中挑選幾人脫離生產，用於對新員工進行培訓
3，團隊內部的溝通將會消耗更多的時間
4，團隊的管理將會更加困難
5，新員工對於工作的不熟悉極有可能拖累專案進度
6，更多人參與設計導致概念的一致性遭到破壞，將會導致專案的缺陷增多
7，由於工作的先後順序問題，所有的員工不一定能投入工作，「十個孕婦不可能在乙個月內產下孩子」
更建議採取的方式（視情況而定）：
1，向專案中追加時間，但這帶來的二次商業成本將會非常高昂
2，帶著問題發布新版本
3，減小目標，發布更精簡的版本，並增添更多的後續版本計畫
六，在分析問題時考慮「帕累託法則」，又稱80/20法則：
1，對於許多現象來說，80%的後果都是 20%的原因造成；
2，在軟體開發中，**中80%的錯誤是由20%的**造成；
3，還有，公司80%的工作是由20%的員工完成的。問題是你並不總是清楚誰是那20%。
七，在控制**質量時，多考慮「林納斯定律」：
足夠多的眼睛，就可讓所有問題浮現」（given enough eyeballs, all bugs are shallow）。
換句話說：只要有足夠的測試人員及共同開發者，所有問題都會在很短時間內發現，而且能夠很容易被解決。
當然，還有很多，多積累，多思考，善於站在巨人簡單上……
工作中的一些認識
作為乙個 的板磚者，都說不上自己是乙個前端程式設計師，還是差太多，為什麼會這樣呢？無論在做什麼，態度永遠是第一位。開發都是乙個乙個的小團隊，為什麼都是兩個肩膀乙個腦袋，同樣是同樣的框架，人家的腦袋瓜，就是比你有靈光呢？我個人認為 首先，自己不必人家聰明，那就多付出點努力，老話不是說笨鳥先飛嘛，努力不...
找工作中的一些感悟
我是個很容易就滿足於悠閒安逸生活 的人，寒暑假的作業都是開學前幾天才寫的。以前的乙個女同學，她都是先寫作業，然後再愉快地過暑假。我不寫作業也能愉快暑假。這就是人跟人之間的區別。她去清華讀經濟了，我在華工讀計算機。看，人跟人的命運就是這麼被區別開了。呵呵。再武大讀了四年本科，被寢室的姐妹同化了，又享受...
最近工作中的一些問題
來公司已經兩個月了，這兩個月裡做不少頁面，水平也有些提高，會寫jquery外掛程式了，會用less來編譯css了，改用sublime編輯器寫 這三項，是我覺得我自己在這兩個月裡的重大收穫。但問題也是有的，最大的問題是開發效率。現在乙個需求提出來，設計圖出來後，由我來寫html css和js，html...