程式設計師應該了解的常見軟體開發定律
軟體開發領域最著名和最常見的定律：
墨菲定律（murphy's law）
可能是最著名的定律之一，主要是因為它不僅適用於軟體開發。
如果事情可能出錯，它就會出錯。
第乙個推論：那些有效的（**），你可能反而沒有寫出來。
第二個推論：詛咒是唯一一門所有程式設計師都能流利說出來的語言。
結論：電腦會按照你所寫的（**）去做，而不是按照你所想的去做。
防禦性程式設計、版本控制、末日場景（針對那些該死的殭屍伺服器攻擊）、tdd、mdd，等等，這些都是針對這一定律的防禦性實踐。
布魯克定律（brook's law）
大多數開發人員都有意無意地經歷過布魯克定律，該定律指出：
為已經延期的軟體專案增加人手只會讓專案延期得更厲害。
如果乙個專案出現了延期，只是簡單地增加人手很可能會帶來災難性的後果。對程式設計效率、軟體開發方法、技術架構等因素進行評審總是會帶來更好的結果。如果沒有，那說明霍夫施塔特定律也在起作用。
霍夫施塔特定律（hofstadter's law）
霍夫施塔特定律由 douglas hofstadter 提出，並以他的名字命名。
當然，不要將這個定律與電視劇集《大**》裡的 leonard hofstadter 混淆起來了，儘管他說的一些話對某些人來說是有一點意義的。
這個定律指出：
即使你考慮到了霍夫施塔特定律，專案的實際完成時間總是比預期的要長。
這個「定律」是關於準確預估完成複雜任務所需時間的難度。這個定律具有遞迴性，反映了預估複雜專案的難度，儘管你可能已經做出了最大的努力，而且也知道任務的複雜性。
這就是為什麼在進行專案預估時必須要有乙個緩衝區。
康威定律（conway』s law）
軟體的結構反映了開發軟體的組織的結構。
或者說得更清楚一點：
組織所設計的系統的結構受限於組織的通訊結構。
很多組織是根據功能性技能來劃分團隊的，所以會有前端開發團隊、後端開發團隊和資料庫開發團隊。簡單地說，如果某人想要改變的東西屬於其他人，那麼他就很難改變這些東西。
現在越來越多的組織根據有界上下文來組建團隊，而微服務等架構也在根據服務邊界而不是孤立的技術架構分割槽來組建團隊。
因此，根據目標軟體架構來組建團隊可以更容易實現軟體架構，而這就是對抗康威法律的一種有效方式。
波斯託定律（postel's law）或魯棒性法則
保守輸出，自由輸入。
jon postel 最初將它作為實現健壯的 tcp 的乙個原則。這個原則也體現在 html 中，html 的成敗可以歸因於它的很多屬性，但究竟 html 是成功的還是失敗的，不同的人有不同的看法。
帕累託法則（pareto principle）或 80/20 法則
對於很多現象，80％的後果源於 20％的原因。
80％的 bug 來自 20％的**，這個說的就是帕累託法則。
還有人說，公司裡 80％的工作是由 20％的員工完成的，問題是你並不清楚是哪 20％員工。
彼得法則（the peter principle）
在乙個等級制度中，每個員工都傾向於晉公升到他無法勝任的職位。
基爾霍夫法則（kerchkhoff's principle）
在密碼學中，系統應該是安全的，即使系統的所有東西都是公開的——除了一小部分資訊——秘鑰。
這是公鑰密碼學的主要法則。
萊納斯定律（linus's law）
這是以 linux 之父 linus torvalds 的名字命名的，該定律指出：
如果有足夠多的眼睛，所有的 bug 都將無所遁形。
可以使用著名的《大教堂與集市》來描述這個定律，它解釋了兩種不同的自由軟體開發模型之間的對比：
大教堂模型——每個軟體發行版都提供源**，但發行版之間的**開發僅限於一組專有的軟體開發人員。
集市模型——**開發通過網際網路公開進行。
結論:對源**進行更廣泛的公開測試、評審和實驗，就會更快地發現各種形式的 bug。
摩爾定律（moore's law）
單位成本的計算機算力每 24 個月翻一番。
最流行的版本是說：
積體電路上的電晶體數量大約每 18 個月會增加一倍。
或者：計算機的處理速度每兩年翻一番！
沃斯定律（wirth's law）
軟體比硬體更容易變慢。
參考一下摩爾定律
九九法則（ninety-ninety rule）
前 90％的**占用了 10％的時間，其餘的 10％**占用了剩下的 90％時間。
克努特優化法則（knuth's optimization principle）
過早優化是萬惡之源。
先寫**，然後找出瓶頸，最後才修復！
諾維格定律（norvig's law）
任何超過 50％滲透率的技術都不會再次翻倍（無論在多少個月內）。
程式設計師應該淡定
程式設計師應該淡定，程式工作沒什麼了不起，每乙個領域都有比較難的事情需要人去做，一般情況下都是基礎理論先有所突破，後續的程式設計師去實現而已。而基礎理論這些東西，並不是程式設計師的領域，可能一幫專家研究幾十年才會有點成就。程式設計師，不管做什麼的，其實都一樣要完成2件事 1.把程式設計好，邏輯結構清...
軟體開發 程式設計師是不是青春飯
任何技術含量低下的工作其實都是青春飯，很容易被取代。對於軟體行業來說，只有低端的程式設計師才會面臨青春飯的問題，該層次人數最多，技術含量低，競爭最激烈，隨著技術的進步，老舊思想和技術的程式設計師最容易被取代。中高階的程式設計師作為行業的中堅力量，人數相對較少，處於賣方市場，競爭並不不激烈，所以相對來...
作為PHP程式設計師應該了解MongoDB的五件事
2010年應該被人們記住，因為sql將在這一年死去。這一年關聯式資料庫行將就木，這一年開發者發現他們再不需要長時間辛苦的構造列或者 來存放資料。2010年將是文件型資料庫的起始年。儘管這樣的勢頭已經持續多年，現在才是乙個更多，更廣泛的文件型資料庫出現的年代。從基於雲計算的amazon到google，...