20 年老程序员告诉你的 20 条编码原则
英文原文:My guiding principles after 20 years of programming
我從 1999 年就開始了編程生涯,到今年已經(jīng)有 20 多年了。我先是從 Basic 開始,很快轉(zhuǎn)到了 Pascal 和 C 語言,然后又學(xué)習(xí)了面向?qū)ο缶幊陶Z言 Delphi 和 C++。2006 年,我開始使用 Java,2011 年開始使用 JavaScript。我參與過各個(gè)行業(yè)的軟件開發(fā),從機(jī)器人、金融科技、醫(yī)療到媒體和通信。我還擔(dān)任過研究員、CTO、TPM(技術(shù)產(chǎn)品經(jīng)理)、老師、系統(tǒng)架構(gòu)師和技術(shù)負(fù)責(zé)人,但不管怎樣,我一直都在編程。
在我參與過的項(xiàng)目當(dāng)中,有些為數(shù)百萬人提供服務(wù),有些在發(fā)布之前就宣告失敗。我做過咨詢顧問,還創(chuàng)辦過自己的公司。我在開源項(xiàng)目、閉源項(xiàng)目和內(nèi)部開源項(xiàng)目上花了很多時(shí)間,從微控制器到移動(dòng)應(yīng)用、桌面應(yīng)用,再到云服務(wù)和無服務(wù)器架構(gòu)。
我把過去 20 年積累的一些最為重要的編程原則總結(jié)如下。
-
不要糾結(jié)于開發(fā)工具——不管是庫、編程語言還是平臺(tái)。盡可能使用原生的構(gòu)件。不要歪曲技術(shù),也不要歪曲了問題本身。為要解決的問題選擇合適的工具,否則你要為你所選擇的工具重新安排你的工作。
-
你寫的代碼不是給機(jī)器看的,而是給你的同事和未來的你看的(除非你寫的是一次性代碼或匯編代碼)。寫代碼的時(shí)候要考慮一下初級(jí)開發(fā)者,他們會(huì)把你的代碼作為參考。
-
優(yōu)秀的軟件是協(xié)作開發(fā)的結(jié)果。高效溝通,進(jìn)行開放式的協(xié)作。信任他人,并讓他人也信任你。尊重他人勝過尊重代碼。以身作則,把你的追隨者變成領(lǐng)導(dǎo)者。
-
分而治之。為分離的關(guān)注點(diǎn)開發(fā)單獨(dú)的低耦合模塊。進(jìn)行單獨(dú)的模塊測試和集成測試。盡可能按照實(shí)際情況測試,同時(shí)也要測試到各種邊界情況。
-
不要把自己與代碼捆綁在一起,要想辦法讓其他人也能修改你的代碼或者添加新的功能,這樣你才能更容易脫身去參與其他項(xiàng)目,或者去其他公司。不要捆綁自己,否則你很難成長。
-
安全性是分層的,每一層需要進(jìn)行單獨(dú)的評(píng)估,同時(shí)又與整體相關(guān)。風(fēng)險(xiǎn)是一個(gè)業(yè)務(wù)決策,與脆弱性和概率有直接的關(guān)系。每一個(gè)產(chǎn)品或組織都有不同的風(fēng)險(xiǎn)偏好(為了獲得更大的收益,他們?cè)敢獬袚?dān)風(fēng)險(xiǎn))。通常這三個(gè)關(guān)注點(diǎn)之間存在相互沖突:用戶體驗(yàn)、安全性和性能。
-
要意識(shí)到每一行代碼都有其生命周期,它們最終都會(huì)死掉。有時(shí)候,一些代碼會(huì)在發(fā)布之前就死掉,所以要學(xué)會(huì)放手。代碼可以分為三種:一種是核心代碼,就像汽車的引擎,沒有了它,產(chǎn)品就毫無意義;一種是必要的代碼,就像是汽車的備胎,平時(shí)用得少,但一旦需要,它決定了系統(tǒng)的成敗;一種是增值的代碼,就像汽車的杯托,如果有那是再好不過,但如果沒有也不會(huì)影響產(chǎn)品。
-
不要把你的個(gè)人標(biāo)識(shí)融入到代碼里,人和代碼應(yīng)該是分離的。不要把其他人對(duì)代碼的評(píng)價(jià)與你自身聯(lián)系到一起,在評(píng)價(jià)他人的代碼時(shí)也要十分謹(jǐn)慎。
-
技術(shù)債務(wù)就像快餐一樣,偶爾欠下一點(diǎn)技術(shù)債務(wù)是可接受的,但如果你習(xí)慣了這樣,它會(huì)毀掉你的產(chǎn)品(而且是以讓你措手不及的方式)。
-
在尋找解決方案時(shí),請(qǐng)按照這樣的優(yōu)先級(jí)進(jìn)行決策:安全性 > 可用性(可訪問性和用戶體驗(yàn))> 可維護(hù)性 > 簡單性(開發(fā)者體驗(yàn))> 簡潔性(代碼量)> 性能。但不能盲目照搬,而是要根據(jù)產(chǎn)品的特點(diǎn)進(jìn)行取舍。你積累的經(jīng)驗(yàn)越多,就越是能夠在這些因素之間做出權(quán)衡。例如,在設(shè)計(jì)游戲引擎時(shí),性能享有最高的優(yōu)先級(jí),但在開發(fā)銀行應(yīng)用程序時(shí),安全性則最為重要。
-
拷貝粘貼是滋生 bug 的溫床。對(duì)你所拷貝或?qū)氲臇|西加以審查,bug 一般會(huì)藏身在復(fù)雜性中。依賴項(xiàng)復(fù)雜沒有關(guān)系,但不能讓它存在于代碼中。
-
不要只顧著寫正常的代碼,處理異常的代碼也要好好寫。讓人們明白為什么會(huì)發(fā)生異常、如何檢測到的以及怎樣解決。對(duì)所有的系統(tǒng)輸入(包括用戶輸入)進(jìn)行驗(yàn)證:盡早失敗,并盡可能從錯(cuò)誤中恢復(fù)。我們要假設(shè)用戶手里握著一把槍:你努力讓用戶輸入一些其他的東西,而不是讓他們的子彈射在你的腦門上。
-
不要使用依賴項(xiàng),除非使用它們的成本比你自己寫代碼的成本低很多。因?yàn)槭褂靡蕾図?xiàng)要導(dǎo)入、維護(hù)、處理 bug,在必要的時(shí)候還要進(jìn)行重構(gòu),這些都是成本。
-
遠(yuǎn)離“炒作驅(qū)動(dòng)開發(fā)”,但你要去了解它們,做一些嘗試。
-
走出舒適區(qū),每天都要學(xué)習(xí)。把學(xué)到的東西分享出來。如果你以大師自居,就不是在學(xué)習(xí)。接觸更多的編程語言、技術(shù)、文化,保持一顆好奇心。
-
好代碼不需要注釋,而優(yōu)秀的代碼提供了良好的注釋,可以讓任何一個(gè)原先沒有參與代碼演進(jìn)、試錯(cuò)和需求過程的人更容易閱讀、修改它。
-
盡量避免使用重載、繼承和隱式的智能特性。使用純函數(shù),它們更容易測試和診斷,否則的話就使用類。實(shí)現(xiàn)不同功能的函數(shù)要使用不同的名字。
-
在徹底了解問題之前不要急著寫代碼。花在傾聽和了解問題上的時(shí)間通常比花在寫代碼上的時(shí)間要多。在寫代碼之前要先了解問題域。問題就像迷宮一樣,你要循序漸進(jìn),反復(fù)進(jìn)行“編碼 - 測試 - 改進(jìn)”,直到把問題解決為止。
-
不要嘗試去解決不存在的問題。不要進(jìn)行投機(jī)性編程。只有在確定代碼確實(shí)需要具備擴(kuò)展性之后才讓代碼具備可擴(kuò)展性。通常情況下,當(dāng)代碼被擴(kuò)展之后,你會(huì)發(fā)現(xiàn)問題會(huì)變得與原先認(rèn)為的不一樣了。
-
大家一起開發(fā)軟件會(huì)更加有趣。建立可持續(xù)發(fā)展的社區(qū)。傾聽,激發(fā)靈感,學(xué)習(xí),分享。
我并不是軟件開發(fā)方面的權(quán)威,但這些都是我一路走來總結(jié)出來的原則。我相信,20 年后,這些原則會(huì)發(fā)生變化,會(huì)變得更加成熟。
總結(jié)
以上是生活随笔為你收集整理的20 年老程序员告诉你的 20 条编码原则的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 怀疑开发者在“造核弹”?GitHub 不
- 下一篇: 关于贫血,你了解多少?