GitHub 熱榜：標星 1.6w，黑客必看的黑魔法開發(fā)指南！

還記得所有AI教程必提的「奧卡姆剃刀原則」嗎？即：如無必要，勿增實體。這條原則也被收藏，還有一些不太常見的費茨法則、蓋爾定律、康威定律等，都被一一收入囊中。

?

寫代碼累了困了？這些法則讓工作事半功倍

?

90-9-1法則（1%法則）

?

90-9-1 法則表明，在諸如維基這樣的互聯(lián)網(wǎng)社區(qū)中，90% 的用戶只看內(nèi)容并不參與互動，9% 的用戶會參與討論，而只有 1% 的用戶會創(chuàng)造內(nèi)容。

?? ? ? ?

現(xiàn)實世界的例子：2014 年，對四個健康的數(shù)字社交網(wǎng)絡進行的一項研究發(fā)現(xiàn)，排名前 1% 的人創(chuàng)造了 73% 的帖子，緊隨其后的 9% 平均占 25%，其余的 90% 的人平均占 2%。

?

類似的，帕累托法則也指出：生活中大多數(shù)事情不是均勻分布的。這個原則也被稱為二八法則，重要的少數(shù)法則和因素稀疏原則。

?

技術成熟度曲線法則

?

技術成熟度曲線是高德納咨詢公司對技術最初興起和發(fā)展的視覺展現(xiàn)。一圖勝千言：

?? ? ? ?? ? ? ?

?簡而言之，這個曲線表明，新技術及其潛在影響通常會引發(fā)一輪浪潮。團隊快速使用這些新技術，但有時會對結果感到失望，這可能是因為該技術還不夠成熟，或者現(xiàn)實應用還沒有完全實現(xiàn)。

?

經(jīng)過一段時間后，技術的能力提高了，使用它的實際機會會增加，最終團隊也可以提高工作效率。

羅伊·阿馬拉簡潔地總結了這一點：我們傾向于高估技術短期內(nèi)的影響，并低估其長期效應。

?

破窗效應

?

在破窗理論中認為，一些明顯的犯罪跡象(或缺乏環(huán)保意識)會導致進一步的、更嚴重的犯罪(或環(huán)境的進一步惡化)。

?

破窗理論已應用于軟件開發(fā)中，它表明劣質(zhì)代碼可能會影響后續(xù)優(yōu)化的效率，從而進一步造成代碼劣化；隨著時間的推移，這種效應將會導致代碼質(zhì)量大幅下降。

?

沒那么常見的法則，但也暗藏工作秘訣

?

阿姆達爾定律

?

阿姆達爾定律是一個顯示計算任務潛在加速能力的公式。這種能力可以通過增加系統(tǒng)資源來實現(xiàn)，通常用于并行計算中。

它可以預測增加處理器數(shù)量的實際好處，然而增加處理器數(shù)量會受到程序并行性的限制。

?

舉例說明：如果程序由兩部分組成，A部分必須由單個處理器執(zhí)行，B部分可以并行運行。那么向執(zhí)行程序的系統(tǒng)添加多個處理器只能獲得有限的好處。

它可以極大地提升部分 B 的運行速度，但部分 A 的運行速度將保持不變。

?

下圖展示了一些運行速度的提升潛能的例子：

?? ? ? ?? ? ? ?

可以看出，50％ 并行化的程序在使用大于 10 個處理單元之后的速度提升收效甚微，而 95％ 并行化的程序在使用超過一千個處理單元之后仍然可以顯著提升速度。

?

隨著摩爾定律逐漸失效，單個處理器的速度增加緩慢，并行化是提高性能的關鍵。

圖形編程是一個極好的例子，現(xiàn)代著色器可以并行渲染單個像素或片段。這也是現(xiàn)代顯卡通常具有數(shù)千個處理核心（GPU 單元）的原因。

?

德墨忒爾定律

?

得墨忒耳定律又稱最少知識原則，是一條與面向?qū)ο笳Z言有關的軟件設計原則。

?

該定律表明，軟件的一個單元應該只與其直接合作者交談。

?

比如對象 A 引用了對象 B，對象 B 引用了對象 C，則 A 可以直接調(diào)用 B 的方法，但不應直接調(diào)用 C 的方法。所以如果 C 有一個 dothing()?的方法，A 不應該直接調(diào)用，而是用 B.getC().doThis()。

遵循這一定律可以限制代碼更改的范圍，使其以后更容易維護、更安全。

?

坎寧漢姆定律

?

在網(wǎng)絡上想得到正確答案的最好方法不是提問題，而是發(fā)布一個錯誤的答案。

?

除了以上的這些法則，該倉庫還給出了很多的原則。

?

職場相關原則

??

死海效應原則：在任何一個組織中，工程師的技能、才華和效能往往與他們在公司的時間呈反比。

能力強的人更有可能離開，能力差的人反而會留下。

?

呆伯特原則：公司會傾向于系統(tǒng)地將工作能力差的員工提升到管理層，以使他們脫離工作流程。

?? ? ? ?? ? ? ?

技術相關的原則：

?

單一功能原則：每個模塊或者類只應該有一項功能。

?

開閉原則：實體應開放擴展并關閉修改。

?

里氏替換原則：可以在不破壞系統(tǒng)的情況下，用子類型替換類型。

?

接口隔離原則：不應強制任何客戶端依賴于它不使用的方法。

?

依賴翻轉(zhuǎn)原則：高級模塊不應該依賴于低級實現(xiàn)。

?

還有一些具有哲學意味的原則：

?

魯棒性原則：在自己所做的事情上要保守, 在接受別人的事情上要自由。

?

你不需要它法則：只有當你需要某些東西的時候，才去實現(xiàn)它們，而不是在你預見的時候。

?

KISS原則：保持簡單和直白。

?

還有很多的法則和原則沒有一一指出，需要的小伙伴請點擊下面的鏈接打開查看。

參考鏈接：

https://github.com/nusr/hacker-laws-zh

往期熱文推薦：
鴻蒙和安卓，到底有什么區(qū)別？
SQL 編程思想：一切皆關系！
學習了！對我影響最深刻的一次代碼重構
【項目】Java身份證號碼識別系統(tǒng)