定律或稱法則，可以指導(dǎo)我們并讓我們?cè)谕榈腻e(cuò)誤中學(xué)習(xí)。

這篇文章中，我將介紹我每次設(shè)計(jì)或?qū)崿F(xiàn)軟件時(shí)出現(xiàn)在我腦海的 5 個(gè)定律。其中有些和開發(fā)有關(guān)，有些和系統(tǒng)組織有關(guān)。它們可以幫助你成為合格的軟件工程師。

墨菲定律

“凡事可能出錯(cuò)，就一定出錯(cuò)。”

這條定律來源于 Edward Murphy —— 一名航天工程師在 50 年代初對(duì)火箭測(cè)試失敗的回應(yīng)。這條定律給我們的啟示是永遠(yuǎn)在系統(tǒng)關(guān)鍵地方使用防御性設(shè)計(jì)，因?yàn)橄到y(tǒng)某些地方總會(huì)出錯(cuò)！

這條定律很容易引入軟件工程領(lǐng)域。當(dāng)你將軟件暴露給終端用戶，他們會(huì)創(chuàng)造性地輸入一些出人意料的內(nèi)容，使系統(tǒng)宕機(jī)。所以你需要讓你的軟件足夠健壯，能夠檢測(cè)并警告非預(yù)期行為。

當(dāng)你在機(jī)器上運(yùn)行軟件時(shí)，任何地方都有可能發(fā)生問題 —— 從硬盤上的系統(tǒng)到數(shù)據(jù)中心的電力供應(yīng)。所以你必須確保你設(shè)計(jì)的架構(gòu)在每個(gè)層級(jí)都可以應(yīng)對(duì)故障。

我曾經(jīng)有機(jī)會(huì)領(lǐng)略過幾次墨菲定律。 舉個(gè)例子，我曾經(jīng)在一個(gè)批處理框架中使用字符串 null 來表示空值，我并不認(rèn)為這有問題，直到有個(gè)名字叫 Null 的用戶提交了一個(gè)交易訂單，我們的報(bào)表流程中斷了幾個(gè)小時(shí)…… 還有一次，在另一個(gè)項(xiàng)目中。當(dāng)所有東西都準(zhǔn)備好部署到生產(chǎn)環(huán)境了，突然 Azure 基礎(chǔ)設(shè)施故障導(dǎo)致我們運(yùn)行自動(dòng)化腳本的服務(wù)器宕機(jī)了。

現(xiàn)實(shí)世界中的經(jīng)驗(yàn)教訓(xùn)提醒著我生活的艱難 —— “凡事可能出錯(cuò)，就一定出錯(cuò)”。 所以，心中牢記墨菲定律，設(shè)計(jì)健壯的軟件。

Knuth定律

“在（至少大部分）編程中，過早優(yōu)化是萬惡之源。”

這條定律也是 Donald Knuth 的經(jīng)典語錄之一，它告誡我們不要過早優(yōu)化應(yīng)用程序中的代碼，直到必須優(yōu)化時(shí)再優(yōu)化。

的確，簡單易讀的源碼可以滿足 99% 的性能需要，并能提高應(yīng)用的可維護(hù)性。最開始使用簡單的解決方案也讓后期性能出現(xiàn)問題時(shí)更容易迭代和改進(jìn)。

垃圾自動(dòng)回收的編程語言中，字符串的連接常常是過早優(yōu)化的例子。在 Java 或 C# 中，String 對(duì)象是不可變的，我們學(xué)會(huì)使用其他結(jié)構(gòu)動(dòng)態(tài)創(chuàng)建字符串，比如StringBuilder。但事實(shí)上直到你分析完個(gè)應(yīng)用程序前，你并不知道 String 對(duì)象創(chuàng)建了多少次并對(duì)性能的產(chǎn)生多大影響。所以首先編寫盡可能整潔的代碼，之后在必須的時(shí)候再優(yōu)化，往往這樣做更有意義。

然而，這條規(guī)則并不應(yīng)該阻止你去學(xué)習(xí)編程語言的性能權(quán)衡和正確的數(shù)據(jù)結(jié)構(gòu)。并且，正如所有其他性能問題，你在優(yōu)化前要測(cè)量開銷。

North定律

“每一個(gè)決定都是一次權(quán)衡”

好吧，我承認(rèn)這是取自 Dan North 的演講Decisions,Decisions，它目前還不是公認(rèn)的定律。 但這條語錄影響了我做的每個(gè)決定，所以我把它放在這。

開發(fā)者日復(fù)一日的生活中，我們每天都做無數(shù)個(gè)大大小小的決定。從命名變量到自動(dòng)化（手動(dòng)）任務(wù)，再到定義平臺(tái)架構(gòu)。

這條語錄強(qiáng)調(diào)無論你做的選擇是什么，你總會(huì)放棄一個(gè)或多個(gè)選項(xiàng)

但這不是最重要的。 最重要的是理智地做出決定，了解其他選項(xiàng)，清楚你為什么不選擇它們。你要始終根據(jù)當(dāng)前你掌握的信息來權(quán)衡并做出決定。

但是如果后來你了解到新的信息，并發(fā)現(xiàn)之前的決定是錯(cuò)誤的，這也沒關(guān)系。關(guān)鍵是記清楚你為什么做出那個(gè)決定，重新評(píng)估新的選項(xiàng)之后再做出新的理智的決定。

重復(fù)一遍

“每一個(gè)決定都是一次權(quán)衡”

所以，做出選擇并對(duì)所有選項(xiàng)心知肚明。

Conway定律

“系統(tǒng)設(shè)計(jì)的架構(gòu)受限于生產(chǎn)設(shè)計(jì)，反映出公司組織的溝通架構(gòu)”

在 60 年代，一位名叫 Melvin Conway 的工程師注意到公司組織結(jié)構(gòu)影響到他們開發(fā)的系統(tǒng)的設(shè)計(jì)。他用一篇論文描述了這個(gè)觀點(diǎn)，并命名為“Conway定律”。

這條定律很適用于軟件開發(fā)領(lǐng)域，甚至體現(xiàn)到代碼層面上。交付軟件組件的各個(gè)團(tuán)隊(duì)組織結(jié)構(gòu)直接影響到組件的設(shè)計(jì)。

舉個(gè)例子，一個(gè)集中式的開發(fā)者團(tuán)隊(duì)會(huì)開發(fā)出各組件耦合的整體應(yīng)用。另一方面，分布式的團(tuán)隊(duì)會(huì)開發(fā)出單獨(dú)的（微）服務(wù)，每一部分關(guān)注點(diǎn)分離清晰。

這些設(shè)計(jì)沒有好壞之分，但它們都是受到團(tuán)隊(duì)溝通方式的影響。在全球有大量獨(dú)立開發(fā)者的開源項(xiàng)目，通常是模塊化和可重用庫，這就是很有說服力的例子。

如今，將大的集成應(yīng)用解耦成微服務(wù)已成趨勢(shì)。這很棒，因?yàn)檫@可以加速交付使用項(xiàng)目。但你也應(yīng)該牢記 Conway 定律，在公司組織構(gòu)建中投入與技術(shù)開發(fā)同樣多的工作。

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

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

這條定律論點(diǎn)是在會(huì)議中花費(fèi)的時(shí)間與事情的價(jià)值成反比。的確是這樣，人們更愿意把注意力和觀點(diǎn)放在他們熟悉的事物上，而不是復(fù)雜的問題上。

帕金森給出一個(gè)例子，一場(chǎng)會(huì)議中，成員們討論兩件事：為公司建核反應(yīng)堆和為員工建車棚。建反應(yīng)堆是一件巨大而復(fù)雜的任務(wù)，沒有人能完全掌控全局。他們完全信賴流程和系統(tǒng)專家，并很快接受了項(xiàng)目。

另一邊，建車棚是一般人都可以做的，每個(gè)人都可以對(duì)顏色有意見。事實(shí)上，每個(gè)會(huì)議成員都會(huì)表達(dá)自己的意見，使得建車棚的決議所花費(fèi)的時(shí)間遠(yuǎn)遠(yuǎn)超過建反應(yīng)堆的。

這條定律在軟件行業(yè)十分出名，這個(gè)故事隨后也被稱為車棚效應(yīng)

舉個(gè)例子，開發(fā)者會(huì)花費(fèi)更多時(shí)間到討論正確縮進(jìn)或函數(shù)命名，而不是討論類的職責(zé)或應(yīng)用架構(gòu)。這是因?yàn)槊總€(gè)人都能認(rèn)知幾個(gè)字符的變動(dòng)，但項(xiàng)目架構(gòu)的變動(dòng)則需要巨大的認(rèn)知負(fù)載

你能注意到的車棚效應(yīng)的另一個(gè)例子是 Scrum 演示。不要誤會(huì)我，我喜歡演示，我認(rèn)為這是一個(gè)很好的機(jī)會(huì)來面對(duì)用戶并獲得對(duì)應(yīng)用程序的反饋。但通常 Scrum 演示過程中的討論會(huì)轉(zhuǎn)向瑣碎問題，而不是審視全局。這些討論也很重要，但你應(yīng)該注意權(quán)衡更重要更復(fù)雜的問題。

一旦你了解這種規(guī)律，你將在會(huì)議和交流中發(fā)覺這種行為。 我并不是讓你在每次討論中避免“小”問題，提高你的意識(shí)可以幫助你關(guān)注真正的問題，并為這些會(huì)議做好準(zhǔn)備。

結(jié)論

這五條定律只是我們行業(yè)中總結(jié)出的教訓(xùn)中一些例子。隨著軟件開發(fā)經(jīng)驗(yàn)的增長，我們將會(huì)學(xué)會(huì)更多。 盡管其中某些定律現(xiàn)在看起來是常識(shí)，我始終堅(jiān)信了解這些原則可以幫助你識(shí)別這些模式并做出反應(yīng)。