作一個(gè)優(yōu)秀的程序員,除了要會(huì)寫代碼,還要懂得職場的15大定律和7大原則。昨日,GitHub趨勢榜第一的項(xiàng)目便總結(jié)了這些定律和原則。總有一款適合你。
總有一款適合你。
作為程序員,你除了會(huì)敲代碼,還得知曉屬于你的定律。今日GitHub便有一個(gè)項(xiàng)目總結(jié)了與開發(fā)人員相關(guān)的15大定律和7大原則。
項(xiàng)目地址:
https://github.com/dwmkerr/hacker-laws
該項(xiàng)目目錄如下:
簡介
定律
阿姆達(dá)爾定律(Amdahl's Law)
布魯克定律(Brooks's Law)
康威定律(Conway's Law)
阿瑪拉定律的“炒作周期”(The Hype Cycle & Amara's Law)
海勒姆定律(Hyrum's Law)
摩爾定律(Moore's Law)
帕金森定律(Parkinson's Law)
普特定律(Putt's Law)
泰斯勒定律(復(fù)雜性守恒定律,Tesler's Law)
抽象化漏洞定律(The Law of Leaky Abstractions)
瑣碎定律(The Law of Triviality)
Unix哲學(xué)(The Unix Philosophy)
Spotify模型(The Spotify Model)
Wadler定律(Wadler's Law)
原則
魯棒性原則(The Robustness Principle,Postel's Law)
SOLID
單一職責(zé)原則(The Single Responsibility Principle)
開放封閉原則(The Open/Closed Principle)
李氏替換原則(The Liskov Substitution Principle)
接口分離原則(The Interface Segregation Principle)
依賴倒置原則(The Dependency Inversion Principle)
TODO
那么接下來,我們就對這些定律和原則進(jìn)行一一解讀。
開發(fā)人員需知的15大定律
阿姆達(dá)爾定律(Amdahl's Law)
維基百科中對此定律的解讀是:
阿姆達(dá)爾定律,一個(gè)計(jì)算機(jī)科學(xué)界的經(jīng)驗(yàn)法則,因吉恩·阿姆達(dá)爾而得名。它代表了處理器并行運(yùn)算之后效率提升的能力。并行計(jì)算中的加速比是用并行前的執(zhí)行速度和并行后的執(zhí)行速度之比來表示的,它表示了在并行化之后的效率提升情況。阿姆達(dá)爾定律是固定負(fù)載(計(jì)算總量不變時(shí))時(shí)的量化標(biāo)準(zhǔn)。
此處舉個(gè)例子來說明:如果一個(gè)程序由兩部分組成,一部分A(必須由一個(gè)處理器執(zhí)行)和一部分B(可以并行執(zhí)行),那么我們可以看到,向執(zhí)行程序的系統(tǒng)添加多個(gè)處理器只能帶來有限的好處。它可以極大地提高B部分的速度,但是A部分的速度將保持不變。
下圖顯示了速度可能改進(jìn)的一些示例:
可以看出,即使是一個(gè)50%可并行的程序,在超過10個(gè)處理單元的情況下也幾乎沒有什么好處,而一個(gè)95%可并行的程序,在超過1000個(gè)處理單元的情況下,仍然可以顯著提高速度。
隨著摩爾定律(Moore’s Law)的放緩,以及單個(gè)處理器速度的加速放緩,并行化是提高性能的關(guān)鍵。圖形編程是一個(gè)很好的例子(使用現(xiàn)代基于著色器的計(jì)算,單個(gè)像素或片段可以并行呈現(xiàn)),這就是為什么現(xiàn)代顯卡通常有成千上萬的處理核心(gpu或著色器單元)。
布魯克定律(Brooks's Law)
維基百科中對此定律的解讀是:
將人力資源添加到一個(gè)后期軟件開發(fā)項(xiàng)目中會(huì)使它更晚。
這條定律表明,在許多情況下,試圖通過增加更多的人來加速已經(jīng)晚了的項(xiàng)目,將使交付日期更晚。該定律楚地表明這是一種過度簡化,但一般的推理是,鑒于新資源的增加時(shí)間和通信開銷,在短期內(nèi)的速度會(huì)降低。而且,許多任務(wù)可能不是可分的,即容易在更多資源之間分配,這意味著潛在的速度增長也更低。
交付工作中常見的一句話,“九個(gè)女人不能在一個(gè)月內(nèi)生孩子”是與布魯克斯定律有關(guān),特別是某些工作不可分割或平行的事實(shí)。
康威定律(Conway's Law)
維基百科中對此定律的解讀是:
這條法律表明,一個(gè)系統(tǒng)的技術(shù)邊界將反映組織的結(jié)構(gòu)。
設(shè)計(jì)系統(tǒng)的組織受限于設(shè)計(jì)這些組織的通信結(jié)構(gòu)的副本。
這條定律表明,一個(gè)系統(tǒng)的技術(shù)邊界將反映組織的結(jié)構(gòu)。康威定律表明,如果一個(gè)組織是由許多小的、不相連的單元組成的,那么它所生產(chǎn)的軟件將是如此。如果一個(gè)組織更多地圍繞功能或服務(wù)的“垂直領(lǐng)域”構(gòu)建,軟件系統(tǒng)也會(huì)反映出這一點(diǎn)。
侯世達(dá)定律(Hofstadter's Law)
維基百科中對此定律的解讀是:
即使考慮了侯世達(dá)定律,它也總是比你想象的要花更長的時(shí)間。
當(dāng)你在估計(jì)某件事需要多長時(shí)間的時(shí)候,你可能聽說過這個(gè)定律。在軟件開發(fā)中,我們往往不擅長準(zhǔn)確地估計(jì)某個(gè)東西需要多長時(shí)間才能交付,這似乎是一個(gè)老生常談的事實(shí)。
阿瑪拉定律的“炒作周期”(The Hype Cycle & Amara's Law)
維基百科中對此定律的解讀是:
我們傾向于過高估計(jì)技術(shù)在短期內(nèi)的影響,并低估長期效應(yīng)。
Hype Cycle(炒作周期)是技術(shù)隨著時(shí)間的推移而產(chǎn)生的興奮和發(fā)展的直觀表現(xiàn),最初由Gartner開發(fā)。最好用視覺效果來表現(xiàn):
簡而言之,這一周期表明,人們通常對新技術(shù)及其潛在影響感到興奮。團(tuán)隊(duì)經(jīng)常快速地投入到這些技術(shù)中,有時(shí)會(huì)對結(jié)果感到失望。這可能是因?yàn)榧夹g(shù)還不夠成熟,或者現(xiàn)實(shí)世界的應(yīng)用還沒有完全實(shí)現(xiàn)。經(jīng)過一段時(shí)間,技術(shù)的能力和使用它的實(shí)際機(jī)會(huì)都會(huì)增加,團(tuán)隊(duì)最終會(huì)變得富有成效。羅伊?阿馬拉(Roy Amara)的名言最簡潔地概括了這一點(diǎn)——“我們往往高估了一項(xiàng)技術(shù)的短期效果,而低估了長期效果。”
海勒姆定律(Hyrum's Law)
維基百科中對此定律的解讀是:
有足夠數(shù)量的API用戶,您在公約中承諾的并不重要:系統(tǒng)的所有可觀察行為都將取決于某人。
Hyrum定律指出,當(dāng)一個(gè)API有足夠多的消費(fèi)者時(shí),這個(gè)API的所有行為(甚至那些沒有被定義為公約的一部分的行為)最終都會(huì)被某人所依賴。一個(gè)簡單的例子可能是非功能元素,比如API的響應(yīng)時(shí)間。一個(gè)更微妙的例子可能是依賴于對錯(cuò)誤消息應(yīng)用正則表達(dá)式來確定API錯(cuò)誤類型的消費(fèi)者。
即使API的公約沒有聲明關(guān)于消息內(nèi)容的任何內(nèi)容,表明用戶應(yīng)該使用相關(guān)的錯(cuò)誤代碼,一些用戶也可能使用消息,更改消息實(shí)際上會(huì)破壞這些用戶的API。
摩爾定律(Moore's Law)
維基百科中對此定律的解讀是:
摩爾的預(yù)測經(jīng)常被用來說明半導(dǎo)體和芯片技術(shù)進(jìn)步的絕對速度。事實(shí)證明,從上世紀(jì)70年代到本世紀(jì)頭十年末,摩爾的預(yù)測是非常準(zhǔn)確的。近年來,這一趨勢發(fā)生了輕微的變化,部分原因是對組件小型化程度的物理限制。然而,并行化的進(jìn)步,以及半導(dǎo)體技術(shù)和量子計(jì)算領(lǐng)域潛在的革命性變化,可能意味著摩爾定律在未來幾十年仍將適用。
帕金森定律(Parkinson's Law)
維基百科中對此定律的解讀是:
工作量不斷增大,以填補(bǔ)滿足工作所需的截止時(shí)間。
在其最初的背景下,這個(gè)定律是基于對官僚機(jī)構(gòu)的研究。它可能被"悲觀"地應(yīng)用于軟件開發(fā)計(jì)劃,理論是團(tuán)隊(duì)在截止日期之前效率低下,然后在截止日期前趕緊完成工作,從而使得實(shí)際截止日期變得有些隨意。
如果將這一定律與侯世達(dá)定律結(jié)合起來,就會(huì)得出一個(gè)更加悲觀的觀點(diǎn)——工作量將會(huì)增大,以填補(bǔ)完成它所需要的時(shí)間,而且仍然比預(yù)期的要長。
普特定律(Putt's Law)
維基百科中對此定律的解讀是:
技術(shù)由兩類人主導(dǎo),一類人懂他們不并需要管理的事務(wù),另一類人管理者他們不懂的事務(wù)。
普特定律往往遵循普特推理(Putt's Corollary):
隨著時(shí)間的推移,每一個(gè)技術(shù)層次都會(huì)發(fā)展出一種能力倒置。
這些陳述表明,由于各種選擇標(biāo)準(zhǔn)和群體組織方式的趨勢,技術(shù)組織的工作層面將有一些技術(shù)人員,以及一些不了解復(fù)雜性和挑戰(zhàn)的管理角色的人員。
然而需要強(qiáng)調(diào)的是,此類定律是廣泛的概括,可能適用于某些類型的組織,而不適用于其他類型的組織。
泰斯勒定律(復(fù)雜性守恒定律,Tesler's Law)
維基百科中對此定律的解讀是:
這條定律表明,一個(gè)系統(tǒng)中有一定程度的復(fù)雜性是無法降低的。
系統(tǒng)中的某些復(fù)雜性是“無意的”。 這是由于結(jié)構(gòu)不良、錯(cuò)誤或者只是解決問題的糟糕建模造成的。 可以減少(或消除)這種“無意”的復(fù)雜性。然而,一些復(fù)雜性是“內(nèi)在的”,這是所解決問題內(nèi)在復(fù)雜性的結(jié)果。這種復(fù)雜性可以轉(zhuǎn)移,但不能消除。
這個(gè)定律中一個(gè)有趣的點(diǎn),即使簡化了整個(gè)系統(tǒng),內(nèi)在的復(fù)雜性也沒有減少,而是轉(zhuǎn)移到了用戶身上,用戶必須以更復(fù)雜的方式行事。
抽象化漏洞定律(The Law of Leaky Abstractions)
維基百科中對此定律的解讀是:
在某種程度上,所有非平凡(non-trivial)抽象都是有漏洞的。
該定律指出,抽象化(通常用于計(jì)算以簡化復(fù)雜系統(tǒng)的工作)在某些情況下會(huì)“泄漏”底層系統(tǒng)的元素,這使得抽象化的行為方式出人意料。
加載文件并讀取其內(nèi)容就是一個(gè)例子。文件系統(tǒng)API是較低層內(nèi)核系統(tǒng)的抽象,內(nèi)核系統(tǒng)本身是與更改磁盤片(或SSD的閃存)上的數(shù)據(jù)相關(guān)的物理進(jìn)程的抽象。在大多數(shù)情況下,將文件處理為二進(jìn)制數(shù)據(jù)流的抽象是可行的。然而,對于磁驅(qū)動(dòng)器,順序讀取數(shù)據(jù)的速度將明顯快于隨機(jī)訪問(由于頁面錯(cuò)誤的開銷增加),但是對于SSD驅(qū)動(dòng)器,不會(huì)出現(xiàn)這種開銷。處理這種情況需要了解底層細(xì)節(jié)(例如,數(shù)據(jù)庫索引文件的結(jié)構(gòu)是為了減少隨機(jī)訪問的開銷),開發(fā)人員可能需要了解抽象的“泄漏”實(shí)現(xiàn)細(xì)節(jié)。
當(dāng)引入更多抽象時(shí),上面的示例可能會(huì)變得更加復(fù)雜。Linux操作系統(tǒng)允許通過網(wǎng)絡(luò)訪問文件,但在本地表示為“普通”文件。如果存在網(wǎng)絡(luò)故障,這個(gè)抽象將會(huì)“泄漏”。如果開發(fā)人員將這些文件視為“正常”文件,而沒有考慮到它們可能會(huì)受到網(wǎng)絡(luò)延遲和故障的影響,那么解決方案就會(huì)有bug。
瑣碎定律(The Law of Triviality)
維基百科中對此定律的解讀是:
這一定律表明,團(tuán)體將把更多的時(shí)間和精力放在瑣碎或表面現(xiàn)象上,而不是嚴(yán)肅和實(shí)質(zhì)性的問題。
Unix哲學(xué)(The Unix Philosophy)
維基百科中對此定律的解讀是:
Unix哲學(xué)是軟件組件應(yīng)該很小,并且專注于做好一件特定的事情。通過將小的、簡單的、定義良好的單元組合在一起,而不是使用大型的、復(fù)雜的、多用途的程序,可以更容易地構(gòu)建系統(tǒng)。
像“微服務(wù)體系結(jié)構(gòu)”這樣的現(xiàn)代實(shí)踐可以被看作是這條定律的一個(gè)應(yīng)用,此處,服務(wù)是小的、集中的,并且只做一件特定的事情,允許由簡單的構(gòu)建塊組成復(fù)雜的行為。
Spotify模型(The Spotify Model)
維基百科中對此定律的解讀是:
Spotify模型是團(tuán)隊(duì)和組織結(jié)構(gòu)的一種方法,已被“Spotify”推廣。在這個(gè)模型中,團(tuán)隊(duì)是圍繞功能而不是技術(shù)來組織的。
Spotify模型還普及了部落、公會(huì)、分會(huì)等組織結(jié)構(gòu)的其它組成部分。
Wadler定律(Wadler's Law)
維基百科中對此定律的解讀是:
在任何語言設(shè)計(jì)中,討論這個(gè)列表中某個(gè)特性所花費(fèi)的總時(shí)間與它位置的冪成正比。
0.語義
1.語法
2.詞匯語法
3.注釋的詞匯語法
類似于“瑣碎定律”,Wadler定律指出,在設(shè)計(jì)一種語言時(shí),與這些特征的重要性相比,花在語言結(jié)構(gòu)上的時(shí)間是不成比例的。
-
摩爾定律
+關(guān)注
關(guān)注
4文章
638瀏覽量
79777 -
代碼
+關(guān)注
關(guān)注
30文章
4894瀏覽量
70480 -
程序員
+關(guān)注
關(guān)注
4文章
954瀏覽量
30332
原文標(biāo)題:【GitHub金牌】程序員必讀職場15大定律和7大原則
文章出處:【微信號(hào):AI_era,微信公眾號(hào):新智元】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
低代碼與傳統(tǒng)開發(fā)的區(qū)別 低代碼與無代碼開發(fā)的區(qū)別
五大云計(jì)算平臺(tái)的建設(shè)原則,缺一不可!
阿里云升級通義靈碼AI程序員,全面上線
TMS320C55x DSP CPU程序員參考補(bǔ)充

UCD3138A64/UCD3138128程序員手冊

機(jī)械革命發(fā)布CODE AI程序員本
Java代碼之美,從遵循樣式規(guī)范開始

Linux驅(qū)動(dòng)程序程序員指南

AI編程工具會(huì)不會(huì)搶程序員飯碗
第五屆長沙·中國1024程序員節(jié)開幕
京東上萬程序員都AI用它!

程序員節(jié)視頻創(chuàng)意大賽,用串口屏贏取千元大獎(jiǎng)

程序員節(jié)視頻創(chuàng)意盛宴,邀您共襄盛舉!

助力程序員告別困擾已久的夢魘-Bug

評論