工程師分享的7個(gè)編程習(xí)慣

我和很多杰出的軟件工程師們一起工作過，他們有的來自FAANG之類的大公司，有的來自正處于創(chuàng)業(yè)階段的小公司。

這些工程師中有人自主創(chuàng)業(yè)，也有人在大型科技公司領(lǐng)導(dǎo)了數(shù)十億美元的項(xiàng)目。在我與他們一起工作的時(shí)間里，我注意到他們絕大部分人的一些共通的編程和工作習(xí)慣。我想，或許正是這些習(xí)慣讓他們成為了行業(yè)金字塔中最頂尖的那1%。

成為一名工程師，而不是碼農(nóng)

工程是為了解決問題而誕生的。

最好的工程師將代碼視為達(dá)到目的的手段。

雖然寫代碼是一種樂趣，但沒有目的地寫代碼是沒有意義的。代碼應(yīng)該用于為用戶設(shè)計(jì)解決方案。

某種意義上，編程是一種創(chuàng)造性的追求。創(chuàng)造力在約束下茁壯成長。添加要解決的明確問題的“約束”，允許工程師以他們認(rèn)為合適的方式自由地探索和創(chuàng)建解決方案。

我所知道的最好的工程師都是有產(chǎn)品意識的：首先考慮為人類解決問題。說到這里，就引出了下一點(diǎn)。

為人而不是為機(jī)器編寫代碼

“任何傻瓜都可以編寫計(jì)算機(jī)可以理解的代碼。優(yōu)秀的程序員編寫人類可以理解的代碼?！?/p>

代碼是為人類編寫的，而不僅僅是為計(jì)算機(jī)編寫的。

代碼是為團(tuán)隊(duì)中的工程師準(zhǔn)備的，他們會閱讀、維護(hù)并在代碼的基礎(chǔ)上進(jìn)行構(gòu)建。

代碼是為用戶準(zhǔn)備的，不管是用手機(jī)的孩子，還是調(diào)用API的開發(fā)者，或者是你自己。

我認(rèn)識的最好的工程師總是為所有受眾評估他們代碼的價(jià)值。

如果他們沒有打動某個(gè)受眾，則該代碼就不會投入生產(chǎn)。

與代碼本身分離

優(yōu)秀的工程師不依附于代碼本身。

即使他們已經(jīng)完成了90%，如果改變意味著最終的結(jié)果會更好，那么他們不害怕刪除代碼并重新開始。

代碼不是個(gè)人的，所以反饋是從容的。

代碼并不完美。沒有人關(guān)心完美的代碼。他們關(guān)心的是帶來變化的代碼。

教會自己不依附于代碼的最好方法是認(rèn)識到，在20年內(nèi)，你的大部分代碼很有可能成為技術(shù)債務(wù)、被棄用或被重寫。

使用一致的標(biāo)準(zhǔn)

編寫代碼時(shí)，請堅(jiān)持一致的編碼標(biāo)準(zhǔn)和風(fēng)格。一致性使代碼更容易被未來的你和你的團(tuán)隊(duì)成員閱讀和理解。

一致的風(fēng)格指南可以讓團(tuán)隊(duì)和代碼庫更容易擴(kuò)展。這就是為什么Meta和Google這樣的公司能夠快速發(fā)布如此多的代碼，而不會隨著時(shí)間的推移使代碼庫變得不可讀和不可維護(hù)。

我認(rèn)識的每一個(gè)優(yōu)秀的人都內(nèi)化了團(tuán)隊(duì)的代碼標(biāo)準(zhǔn)，并盡可能嚴(yán)格地遵循它，洞悉它的好處。

寫簡單干凈的代碼

我認(rèn)識的每一位精英工程師都編寫了一些代碼，這些代碼編寫起來可能很復(fù)雜，但最終閱讀和理解起來都很簡單。我能想到的最好的詞就是他們的代碼很美觀。

他們的代碼干凈、有條理、合乎邏輯。在他們的代碼中做出的每個(gè)決定都是有意義的，當(dāng)有些事情沒有意義時(shí)，它會在代碼中被很好地記錄下來。

編寫干凈代碼的一個(gè)好方法是遵循原則，比如SOLID原則。雖然它們最初是用面向?qū)ο缶幊?OOP)設(shè)計(jì)的，但它們可以擴(kuò)展到通用編程：

單一責(zé)任：一個(gè)類只能有一個(gè)責(zé)任。

open-closed：軟件對象（類、模塊等）應(yīng)該開放擴(kuò)展，但關(guān)閉修改，允許可預(yù)測、可維護(hù)的代碼。

Liskov 替換：子類型必須可替換其基本類型，而不會影響程序的正確性。

接口隔離：代碼不應(yīng)該依賴于沒有使用全部接口的大型接口。相反，包應(yīng)該包含并允許更小的、特定的接口被導(dǎo)入。

依賴反轉(zhuǎn)：高級模塊不應(yīng)依賴于低級模塊;兩者都應(yīng)依賴于抽象，從而促進(jìn)更靈活和解耦的系統(tǒng)設(shè)計(jì)。

這方面的一個(gè)例子是命名。好的命名沒有神奇的值、明確的區(qū)別、描述性的函數(shù)名稱和可理解的變量。

不要讓意外發(fā)生

代碼不應(yīng)該產(chǎn)生意外。這是通過遵循代碼原則和編寫適當(dāng)?shù)臏y試來實(shí)現(xiàn)的。

好的代碼是可預(yù)測的。

測試強(qiáng)制代碼清晰和可預(yù)測性。他們提供信心。良好的自動化測試允許團(tuán)隊(duì)對代碼進(jìn)行更改，而不必?fù)?dān)心會破壞一些看不見的東西。

一些類型的測試包括:

單個(gè)組件和獨(dú)立功能的單元測試。

用于多個(gè)組件之間交互的集成測試。

端到端測試，從用戶的角度評估整個(gè)系統(tǒng)的功能

測試應(yīng)該很簡單。在閱讀失敗的測試時(shí)，應(yīng)該很容易識別出哪里出了問題。

知道什么不應(yīng)該測試也很重要。

例如，如果端到端測試的工作量超過了程序的實(shí)際收益，那么測試將被周全的文檔、監(jiān)視和向正確的人(例如代碼所有者)發(fā)出警報(bào)所取代。

測試也不應(yīng)該測試代碼中的實(shí)現(xiàn)細(xì)節(jié)，比如測試前端代碼中的某些CSS選擇器，而不是使用數(shù)據(jù)屬性或只是屏幕截圖測試。

經(jīng)常溝通

偉大的系統(tǒng)不是單獨(dú)建立起來的。優(yōu)秀的工程師會進(jìn)行設(shè)計(jì)審查，征求反饋，并繼續(xù)對他們的初始設(shè)計(jì)進(jìn)行迭代。

每個(gè)人都有知識盲區(qū)，可以由其他人來填補(bǔ)。新的視角通常可以幫助代碼變得更清晰，或者提供以前可能沒有想到的新方法。

最好的工程師既善于溝通又善于合作——為了更好的最終結(jié)果，他們不怕花時(shí)間一起工作。

這可以很簡單，比如讓團(tuán)隊(duì)成員快速檢查文檔，或者為重要的拉取請求添加額外的代碼檢查人員。

慢，即是快

我所知道的最好的工程師通過慢編碼來快速完成項(xiàng)目。聽起來很奇怪，對吧?

其實(shí)，上述所有這些原則和習(xí)慣都增加了首次編碼的時(shí)間。但它們允許工程師一步一步地推進(jìn)項(xiàng)目的進(jìn)展。

通過花時(shí)間使用標(biāo)準(zhǔn)、適當(dāng)?shù)販y試、使用原則和經(jīng)常溝通，從長遠(yuǎn)來看，他們可以節(jié)省更多的時(shí)間。

當(dāng)我還是一名實(shí)習(xí)生和初級工程師時(shí)，我親身經(jīng)歷過另一種選擇，我相信很多人也有過這種經(jīng)歷，那就是向前沖3步，撞到一個(gè)障礙物，然后不得不后退5步。

不要盲目循規(guī)蹈矩

以上的“規(guī)則”和“原則”只是指導(dǎo)方針。并不是所有的東西都能很好地符合指導(dǎo)方針。

有時(shí)候，你寫的代碼是一個(gè)正方形，不能放進(jìn)那個(gè)圓圈里。沒關(guān)系。

在這種情況下，請確保記錄代碼以某種方式編寫的原因。

如果你不這樣做，那么有人，比如未來的你，可能會在未來看到當(dāng)時(shí)的代碼時(shí)覺得“哇，我當(dāng)時(shí)真笨。為什么不符合我們的標(biāo)準(zhǔn)呢?”

然后，他們會花20個(gè)小時(shí)重新編碼，以符合標(biāo)準(zhǔn)，只是為了得到和以前相同的結(jié)論。聽起來是不是很熟悉?

軟件開發(fā)的現(xiàn)實(shí)是，并不是所有的代碼都是干凈的或完全遵循規(guī)則的。

但是，它可以是一致的、干凈的、可理解的、可測試的和有價(jià)值的。

寫在最后

此外，我還注意到：這些工程師的行為模式還包括：

至少在一個(gè)領(lǐng)域有深厚的領(lǐng)域知識。我所記錄的每一位工程師如今都是各自領(lǐng)域的頂尖人物，因?yàn)樗麄儗Ｗ⒂谀骋活I(lǐng)域，并成為了該領(lǐng)域的專家，無論是前端基礎(chǔ)設(shè)施、分布式系統(tǒng)還是簡潔的UI。

經(jīng)常適當(dāng)?shù)赝其N自己。這些工程師并沒有藏匿于幕后。他們團(tuán)隊(duì)中的每個(gè)人以及與他們一起工作的每個(gè)人都知道他們的價(jià)值和專長。這是通過適當(dāng)?shù)貭I銷自己和從事高影響力項(xiàng)目的結(jié)合而實(shí)現(xiàn)的。

編輯：黃飛