本文最初發(fā)布于 Level Up Coding。

多年來，我觀察到了一些在工程過程中反復出現(xiàn)的基本模式和陷阱。有趣的是，它們與工程博客上無休止爭論的話題無關(guān)。例如，我不記得哪一次我的團隊因為對 SOLID 原則理解不足而導致錯過了交付期限。偶爾，我會遇到一條“法則”，它完美描述了我所經(jīng)歷的問題。令人惱火的是，這些便利的工程定律卻往往在播客、有聲讀物和博客的邊角隱蔽處。所以我把它們整理成一個清單，其中列出了我最喜歡的 8 條編程法則，你肯定也會在現(xiàn)實生活中遇到它們。

1）墨菲第二定律

墨菲定律[1]是這個榜單上最著名、最廣為人知的定律，它通常被表述為：

“凡事只要可能出錯，那就一定會出錯。”

不過，真要說觸及所有工程師痛處的還要數(shù)墨菲第二定律：

“任何解決方案都有自己的問題“

或者，沒有什么事情像看起來那么簡單[2]。墨菲第二定律雄辯地總結(jié)出了以下觀察結(jié)果：作為工程師，我們接觸的任何東西都會增加系統(tǒng)的風險，因此，可以通過避免系統(tǒng)更改來降低風險。

運用之道

隨著我成長為一名成熟的工程師，我花在編程上的時間越來越少。事實上，我已經(jīng)慢慢地開始認為，編寫新代碼是一種系統(tǒng)性風險；它增加了復雜性、可維護性，可能還有 Bug?？紤]到墨菲定律，我有以下建議：

1. 首選流程變革和供應商軟件，而不是自主開發(fā)的解決方案。
2. 避免陷入快速解決方案陷阱，因為你以后不得不回過頭來改進。第一次就把它做好。
3. 測試。測試。測試。測試覆蓋率越高，應用程序就越能適應復雜的環(huán)境。

2）康威定律

1967 年，梅爾文·康威揭示了這樣一個道理[3]：

“設計系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設計的組織的溝通結(jié)構(gòu)?！?/span>

或者，更直截了當?shù)兀?/span>

“如果你讓 4 個小組開發(fā)編譯器，那么你就會獲得 4 個編譯器?！?/span>

康威定律的影響很大，因為軟件工程師常常必須與分散在世界各地的同事一起構(gòu)建系統(tǒng)。例如，我在一家大型托管銀行工作的時候，曾參與開發(fā)過一個有很多服務的交易系統(tǒng)。除了兩個服務之外，其余服務都是通過內(nèi)部消息總線進行通信。然而，莫名其妙的，這兩個服務通過互聯(lián)網(wǎng)上的公共 API 進行通信。

就像大腦功能作為子組件運行一樣，任何時空上分散的勞動力也是如此。

我接著發(fā)現(xiàn)，通過互聯(lián)網(wǎng)進行通信的服務是美國團隊和印度團隊唯一重疊的地方。系統(tǒng)架構(gòu)基本上是兩個半球：左邊是美國的微服務，右邊是印度的服務，它們之間有一個最小 API。從根本上說，這個 API 就是大西洋。

運用之道

在所有科技領(lǐng)域中，關(guān)于康威定律的補救措施，有一個最好的說法是逆康威模式（Inverse Conway Maneuver）。換句話說，通過改進團隊和組織結(jié)構(gòu)來促成所需的架構(gòu)[4]。在這方面，亞馬遜的雙披薩團隊可能算是最著名的例子了，故事是這樣的：

• 2001 年，Amazon.com 是一個緊耦合的大型單體，維護難度很大[5]。
• 該網(wǎng)站被重建為多個微服務，每個微服務由一個專門的團隊支持。因此，團隊按照業(yè)務線（如購物車、推薦、廣告）而不是技術(shù)線（如數(shù)據(jù)庫、QA、開發(fā)）進行了重組。
• T 團隊保持較小的規(guī)?！藛T數(shù)量以兩個披薩能讓團隊所有人吃飽為限。公司和網(wǎng)站同時經(jīng)歷了一次重構(gòu)。

這很好，但你可能沒有能力開展公司范圍的組織結(jié)構(gòu)大調(diào)整。不用擔心，有幾種方法可以讓你的組織，或者至少是你的團隊，擺脫康威定律：

1. 最重要的工作應該在時區(qū)重疊的時間內(nèi)完成。我并不是說西海岸的同事要趕每天早上 6 點的接觸點，但是真正關(guān)鍵的會議和結(jié)對開發(fā)應該安排在團隊中大多數(shù)人都能參加的時間。
2. 在招聘和組織工作中考慮到這種限制因素。雖然這很可能是你無法控制的，但你可以嘗試向你的經(jīng)理們傳達康威定律。
3. 接受它。如果你所在的組織是分布式的，那么或許你們的系統(tǒng)也應該是分布式的。避免與組織結(jié)構(gòu)不協(xié)調(diào)的系統(tǒng)架構(gòu)。

3）演示定律

也被稱為演示過程中的墨菲定律，它指出，無論你排練得多么好，無論你排練了多少次，你在演示時總是會出錯！我在這里就不詳細說明為什么會發(fā)生這種情況了——關(guān)于這一點，請查閱資料[9-11] 。

如果這在世界一流工程師馬斯克身上會發(fā)生，那么在你身上也會發(fā)生（https://www.reddit.com/r/ProgrammerHumor/comments/e0bkok/universal_law_of_demos/）

運用之道

接受演示經(jīng)常會不順利的事實，做好防范：

1. 做最低限度演示 —— 在可以傳達想法/應用/功能的前提下，盡可能減少展示內(nèi)容。
2. 實際的演示過程會比你預想的長。
3. 至少提前 20 分鐘到場，打開在線會議，準備好 PPT。沒有什么比一屋子的工程師為如何打開在線會議而爭論不休更令人厭惡的了。
4. 準備一個備份演示。想象一下，你即將展示一個新的網(wǎng)站，而在演示前 5 分鐘，AWS 出現(xiàn)了故障。你能在本地機器上運行幾個頁面嗎？是否有一個部署在不同地區(qū)的低配環(huán)境等等……要為最壞的情況做好準備。
5. 小黃鴨調(diào)試法

由于演示從來都無法完全按計劃進行，你實際上可以利用這一點來發(fā)揮自己的優(yōu)勢。如果有什么東西不能正常工作，如你的 IDE 出了問題，你無法重現(xiàn)一個錯誤，諸如此類。那么，你可以利用演示定律，試著把它展示給一個朋友。通常，在談論這個問題的時候，你會發(fā)現(xiàn)解決方案，或者問題會神奇地消失。

4）格雷沙姆定律

格雷沙姆定律來自 19 世紀的經(jīng)濟學，它指出：

“劣幣驅(qū)逐良幣” [6] ，或者更通俗地說“壞的擠走好的”。

Ben Hosking 在[7]中對格雷沙姆定律在軟件工程中的應用做了很好的描述，我把它簡單地歸結(jié)為：

廉價的軟件實際上非常昂貴[8]。

你希望三者兼而有之，但實際上應該把重點放在質(zhì)量（Godd）上（https://andrewcoppolino.com/blog/fast-good-cheap-pick-two/）

運用之道

在理想世界里，每個項目都很快，很便宜，而且還做得很好。然而，在現(xiàn)實中，我們只能追求 3 項中的 2 項，要明智地選擇。在某些情況下，我們不得不倉促趕工，但根據(jù)格雷沙姆定律，“便宜”是一個謊言。那是技術(shù)債務。你應該總是追求把事情做好。

5）計劃謬誤

在 DanIEl Kahneman 的《思考，快與慢》一書中[13]，估計謬誤是指人類在提前計劃時表現(xiàn)出相當大的樂觀偏差，導致對完成一項任務所需的時間估計不足。你可能經(jīng)常會碰到這種情況。例如，最近你是否有什么小差使原本打算用一個小時完成，最后卻讓你耗費了半天時間？事實上，對于任何任務估計，一般的建議是先將最初的估計翻倍甚至翻三倍，然后你才會對其實際完成時間有一個大致的認識。

計劃謬誤的精彩描繪（https://medium.com/geekculture/how-the-planning-fallacy-trips-you-up-3248b7e3978e）

以下是計劃謬誤的幾個實際的例子[14]：

• 悉尼歌劇院原計劃于 1963 年完工。但事實是，它的縮小版在十年后的 1973 年才開放。最初的成本估計為 700 萬美元，但因為延期成本增加到了 1.02 億美元。
• 波士頓中央大道下的“大隧道”工程比計劃晚了 7 年才完成，預算為 28 億美元（1988 年），實際耗資 80.8 億美元。
• 加州高鐵仍在建設中，預計將超支數(shù)百億美元，與主要城市的連接被推遲到農(nóng)村段完成后。

運用之道

1. 對任何被認為“應該很快/很容易”的東西持懷疑態(tài)度。
2. 在任何時候，在給出最后期限時，務必謹慎地用試探性的問題來回應。例如，“如果 QA 團隊在第一輪就碰到了 Bug，那么時間表會有什么變化？”像這樣的基本問題可以幫助我們發(fā)現(xiàn)那些事后看來很明顯的誤區(qū)和盲區(qū)。
3. 當有疑問時，將估計加倍。當應別人要求進行估計時，至少要按最初估計的兩倍。有時候，我會按三倍，然后在對方的說服下改為兩倍。

6）海勒姆定律

該定律是最近才提出來的，可以追溯到一名谷歌人的博客[12]。該定律指出：

當一個 API 有足夠多的用戶，

你在契約中承諾了什么并不重要：

系統(tǒng)中所有看得見的行為

都會有某個人依賴……

XKCD 漫畫就是最好的例證：

https://xkcd.com/1172/

運用之道

與墨菲定律類似，你必須注意，人們會以你意想不到的方式使用系統(tǒng)。因此，必須盡量縮小其范圍。構(gòu)建一個讓用戶可以用兩種類似的方式做同一件事的 API？這會讓用戶感到困惑嗎？盡量讓接口一目了然、固執(zhí)己見、簡單易用，以至于幼兒園的小朋友都能使用。

最近，我在設計一個 API 時遇到了海勒姆定律描述的情況。簡單起見，假設它獲取一個用戶列表：

fetchUsers() -> {Allan Apple, Bill Banana, Chris Carrot …}

注意到用戶是有順序的了嗎？排序過程是隱式的，因為是在數(shù)據(jù)庫中完成的，API 契約中沒有順序保證。然而，考慮到海勒姆定律，我意識到，最終會有人依賴于這個順序。因此，我在構(gòu)建時將它作為 API 契約的一個默認參數(shù)fetchUsers(sort=True)。

7）帕累托法則

帕累托法則也被稱為收益遞減定律，或 80/20 原則，其適用范圍很廣。例如，根據(jù) 1989 年的估計，世界上最富有的 20%的公民擁有世界上 80%的財富（多么奇怪）。或者，20%的工作場所危險源導致了 80%的傷害。在軟件領(lǐng)域，這體現(xiàn)在幾個方面，我將直接引用維基百科的說法，因為它說得很好：

在計算機科學中，帕累托法則可以應用于優(yōu)化工作。例如，微軟公司指出，修復報告最多的錯誤中的 20%，可以消除特定系統(tǒng)中相關(guān)錯誤和崩潰的 80%。Lowell Arthur表示，“20%的代碼包含了 80%的錯誤。找到它們，修復它們！" 人們還發(fā)現(xiàn)，一般來說，一款軟件的 80%可以在分配的總時間的 20%內(nèi)寫完。反之，最難的 20%的代碼需要 80%的時間。通常，這個因素是軟件編碼中COCOMO估算的一部分。

運用之道

要利用好帕累托法則，你可以采取以下措施：

• 先解決難題。

盡早將最棘手的工程挑戰(zhàn)暴露出來很重要。80%的工作可能都潛伏在這里。

• 避免鍍金，即過度設計。

一個很好的方法是承擔更多的責任，這將使你專注于最重要的挑戰(zhàn)，而不是細節(jié)。

我并不是說你應該同時處理多項任務，這通常很低效。我的意思是，不要在任何一項任務上花費超過一周的時間。當然，不是所有的任務都能在一周內(nèi)完成，這就是問題的關(guān)鍵。如果給你的時間無限，你就會找活來干，這通常會導致鍍金。然而，如果知道你要把它交給一個隊友，那么你就必須確定什么最重要——也許只是創(chuàng)建一個包含 CRUD 方法的 REST API，或者僅僅是設置構(gòu)建管道。通過快速參與和退出，你將在多個項目中完成 80%的工作。當你的同事花了整整一個月的時間把一件事情做到 100%的時候，你會把四件事情做到 80%，在某種意義上，你的生產(chǎn)力提高了大約 3 倍。我可以告訴你，當我成為一名高級開發(fā)人員時，我在許多項目中做出了貢獻，這比我在之前的工作中從頭到尾做一件事更有價值；在我看來，寬度>深度。

8）泰斯勒定律

圖片來源：https://unsplash.com/photos/OopPIi_A428

又稱復雜性守恒定律，其思想是，每個系統(tǒng)都有一個固有的不可約減的復雜性，如果要處理它，要么系統(tǒng)變得更復雜，要么交由用戶來完成。Larry Tesler 認為，最好是花點工程時間來改進系統(tǒng)，而不是指望用戶這么做。這是有道理的——如果你的應用有一百萬用戶，那么即使一個工程師花費一個月的時間從一項操作中減掉了幾次點擊，就可以為百萬用戶節(jié)省數(shù)百萬次點擊。

在我自己的生活中，這種情況每天都在發(fā)生。當我和谷歌家居說，打開燈，改變它們的顏色。我必須給它兩個單獨的命令：

嘿，谷歌，把燈開到 50%……（等待 5 秒）……嘿，谷歌，把燈調(diào)為白光。

當然啦，在人工智能中支持復合命令難度很大，因此，用戶吸納了這種復雜性。

運用之道

• 避免增加用戶負擔的解決方案；觀察用戶如何使用系統(tǒng)，并設法發(fā)現(xiàn)不足。
• 總是選擇花更多的時間在“正確方法”上，而不是“快速方法”上，即格雷沙姆定律。
• 像用戶一樣思考——你愿意使用你正在構(gòu)建的功能嗎？

買 8 贈 1——XY 問題

這本身不是一條定律，但感覺應該包括在內(nèi)。當一個解決方案（Y）的提出沒有充分考慮實際問題（X）的背景，就會導致更好的解決方案（Z）被忽視，浪費精力?？紤]一下這樣一個例子：

老板：“請加大這一頁的字體?！保?/span>建議解決方案 Y）

工程師：“好的?！?/span>

老板（第二天）：“你能把它改回來嗎？用戶說太大了?！?/span>

工程師：“好吧——我們一開始為什么要改？”

老板：“我們的一個用戶用的是舊版本的 IE，字體渲染有問題?！保?/span>真正的問題 X）

工程師：“他就不能用 Chrome 嗎？”（備選方案 Z）

運用之道

在上面的例子中，只要工程師問幾個澄清式問題，就可以避免浪費精力。老板對解決方案（Y）的執(zhí)著使他看不到可能更好的解決方案（Z）。

在現(xiàn)實生活中，XY 問題通常始于一些聽起來可疑的事情。像“請把字體改大”這樣的請求不是一個問題陳述，而是一個解決方案陳述。真正的問題是“此頁面在舊的 IE 瀏覽器上顯示不正?！?。遺憾的是，有時候需要工程師來提取上下文信息，因為經(jīng)常會缺少需求和工單。但好消息是，這通常并不難——只要說“讓我們復盤下——我們要解決的問題是什么”，99%的情況下你都能成功。

你是怎么想的？我漏掉了什么重要的東西嗎？我有什么地方理解的不對嗎？歡迎留言，以便我可以修改這篇文章。

相關(guān)連接

1. https://en.wikiquote.org/wiki/Murphy’s_law

2. https://www.angelo.edu/faculty/kboudrea/cheap/cheap3_murphy.htm#:~:text=Murphy's Second Law: Nothing is,the one to go wrong.

3. https://en.wikipedia.org/wiki/Conway’s_law

4. https://www.thoughtworks.com/en-us/radar/techniques/inverse-conway-maneuver

5. https://thenewstack.io/led-amazon-microservices-architecture/

6. https://www.britannica.com/topic/Greshams-law

7. https://itnext.io/greshams-law-why-bad-developers-push-out-good-developer-and-developers-create-low-quality-code-9b6a8d15bffb

8. https://dev.solita.fi/2020/06/16/cheap-software-is-expensive.html

9. https://wiki.c2.com/?DemoMeltdown

10. https://theappslab.com/2009/07/17/murphys-law-of-demos/

11. https://levelup.gitconnected.com/the-4-laws-of-the-software-demo-b74b79ca79e3?gi=5ec80c8efa29

12. https://www.hyrumslaw.com/

13. https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow