讓你遙遙領(lǐng)先的七個編程習(xí)慣
發(fā)布時間:2023-10-07 15:34:35
1、成為一名工程師,而不是碼農(nóng)
工程是為了解決問題而誕生的。
最好的工程師將代碼視為達到目的的手段。
雖然寫代碼是一種樂趣,但沒有目的地寫代碼是沒有意義的。代碼應(yīng)該用于為用戶設(shè)計解決方案。
某種意義上,編程是一種創(chuàng)造性的追求。創(chuàng)造力在約束下茁壯成長。添加要解決的明確問題的“約束”,允許工程師以他們認為合適的方式自由地探索和創(chuàng)建解決方案。
我所知道的最好的工程師都是有產(chǎn)品意識的:首先考慮為人類解決問題。說到這里,就引出了下一點。
2、為人而不是為機器編寫代碼
“任何傻瓜都可以編寫計算機可以理解的代碼。優(yōu)秀的程序員編寫人類可以理解的代碼?!?/p>
代碼是為人類編寫的,而不僅僅是為計算機編寫的。
代碼是為團隊中的工程師準(zhǔn)備的,他們會閱讀、維護并在代碼的基礎(chǔ)上進行構(gòu)建。
代碼是為用戶準(zhǔn)備的,不管是用手機的孩子,還是調(diào)用 API 的開發(fā)者,或者是你自己。
我認識的最好的工程師總是為所有受眾評估他們代碼的價值。
如果他們沒有打動某個受眾,則該代碼就不會投入生產(chǎn)。
3、與代碼本身分離
優(yōu)秀的工程師不依附于代碼本身。
即使他們已經(jīng)完成了 90%,如果改變意味著最終的結(jié)果會更好,那么他們不害怕刪除代碼并重新開始。
代碼不是個人的,所以反饋是從容的。
代碼并不完美。沒有人關(guān)心完美的代碼。他們關(guān)心的是帶來變化的代碼。
教會自己不依附于代碼的最好方法是認識到,在 20 年內(nèi),你的大部分代碼很有可能成為技術(shù)債務(wù)、被棄用或被重寫。
4、使用一致的標(biāo)準(zhǔn)
編寫代碼時,請堅持一致的編碼標(biāo)準(zhǔn)和風(fēng)格。一致性使代碼更容易被未來的你和你的團隊成員閱讀和理解。
一致的風(fēng)格指南可以讓團隊和代碼庫更容易擴展。這就是為什么 Meta 和 Google 這樣的公司能夠快速發(fā)布如此多的代碼,而不會隨著時間的推移使代碼庫變得不可讀和不可維護。
我認識的每一個優(yōu)秀的人都內(nèi)化了團隊的代碼標(biāo)準(zhǔn),并盡可能嚴格地遵循它,洞悉它的好處。
5、寫簡單干凈的代碼
我認識的每一位精英工程師都編寫了一些代碼,這些代碼編寫起來可能很復(fù)雜,但最終閱讀和理解起來都很簡單。我能想到的最好的詞就是他們的代碼很美觀。
他們的代碼干凈、有條理、合乎邏輯。在他們的代碼中做出的每個決定都是有意義的,當(dāng)有些事情沒有意義時,它會在代碼中被很好地記錄下來。
編寫干凈代碼的一個好方法是遵循原則,比如 SOLID 原則。雖然它們最初是用面向?qū)ο缶幊?OOP)設(shè)計的,但它們可以擴展到通用編程:
單一責(zé)任:一個類只能有一個責(zé)任。
open-closed:軟件對象(類、模塊等)應(yīng)該開放擴展,但關(guān)閉修改,允許可預(yù)測、可維護的代碼。
Liskov 替換:子類型必須可替換其基本類型,而不會影響程序的正確性。
接口隔離:代碼不應(yīng)該依賴于沒有使用全部接口的大型接口。相反,包應(yīng)該包含并允許更小的、特定的接口被導(dǎo)入。
依賴反轉(zhuǎn):高級模塊不應(yīng)依賴于低級模塊;兩者都應(yīng)依賴于抽象,從而促進更靈活和解耦的系統(tǒng)設(shè)計。
這方面的一個例子是命名。好的命名沒有神奇的值、明確的區(qū)別、描述性的函數(shù)名稱和可理解的變量。
6、不要讓意外發(fā)生
代碼不應(yīng)該產(chǎn)生意外。這是通過遵循代碼原則和編寫適當(dāng)?shù)臏y試來實現(xiàn)的。
好的代碼是可預(yù)測的。
測試強制代碼清晰和可預(yù)測性。他們提供信心。良好的自動化測試允許團隊對代碼進行更改,而不必擔(dān)心會破壞一些看不見的東西。
一些類型的測試包括:
單個組件和獨立功能的單元測試。
用于多個組件之間交互的集成測試。
端到端測試,從用戶的角度評估整個系統(tǒng)的功能
測試應(yīng)該很簡單。在閱讀失敗的測試時,應(yīng)該很容易識別出哪里出了問題。
知道什么不應(yīng)該測試也很重要。
例如,如果端到端測試的工作量超過了程序的實際收益,那么測試將被周全的文檔、監(jiān)視和向正確的人(例如代碼所有者)發(fā)出警報所取代。
測試也不應(yīng)該測試代碼中的實現(xiàn)細節(jié),比如測試前端代碼中的某些 CSS 選擇器,而不是使用數(shù)據(jù)屬性或只是屏幕截圖測試。
7、經(jīng)常溝通
偉大的系統(tǒng)不是單獨建立起來的。優(yōu)秀的工程師會進行設(shè)計審查,征求反饋,并繼續(xù)對他們的初始設(shè)計進行迭代。
每個人都有知識盲區(qū),可以由其他人來填補。新的視角通??梢詭椭a變得更清晰,或者提供以前可能沒有想到的新方法。
最好的工程師既善于溝通又善于合作——為了更好的最終結(jié)果,他們不怕花時間一起工作。
這可以很簡單,比如讓團隊成員快速檢查文檔,或者為重要的拉取請求添加額外的代碼檢查人員。
8、慢,即是快
我所知道的最好的工程師通過慢編碼來快速完成項目。聽起來很奇怪,對吧?
其實,上述所有這些原則和習(xí)慣都增加了首次編碼的時間。但它們允許工程師一步一步地推進項目的進展。
通過花時間使用標(biāo)準(zhǔn)、適當(dāng)?shù)販y試、使用原則和經(jīng)常溝通,從長遠來看,他們可以節(jié)省更多的時間。
當(dāng)我還是一名實習(xí)生和初級工程師時,我親身經(jīng)歷過另一種選擇,我相信很多人也有過這種經(jīng)歷,那就是向前沖 3 步,撞到一個障礙物,然后不得不后退 5 步。
9、不要盲目循規(guī)蹈矩
以上的“規(guī)則”和“原則”只是指導(dǎo)方針。并不是所有的東西都能很好地符合指導(dǎo)方針。
有時候,你寫的代碼是一個正方形,不能放進那個圓圈里。沒關(guān)系。
在這種情況下,請確保記錄代碼以某種方式編寫的原因。
如果你不這樣做,那么有人,比如未來的你,可能會在未來看到當(dāng)時的代碼時覺得“哇,我當(dāng)時真笨。為什么不符合我們的標(biāo)準(zhǔn)呢?”
然后,他們會花 20 個小時重新編碼,以符合標(biāo)準(zhǔn),只是為了得到和以前相同的結(jié)論。聽起來是不是很熟悉
軟件開發(fā)的現(xiàn)實是,并不是所有的代碼都是干凈的或完全遵循規(guī)則的。
但是,它可以是一致的、干凈的、可理解的、可測試的和有價值的。
10、保持新鮮力
太空電梯、MOSS、ChatGPT 等,都預(yù)兆著 2023 年注定不會是平凡的一年。任何新的技術(shù)都值得推敲,我們應(yīng)要有這種敏感性。
這幾年隱約碰過低代碼,目前比較熱門,很多大廠都相繼加入。
低代碼平臺概念:通過自動代碼生成和可視化編程,只需要少量代碼,即可快速搭建各種應(yīng)用。
到底啥是低代碼,在我看來就是拖拉拽,呼呼呼,一通操作,搞出一套能跑的系統(tǒng),前端,后端,數(shù)據(jù)庫,一把完成。當(dāng)然這可能是最終目標(biāo)。