每一個程序員都該知道的 5 個定律

定律或稱法則，能夠指導咱們並讓咱們在同伴的錯誤中學習。

這篇文章中，我將介紹我每次設計或實現軟件時出如今我腦海的 5 個定律。其中有些和開發有關，有些和系統組織有關。它們能夠幫助你成爲合格的軟件工程師。

墨菲定律

「凡事可能出錯，就必定出錯。」

這條定律來源於 Edward Murphy —— 一名航天工程師在 50 年代初對火箭測試失敗的迴應。這條定律給咱們的啓示是永遠在系統關鍵地方使用防護性設計，由於系統某些地方總會出錯！

這條定律很容易引入軟件工程領域。當你將軟件暴露給終端用戶，他們會創造性地輸入一些出人意料的內容，使系統宕機。因此你須要讓你的軟件足夠健壯，可以檢測並警告非預期行爲。

當你在機器上運行軟件時，任何地方都有可能發生問題 —— 從硬盤上的系統到數據中心的電力供應。因此你必須確保你設計的架構在每一個層級均可以應對故障。

我曾經有機會領略過幾回墨菲定律。 舉個例子，我曾經在一個批處理框架中使用字符串 null 來表示空值，我並不認爲這有問題，直到有個名字叫 Null 的用戶提交了一個交易訂單，咱們的報表流程中斷了幾個小時…… 還有一次，在另外一個項目中。當全部東西都準備好部署到生產環境了，忽然 Azure 基礎設施故障致使咱們運行自動化腳本的服務器宕機了。

現實世界中的經驗教訓提醒着我生活的艱難 —— 「凡事可能出錯，就必定出錯」。 因此，心中牢記墨菲定律，設計健壯的軟件。

Knuth定律

「在（至少大部分）編程中，過早優化是萬惡之源。」

這條定律也是 Donald Knuth 的經典語錄之一，它告誡咱們不要過早優化應用程序中的代碼，直到必須優化時再優化。

的確，簡單易讀的源碼能夠知足 99% 的性能須要，並能提升應用的可維護性。最開始使用簡單的解決方案也讓後期性能出現問題時更容易迭代和改進。

垃圾自動回收的編程語言中，字符串的鏈接經常是過早優化的例子。在 Java 或 C# 中，String 對象是不可變的，咱們學會使用其餘結構動態建立字符串，好比 StringBuilder。但事實上直到你分析完個應用程序前，你並不知道 String 對象建立了多少次並對性能的產生多大影響。因此首先編寫儘量整潔的代碼，以後在必須的時候再優化，每每這樣作更有意義。

然而，這條規則並不該該阻止你去學習編程語言的性能權衡和正確的數據結構。而且，正如全部其餘性能問題，你在優化前要測量開銷。

North定律

「每個決定都是一次權衡」

好吧，我認可這是取自 Dan North 的演講 Decisions,Decisions，它目前還不是公認的定律。 但這條語錄影響了我作的每一個決定，因此我把它放在這。

開發者日復一日的生活中，咱們天天都作無數個大大小小的決定。從命名變量到自動化（手動）任務，再到定義平臺架構。

這條語錄強調不管你作的選擇是什麼，你總會放棄一個或多個選項

但這不是最重要的。 最重要的是理智地作出決定，瞭解其餘選項，清楚你爲何不選擇它們。你要始終根據當前你掌握的信息來權衡並作出決定。

可是若是後來你瞭解到新的信息，並發現以前的決定是錯誤的，這也不要緊。關鍵是記清楚你爲何作出那個決定，從新評估新的選項以後再作出新的理智的決定。

重複一遍

「每個決定都是一次權衡」

因此，作出選擇並對全部選項心知肚明。

Conway定律

「系統設計的架構受限於生產設計，反映出公司組織的溝通架構」

在 60 年代，一位名叫 Melvin Conway 的工程師注意到公司組織結構影響到他們開發的系統的設計。他用一篇論文描述了這個觀點，並命名爲「Conway定律」。

這條定律很適用於軟件開發領域，甚至體現到代碼層面上。交付軟件組件的各個團隊組織結構直接影響到組件的設計。

舉個例子，一個集中式的開發者團隊會開發出各組件耦合的總體應用。另外一方面，分佈式的團隊會開發出單獨的（微）服務，每一部分關注點分離清晰。

這些設計沒有好壞之分，但它們都是受到團隊溝通方式的影響。在全球有大量獨立開發者的開源項目，一般是模塊化和可重用庫，這就是頗有說服力的例子。

現在，將大的集成應用解耦成微服務已成趨勢。這很棒，由於這能夠加速交付使用項目。但你也應該牢記 Conway 定律，在公司組織構建中投入與技術開發一樣多的工做。

瑣碎定律（帕金森瑣碎定律）

「組織成員投入大量精力到瑣碎的事情上。」

這條定律論點是在會議中花費的時間與事情的價值成反比。的確是這樣，人們更願意把注意力和觀點放在他們熟悉的事物上，而不是複雜的問題上。

帕金森給出一個例子，一場會議中，成員們討論兩件事：爲公司建核反應堆和爲員工建車棚。建反應堆是一件巨大而複雜的任務，沒有人能徹底掌控全局。他們徹底信賴流程和系統專家，並很快接受了項目。

另外一邊，建車棚是通常人均可以作的，每一個人均可以對顏色有意見。事實上，每一個會議成員都會表達本身的意見，使得建車棚的決議所花費的時間遠遠超過建反應堆的。

這條定律在軟件行業十分出名，這個故事隨後也被稱爲車棚效應

舉個例子，開發者會花費更多時間到討論正確縮進或函數命名，而不是討論類的職責或應用架構。這是由於每一個人都能認知幾個字符的變更，但項目架構的變更則須要巨大的認知負載

你能注意到的車棚效應的另外一個例子是 Scrum 演示。不要誤會我，我喜歡演示，我認爲這是一個很好的機會來面對用戶並得到對應用程序的反饋。但一般 Scrum 演示過程當中的討論會轉向瑣碎問題，而不是審視全局。這些討論也很重要，但你應該注意權衡更重要更復雜的問題。

一旦你瞭解這種規律，你將在會議和交流中發覺這種行爲。 我並非讓你在每次討論中避免「小」問題，提升你的意識能夠幫助你關注真正的問題，併爲這些會議作好準備。

 

結論

這五條定律只是咱們行業中總結出的教訓中一些例子。隨着軟件開發經驗的增加，咱們將會學會更多。 儘管其中某些定律如今看起來是常識，我始終堅信瞭解這些原則能夠幫助你識別這些模式並作出反應。