布魯克斯定律
它是由弗雷德·布魯克斯 (Fred Brooks) 在 1975 年出版的《人月神話》一書中提出的蛹批。他說“為后期的軟件項目增加人力會使其更晚交付”。
這個想法非常出乎意料捞挥，因為當(dāng)一個項目落后于計劃時，一個明顯的策略是嘗試增加來自組織其他部門的人員或新員工來幫助支持這項工作忧吟。
事實上砌函，增加團(tuán)隊成員會增加溝通成本，因為新員工會通過以下一些方式培養(yǎng)技能并對現(xiàn)有員工提出要求：檢測錯誤溜族、解釋代碼讹俊、閱讀設(shè)計文檔等。
康威定律
大約 50 年前煌抒，Mel Conway 在 Datamation 上發(fā)表了一篇名為“委員會如何發(fā)明仍劈？”的論文，其中探討了組織結(jié)構(gòu)與最終系統(tǒng)設(shè)計之間的關(guān)系寡壮。這個想法是系統(tǒng)的架構(gòu)將由公司的溝通和組織結(jié)構(gòu)決定贩疙。
菲茨定律
“獲取目標(biāo)的時間是到目標(biāo)的距離和目標(biāo)大小的函數(shù)”，這被稱為菲茨定律况既。根據(jù)他的定律这溅，由于速度與精度的權(quán)衡，快速移動和小目標(biāo)會導(dǎo)致更大的錯誤率棒仍。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
1978 年悲靴，施樂的員工使用菲茨定律來發(fā)現(xiàn)哪種輸入設(shè)備最適合他們的計算機(jī)系統(tǒng)。您可能需要執(zhí)行以下一些操作以將菲特定律應(yīng)用于您的用戶界面設(shè)計：
避免將任何按鈕設(shè)置得太小降狠，并且應(yīng)該將重要的按鈕設(shè)置大以便易于點擊对竣。
在光標(biāo)位置彈出菜單有助于減少移動距離庇楞，從而減少移動時間。
戏裎常克定律
希克定律說临燃，“用戶做出決定所需的時間取決于他們擁有的可能選擇的數(shù)量”睛驳。該定律聲稱，用戶從一個包含 10 個項目的菜單中做出選擇要比從兩個包含 5 個項目的菜單中更快地做出選擇膜廊。
? ? ? ? ? ? ? ? ? ??
該定律還指出乏沸，做出決定所需的時間受以下兩個因素的影響：
用戶對選擇的了解，例如來自重復(fù)使用爪瓜。
選擇的形式是聲音還是文字蹬跃、視頻或按鈕？
霍夫施塔特定律
認(rèn)知科學(xué)家 Douglas Hofstadter 創(chuàng)造了 Hofstadter 定律：
它總是比您預(yù)期的要長铆铆，即使您考慮了霍夫施塔特定律蝶缀。
當(dāng)然，沒有任何定律規(guī)定一切都必須枯燥薄货、乏味翁都、枯燥或乏味。但是當(dāng)執(zhí)行時谅猾，一切都會出錯柄慰，而且花費的時間比我們預(yù)期的要長。
克爾科夫斯原理
Kerckhoffs 原理指出税娜，“密碼系統(tǒng)的安全性必須僅在于其密鑰的選擇坐搔，其他一切（包括算法本身）都應(yīng)該被視為公共知識”。
這是公鑰密碼學(xué)的主要原理敬矩。它被廣泛接受并暗示算法必須有許多可能的密鑰薯蝎，密鑰空間必須非常大。
萊納斯定律
該定律由 Eric S. Raymond 在他的論文和著作 The Cathedral and the Bazaar (1999) 中提出谤绳，并以 Linus Torvalds（Linux 操作系統(tǒng)的首席開發(fā)人員）的名字命名。
如果有足夠的眼球袒哥，所有的錯誤都是淺薄的缩筛。
他認(rèn)為，通過盡可能多的人來識別并隨后更正錯誤堡称，可以最好地修復(fù)錯誤瞎抛。
梅特卡夫定律
梅特卡夫定律指出“系統(tǒng)的價值大約隨著系統(tǒng)用戶數(shù)量的平方增長”。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 整個網(wǎng)絡(luò)的連接總數(shù)為 (N·(N ? 1))/2~N2
換句話說却紧，如果你認(rèn)識的人數(shù)增加一倍桐臊，你的網(wǎng)絡(luò)價值就會增加四倍胎撤。
摩爾定律
這條以英特爾創(chuàng)始人戈登摩爾命名的定律預(yù)測，半導(dǎo)體晶體管的數(shù)量每 18 到 24 個月就會翻一番断凶。
今天伤提，硅芯片上安裝的晶體管增加一倍，幾乎每 18 個月而不是每 24 個月认烁。專家們一致認(rèn)為肿男，計算機(jī)應(yīng)該在 2020 年代的某個時候達(dá)到摩爾定律的物理極限。
帕累托原則
帕累托法則却嗡，也就是 80/20法則 舶沛，你聽說過嗎？這反映了“80% 的影響是 20% 原因的產(chǎn)物”窗价。
? ? ? ? ? ? ? 大多數(shù)人傾向于將大約 80% 的時間花在任務(wù)上如庭，以產(chǎn)生 20% 的結(jié)果。
這一原則可以普遍適用于商業(yè)領(lǐng)域撼港，并可以在社會各個部門找到坪它。我們甚至可以在日常生活的大部分領(lǐng)域使用它。例如餐胀，20% 的員工產(chǎn)生 80% 的工作哟楷，或 20% 的產(chǎn)品產(chǎn)生 80% 的利潤。
羅斯定律
每一個決定都是一次權(quán)衡否灾。
取自 Dan North 的演講Decisions,Decisions卖擅，它目前還不是公認(rèn)的定律。
開發(fā)者日復(fù)一日的生活中墨技，我們每天都做無數(shù)個大大小小的決定惩阶。從命名變量到自動化（手動）任務(wù)，再到定義平臺架構(gòu)扣汪。
這條語錄強(qiáng)調(diào)無論你做的選擇是什么断楷，你總會放棄一個或多個選項。
但這不是最重要的崭别。 最重要的是理智地做出決定冬筒，了解其他選項，清楚你為什么不選擇它們茅主。你要始終根據(jù)當(dāng)前你掌握的信息來權(quán)衡并做出決定舞痰。
但是如果后來你了解到新的信息，并發(fā)現(xiàn)之前的決定是錯誤的诀姚，這也沒關(guān)系响牛。關(guān)鍵是記清楚你為什么做出那個決定，重新評估新的選項之后再做出新的理智的決定。
奧卡姆剃刀
這句廣為人知的格言可以追溯到十四世紀(jì)一位名叫威廉奧卡姆的哲學(xué)家和修士呀打。奧卡姆剃刀通常被表述為：
在相互競爭的假設(shè)中矢赁，應(yīng)該選擇假設(shè)最少的假設(shè)。
我們能回憶起 600 多年前的格言的全部原因是它運(yùn)作良好贬丛，這并不奇怪撩银。奧卡姆剃刀原理是如此基礎(chǔ)，如此基本瘫寝，以至于在兩種相互競爭的理論之間做出決定時蜒蕾，它應(yīng)該是我們首先考慮的事情。
漢隆剃刀
有時我覺得用戶是故意要惹我生氣焕阿。他們按不應(yīng)該按的按鈕咪啡，發(fā)現(xiàn)了他們不應(yīng)該看到的缺陷（因為它們對我來說不是），并且通常使我生活中的大部分事情變得比原本更困難暮屡。
不過撤摸，我盡量記住，人們所做的絕大多數(shù)看似惡意的行為并非故意如此褒纲。相反准夷，這是因為他們不知道更多。這是一句名為Hanlon's Razor的格言的關(guān)鍵莺掠，它指出：
永遠(yuǎn)不要把可以用愚蠢充分解釋的事情歸咎于惡意衫嵌。
不要假設(shè)人們是惡意的，假設(shè)他們無知彻秆，然后幫助他們克服無知楔绞。大多數(shù)人想要學(xué)習(xí)，而不是為了好玩而刻薄唇兑。
鄧寧-克魯格效應(yīng)
研究人員大衛(wèi)·鄧寧和賈斯汀·克魯格在 1999 年進(jìn)行了一項實驗酒朵，觀察到了一種后來被稱為鄧寧-克魯格效應(yīng)的現(xiàn)象：
不熟練的人往往會錯誤地認(rèn)為自己的能力比實際能力強(qiáng)得多。
穩(wěn)健性原則（又名 Postel 定律）
軟件開發(fā)中的基本思想之一扎附，特別是 API 設(shè)計等領(lǐng)域蔫耽，可以用魯棒性原則簡潔地表達(dá)：
在自己所做的事情上要嚴(yán)格, 在接受別人的事情上要寬容。
這個原則也被稱為互聯(lián)網(wǎng)先驅(qū)Jon Postel 的Postel 定律留夜，他最初將其寫成RFC 760 的一部分匙铡。值得記住的是，除了溫和的提醒之外碍粥，最好的代碼通常是根本沒有代碼慰枕。
通常應(yīng)用于服務(wù)器應(yīng)用程序開發(fā)中，該原則指出即纲，你發(fā)送給其他人的內(nèi)容應(yīng)盡可能最小且符合要求，并且處理不符合要求的輸入博肋。
該原則的目標(biāo)是構(gòu)建穩(wěn)健的系統(tǒng)低斋。如果可以理解意圖蜂厅，它們可以處理不良的輸入。但是，接受錯誤格式的輸入可能存在安全隱患，特別是此類的輸入未經(jīng)過充分測試桂塞。
伊格森定律
曾經(jīng)遠(yuǎn)離一個項目很長時間倚搬，然后回到它并想知道“什么白癡寫了這個廢話？” 才發(fā)現(xiàn)那個白癡是你围苫？
伊格森定律非常準(zhǔn)確地描述了這種情況：
任何你六個月或更長時間都沒有看過的你自己的代碼也可能是由其他人編寫的。
請記住，下次您重新加入一個您已經(jīng)離開數(shù)月的項目時改橘。代碼不再是你的代碼，你現(xiàn)在的任務(wù)是改進(jìn)別人的玉控。
彼得原理
可以適用于管理人員（任何領(lǐng)域飞主，而不僅僅是軟件）的基本定律之一，是由加拿大教育家勞倫斯·J·彼得制定的彼得原則：
一個職位的候選人的選擇是基于候選人在當(dāng)前角色中的表現(xiàn)高诺，而不是與預(yù)期角色相關(guān)的能力碌识。
彼得原理揭示的問題是，員工往往會根據(jù)他們目前的表現(xiàn)得到評估虱而，而他們的上級認(rèn)為這些員工也能勝任不同的角色筏餐，即使他們目前的角色和預(yù)期的角色可能不一樣。最終牡拇，此類晉升會將不合格的候選人置于權(quán)力的高位魁瞪，在特別糟糕的情況下，您最終可能會在組織層級的每一步都出現(xiàn)尖頭發(fā)的老板诅迷。
呆伯特原理
談到尖頭發(fā)的老板佩番，漫畫家斯科特·亞當(dāng)斯（出版漫畫《呆伯特》）提出了彼得原理的一個負(fù)面變體，他將其命名為呆伯特原理罢杉。彼得原理假設(shè)被提拔的工人實際上能勝任他們目前的職位趟畏，這就是他們首先獲得晉升的原因。相比之下滩租，呆伯特原則假設(shè)最不稱職的人晉升最快赋秀。呆伯特原則通常是這樣表述的：
不稱職的員工將被提升到勝任員工之上的管理職位，從而將他們從實際工作中移除律想，并最大限度地減少他們可能造成的損害猎莲。
90-90 法則
因為事情總是會出錯，而且人們在估計自己的技能水平方面是出了名的糟糕技即，1980 年代貝爾實驗室的工程師 Tom Cargill 提出了一個最終被稱為90-90 規(guī)則的東西：
前 90% 的代碼占了前 90% 的開發(fā)時間著洼。其余 10% 的代碼占了其他 90% 的開發(fā)時間。
也許這解釋了為什么這么多軟件項目最終會超出預(yù)算并缺少功能。
帕金森定律
可以應(yīng)用于估算藝術(shù)的最精明的觀察可能來自英國海軍歷史學(xué)家CN Parkinson身笤。他開玩笑地提出了一句叫做帕金森定律的格言豹悬，最初的理解是：
工作擴(kuò)大以填補(bǔ)完成的可用時間。
在工作能夠完成的時限內(nèi)液荸，工作量會一直增加瞻佛，直到所有可用時間都被填滿為止。
基于官僚機(jī)構(gòu)的研究背景娇钱，該定律被應(yīng)用于軟件開發(fā)中伤柄。該理論認(rèn)為，團(tuán)隊在截止日期之前效率低下文搂，然后在截止日期前趕緊完成工作适刀，從而使實際截止日期變得隨意。
下次填寫估算值時請記住這一點细疚。
賽爾定律
經(jīng)濟(jì)學(xué)家兼教授Charles Issawi提出了一個后來被稱為賽爾定律的想法蔗彤，以哥倫比亞大學(xué)一位教授的名字命名。Issawi 對這條定律的表述如下：
在任何爭議中疯兼，感情的強(qiáng)度與所涉問題的價值成反比然遏。
簡而言之，越不重要的事情吧彪，人們就會越激烈地爭論它待侵。
帕金森瑣碎定律（AKA Bikeshedding）
賽爾定律直接適用于另一條適用于會議的定律，在這里我們再次遇到 CN Parkinson 的想法姨裸。帕金森瑣碎定律指出：
花在任何議程項目上的時間將與所涉及的資金總額成反比秧倾。
帕金森設(shè)想了這樣一種情況：一個委員會的任務(wù)是設(shè)計一個核反應(yīng)堆。然后傀缩，該委員會花費了不成比例的時間來設(shè)計反應(yīng)堆的自行車棚那先，因為任何普通人都有足夠的生活經(jīng)驗來了解自行車棚應(yīng)該是什么樣子。顯然赡艰，反應(yīng)堆的“核心”功能更為重要售淡，但它們是如此復(fù)雜，以至于普通人無法深入了解所有這些功能慷垮。因此揖闸，時間（和意見）被花在每個人都能理解但顯然更微不足道的想法上。
墨菲定律
如果你擔(dān)心那里出現(xiàn)問題料身，那里就會出錯汤纸。
Murphy 定律在項目管理，軟件開發(fā)和一般生活的所有領(lǐng)域都是可見的芹血。在軟件開發(fā)中贮泞，墨菲定律突出了一個關(guān)鍵：計算機(jī)做的是你告訴他們要做的事情楞慈，而不是你想要他們做什么。
古德哈特定律
當(dāng)衡量標(biāo)準(zhǔn)成為目標(biāo)時隙畜，它就不再是一個好的衡量標(biāo)準(zhǔn)抖部。
Goodhart 軟件開發(fā)定律的一個例子是代碼行數(shù)。代碼行數(shù)提供了一種衡量軟件產(chǎn)品大小的方法议惰。但是，當(dāng)用作目標(biāo)時乡恕，代碼的質(zhì)量會下降言询。
應(yīng)該根據(jù)軟件本身的結(jié)構(gòu)進(jìn)行精煉或分離，而不是一個混亂的意大利面條式代碼傲宜。
加爾法則
一個復(fù)雜的系統(tǒng)可以從一個有效的簡單系統(tǒng)發(fā)展而來运杭。而從頭開始構(gòu)建的復(fù)雜系統(tǒng)也許將無法工作。
我們在許多生命的復(fù)雜系統(tǒng)中看到這個定律函卒，例如辆憔，生命本身從單細(xì)胞生物開始，變得復(fù)雜报嵌。軟件開發(fā)也不例外虱咧。
Gall 法則如果成立（它似乎是成立的），是用最小可行產(chǎn)品（MVP）開始軟件產(chǎn)品開發(fā)的一個很好的理由锚国。
扎溫斯基定律
每個程序都會嘗試擴(kuò)展腕巡，直到它能夠讀取郵件。那些無法擴(kuò)展的程序被那些可以擴(kuò)展的程序所取代血筑。
說到復(fù)雜性绘沉，Zawinski 定律表明，一旦建成豺总，產(chǎn)品將繼續(xù)擴(kuò)大车伞。他們添加了更多功能，直到它們不再擴(kuò)展為止喻喳。
特征蠕變的實例反應(yīng)了 Zawinski 在軟件開發(fā)中的應(yīng)用另玖。隨著更加簡化的選項，臃腫的程序很快就會被淘汰沸枯。
盧巴爾斯基定律
還有一個錯誤日矫。
對于所有編程最佳實踐，更新和維護(hù)绑榴，總會有一個 bug 需要修復(fù)哪轿。或者還有一件事要調(diào)整翔怎，添加或?qū)W習(xí)窃诉。畢竟杨耙，程序員的工作從未完成。
所以飘痛，請記住珊膜，在軟件開發(fā)方面，完成比完美更好宣脉。
軟件開發(fā)的許多規(guī)律车柠，無論是定律，原則還是模式塑猖，每個軟件開發(fā)方法都有不同之處竹祷。這可能是一個有趣的見解，一個有用的教訓(xùn)羊苟，或一個簡單的興趣點塑陵。
阿姆達(dá)爾定律
阿姆達(dá)爾定律是一個顯示計算任務(wù)潛在加速能力的公式。這種能力可以通過增加系統(tǒng)資源來實現(xiàn)蜡励，通常用于并行計算中令花。它可以預(yù)測增加處理器數(shù)量的實際好處，然而增加處理器數(shù)量會受到程序并行性的限制凉倚。
舉例說明：如果程序由兩部分組成兼都，部分 A 必須由單個處理器執(zhí)行，部分 B 可以并行運(yùn)行占遥。那么向執(zhí)行程序的系統(tǒng)添加多個處理器只能獲得有限的好處俯抖。它可以極大地提升部分 B 的運(yùn)行速度，但部分 A 的運(yùn)行速度將保持不變瓦胎。
下圖展示了一些運(yùn)行速度的提升潛能的例子：
可以看出芬萍，50％ 并行化的程序在使用大于 10 個處理單元之后的速度提升收效甚微，而 95％ 并行化的程序在使用超過一千個處理單元之后仍然可以顯著提升速度搔啊。
隨著摩爾定律減慢柬祠，單個處理器的速度增加緩慢，并行化是提高性能的關(guān)鍵负芋。圖形編程是一個極好的例子漫蛔，現(xiàn)代著色器可以并行渲染單個像素或片段。這也是現(xiàn)代顯卡通常具有數(shù)千個處理核心（GPU 或著色器單元）的原因旧蛾。
鄧巴數(shù)字
鄧巴數(shù)字是對一個人能夠保持穩(wěn)定社會關(guān)系的人數(shù)的認(rèn)知極限——在這種關(guān)系中莽龟，一個人知道每個人是誰，也知道每個人與其他人的關(guān)系如何锨天。而對這一數(shù)字的確切值則有著一些不同意見毯盈。鄧巴指出，人僅能輕松地維持 150 個穩(wěn)定的關(guān)系病袄。這樣的關(guān)系在一個更社會化的背景中搂赋，便是當(dāng)你碰巧在酒吧里碰到這些人時候赘阀，你不會因為加入他們而感到尷尬。鄧巴數(shù)字的估計值一般在 100 至 250 之間脑奠。
和人與人之間穩(wěn)定的關(guān)系一樣基公，開發(fā)人員與代碼庫的關(guān)系也需要努力維護(hù)。當(dāng)面對大型宋欺、復(fù)雜的項目轰豆，或許多項目的歸屬權(quán)時，我們會依賴于約定齿诞、策略和建模過程來進(jìn)行擴(kuò)展秒咨。鄧巴數(shù)字不僅在辦公室規(guī)模的擴(kuò)大的過程中舉足輕重，而且在設(shè)置團(tuán)隊工作范圍掌挚，或決定系統(tǒng)何時應(yīng)該注重于輔助建模和組織管理開銷自動化的工具時，也是非常重要的菩咨。將鄧巴數(shù)字放入工程內(nèi)容中進(jìn)行類比吠式，那就是您能加入并有信心隨叫隨到進(jìn)行輪換的項目數(shù)(亦或是單個項目的規(guī)范化復(fù)雜性)。
技術(shù)成熟度曲線
我們傾向于過高估計技術(shù)在短期內(nèi)的影響抽米，并低估長期效應(yīng)特占。—— 羅伊·阿馬拉
技術(shù)成熟度曲線是高德納咨詢公司對技術(shù)最初興起和發(fā)展的視覺展現(xiàn)云茸。一圖頂千言：
簡而言之是目，這個周期表明，新技術(shù)及其潛在影響通常會引發(fā)一陣?yán)顺北贽唷F(tuán)隊快速使用這些新技術(shù)懊纳，有時會對結(jié)果感到失望。這可能是因為該技術(shù)還不夠成熟亡容，或者現(xiàn)實應(yīng)用還沒有完全實現(xiàn)嗤疯。經(jīng)過一段時間后，技術(shù)的能力提高了闺兢，使用它的實際機(jī)會會增加茂缚，最終團(tuán)隊也可以提高工作效率。羅伊·阿馬拉簡潔地總結(jié)了這一點：我們傾向于高估技術(shù)短期內(nèi)的影響屋谭，并低估長期效應(yīng)脚囊。
隱式接口定律
當(dāng) API 有足夠多的用戶時，你在契約中的承諾已不重要：你系統(tǒng)的所有可觀察行為都將被某些人所依賴桐磁。 —— 海倫·賴特
隱式接口定律表明悔耘，當(dāng)你的 API 有足夠多的用戶時，API 的所有行為（包括那些未囊括在公共說明中的一部分）最終都會被其他人所依賴所意。一個簡單的例子是 API 的響應(yīng)時間這種非功能性因素淮逊，還有一個更微妙的例子是：用戶使用正則表達(dá)式判斷錯誤信息的類型時催首，即使 API 的公共說明沒有說明消息的內(nèi)容，來指示用戶錯誤的類型泄鹏，一些用戶也可能會使用并更改該消息郎任，而這實際上會破壞 API 的使用。
過早優(yōu)化效應(yīng)
過早優(yōu)化是萬惡之源备籽〔爸危—— 高納德
在高納德的《goto 語句的結(jié)構(gòu)化編程》論文中，他寫到车猬，程序員花了大量的時間思考和擔(dān)心非關(guān)鍵部分的速度霉猛，這些嘗試在調(diào)試以及維護(hù)時會產(chǎn)生強(qiáng)烈的副作用。我們大約 97% 的時間浪費在小效率上珠闰。過早優(yōu)化是萬惡之源惜浅。我們應(yīng)該關(guān)注 3% 的關(guān)鍵部分。
然而伏嗜，在我們真正需要優(yōu)化時坛悉，過早優(yōu)化可以定義為優(yōu)化。
普特定律
? ? ? ? ? ? 技術(shù)由兩類人主導(dǎo)承绸，一類是純粹的管理人員裸影， 一類是純粹的技術(shù)人員。
普特定律常常遵循普特推論：
? ? ? ? ? ? 每一個技術(shù)層次军熏，假以時日轩猩，能力將逆轉(zhuǎn)。
這些結(jié)論表明荡澎，由于各種選擇標(biāo)準(zhǔn)和群體組織的趨勢均践，技術(shù)組織的工作層面將有一些技術(shù)人員，以及一些不了解復(fù)雜性和挑戰(zhàn)的管理人員衔瓮。這種現(xiàn)象可能是由于 The Peter Principe 或 Dilbert's Law 造成的浊猾。
但是，應(yīng)該強(qiáng)調(diào)的是热鞍，諸如此類的定律是一種廣泛的概括葫慎，可能適用于某些類型的組織，而不適用于其他組織薇宠。
復(fù)雜性守恒定律
系統(tǒng)中的某些復(fù)雜性是無意的偷办。這是由于結(jié)構(gòu)不良，錯誤或者糟糕的建模造成的澄港。這種無意的復(fù)雜性可以減少或者消除椒涯。然而，由于待解決問題固有的復(fù)雜性回梧，某些復(fù)雜性是內(nèi)在的废岂。這種復(fù)雜性可以轉(zhuǎn)移祖搓，但不能消除。
該定律有趣的一點是湖苞，即使簡化整個系統(tǒng)拯欧，內(nèi)在的復(fù)雜性也不會降低。它會轉(zhuǎn)移到用戶财骨，并且用戶必須以更復(fù)雜的方式行事镐作。
抽象泄漏定律
在某種程度上，所有非平凡的抽象都是有泄漏的隆箩「眉郑—— 喬爾斯·波爾斯基
該定律指出，通常用于簡化復(fù)雜系統(tǒng)的抽象捌臊，在某些情況下將底層系統(tǒng)泄漏出來杨蛋，使得抽象表現(xiàn)出意外的行為。
例如加載文件并讀取其內(nèi)容理澎。文件系統(tǒng) API 是較低級別內(nèi)核系統(tǒng)的抽象六荒，它們本身是與磁盤（或 SSD 的閃存）上的數(shù)據(jù)更改相關(guān)的物理過程的抽象。在大多數(shù)情況下矾端，處理文件（如二進(jìn)制數(shù)據(jù)流）的抽象將起作用。但是卵皂，對于磁盤驅(qū)動器秩铆，順序讀取數(shù)據(jù)將比隨機(jī)訪問快得多（由于頁面錯誤的開銷增加）。但對于 SSD 驅(qū)動器灯变，此開銷不會出現(xiàn)殴玛。需要理解基礎(chǔ)細(xì)節(jié)來處理這種情況（例如，數(shù)據(jù)庫索引文件的良好結(jié)構(gòu)可以減少隨機(jī)訪問的開銷）添祸，開發(fā)人員需要合理的抽象滚粟，來處理不同的細(xì)節(jié)。
當(dāng)引入更多的抽象時刃泌，上面的例子會變得更復(fù)雜凡壤。Linux 操作系統(tǒng)允許通過網(wǎng)絡(luò)訪問文件，但在本地表示為普通文件耙替。如果存在網(wǎng)絡(luò)故障亚侠，這種抽象將會泄漏。
描述該定律的文章表明俗扇，過度依賴抽象硝烂，加上對底層過程的理解不足，實際上使得問題在某些情況下更加復(fù)雜铜幽。
Unix 哲學(xué)
Unix 哲學(xué)指軟件組件應(yīng)該很小滞谢，并專注于做一件特定的事情串稀。將小而簡單以及定義良好的單元組合在一起，而不是使用大而復(fù)雜的多用途程序狮杨，可以更輕松地構(gòu)建系統(tǒng)母截。
像微服務(wù)架構(gòu)這種現(xiàn)代實踐可以認(rèn)為是這種哲學(xué)的應(yīng)用，其中服務(wù)很小禾酱，集中于做一件特定的事情微酬，由簡單的構(gòu)建塊組成復(fù)雜的行為。
Spotify 模型
Spotify 模型是團(tuán)隊和組織結(jié)構(gòu)的一種方法颤陶，已被 Spotify 實驗室推廣開來颗管。在此模型中，團(tuán)隊圍繞功能而非技術(shù)進(jìn)行組織滓走。
Spotify 模型還普及了部落垦江、行會以及章節(jié)的概念，這些是組織結(jié)構(gòu)的其他組成部分搅方。
沃德勒定律
任何語言設(shè)計中比吭，討論下面列表中某個要素所花費的總時間與其位置成正比。
語義 (Semantics)
語法 (Syntax)
詞法 (Lexical syntax)
注釋語法 (Lexical syntax of comments)
簡而言之姨涡，在語義上花費一個小時衩藤，就要在注釋語法上花費八個小時。
與帕金森瑣碎定理類似涛漂，沃德勒定律指出赏表，在設(shè)計語言時，與這些特征的重要性相比匈仗，花在語言結(jié)構(gòu)上的時間過多瓢剿。
第二系統(tǒng)效應(yīng)
第二系統(tǒng)效應(yīng)（second-system effect），又稱第二系統(tǒng)癥候群（second-system syndrome）悠轩，由佛瑞德·布魯克斯在《人月神話》中提出的經(jīng)驗概括间狂。它認(rèn)為，在完成一個小型火架、優(yōu)雅而成功的系統(tǒng)之后鉴象，人們傾向于對下一個計劃有過度的期待，可能因此建造出一個巨大何鸡、有各種特色的怪獸系統(tǒng)炼列。第二系統(tǒng)效應(yīng)可能造成軟件專案計劃過度設(shè)計，產(chǎn)生太多變數(shù)音比，過度復(fù)雜俭尖，無法達(dá)成期待，并因而失敗。
