點選「 IT碼徒 」， 關註，置頂 公眾號
每日技術幹貨，第一時間送達！
我和很多傑出的軟體工程師們一起工作過，他們有的來自FAANG之類的大公司，有的來自正處於創業階段的小公司。
這些工程師中有人自主創業，也有人在大型科技公司領導了數十億美元的計畫。在我與他們一起工作的時間裏，我註意到他們絕大部份人的一些共通的編程和工作習慣。我想，或許正是這些習慣讓他們成為了行業金字塔中最頂尖的那1%。
1
成為一名工程師，而不是碼農
工程是為了解決問題而誕生的。
最好的工程師將程式碼視為達到目的的手段。
雖然寫程式碼是一種樂趣，但沒有目的地寫程式碼是沒有意義的。程式碼應該用於為使用者設計解決方案。
某種意義上，編程是一種創造性的追求。創造力在約束下茁壯成長。添加要解決的明確問題的「約束」，允許工程師以他們認為合適的方式自由地探索和建立解決方案。
我所知道的最好的工程師都是有產品意識的：首先考慮為人類解決問題。說到這裏，就引出了下一點。
2
為人而不是為機器編寫程式碼
「任何傻瓜都可以編寫電腦可以理解的程式碼。優秀的程式設計師編寫人類可以理解的程式碼。」
程式碼是為人類編寫的，而不僅僅是為電腦編寫的。
程式碼是為團隊中的工程師準備的，他們會閱讀、維護並在程式碼的基礎上進行構建。
程式碼是為使用者準備的，不管是用手機的孩子，還是呼叫API的開發者，或者是你自己。
我認識的最好的工程師總是為所有受眾評估他們程式碼的價值。
如果他們沒有打動某個受眾，則該程式碼就不會投入生產。
3
與程式碼本身分離
優秀的工程師不依附於程式碼本身。
即使他們已經完成了90%，如果改變意味著最終的結果會更好，那麽他們不害怕刪除程式碼並重新開始。
程式碼不是個人的，所以反饋是從容的。
程式碼並不完美。沒有人關心完美的程式碼。他們關心的是帶來變化的程式碼。
教會自己不依附於程式碼的最好方法是認識到，在20年內，你的大部份程式碼很有可能成為技術債務、被棄用或被重寫。
4
使用一致的標準
編寫程式碼時，請堅持一致的編碼標準和風格。一致性使程式碼更容易被未來的你和你的團隊成員閱讀和理解。
一致的風格指南可以讓團隊和程式碼庫更容易擴充套件。這就是為什麽Meta和Google這樣的公司能夠快速釋出如此多的程式碼，而不會隨著時間的推移使程式碼庫變得不可讀和不可維護。
我認識的每一個優秀的人都內化了團隊的程式碼標準，並盡可能嚴格地遵循它，洞悉它的好處。
5
寫簡單幹凈的程式碼
我認識的每一位精英工程師都編寫了一些程式碼，這些程式碼編寫起來可能很復雜，但最終閱讀和理解起來都很簡單。我能想到的最好的詞就是他們的程式碼很美觀。
他們的程式碼幹凈、有條理、合乎邏輯。在他們的程式碼中做出的每個決定都是有意義的，當有些事情沒有意義時，它會在程式碼中被很好地記錄下來。
編寫幹凈程式碼的一個好方法是遵循原則，比如SOLID原則。雖然它們最初是用物件導向編程(OOP)設計的，但它們可以擴充套件到通用編程：
單一責任：一個類只能有一個責任。
open-closed：軟體物件（類、模組等）應該開放擴充套件，但關閉修改，允授權預測、可維護的程式碼。
Liskov 替換：子類別型必須可替換其基本型別，而不會影響程式的正確性。
介面隔離：程式碼不應該依賴於沒有使用全部介面的大型介面。相反，包應該包含並允許更小的、特定的介面被匯入。
依賴反轉：高級模組不應依賴於低階模組;兩者都應依賴於抽象，從而促進更靈活和解耦的系統設計。
這方面的一個例子是命名。好的命名沒有神奇的值、明確的區別、描述性的函式名稱和可理解的變量。
6
不要讓意外發生
程式碼不應該產生意外。這是透過遵循程式碼原則和編寫適當的測試來實作的。
好的程式碼是可預測的。
測試強制程式碼清晰和可預測性。他們提供信心。良好的自動化測試允許團隊對程式碼進行更改，而不必擔心會破壞一些看不見的東西。
一些型別的測試包括:
單個元件和獨立功能的單元測試。
用於多個元件之間互動的整合測試。
端到端測試，從使用者的角度評估整個系統的功能
測試應該很簡單。在閱讀失敗的測試時，應該很容易辨識出哪裏出了問題。
知道什麽不應該測試也很重要。
例如，如果端到端測試的工作量超過了程式的實際收益，那麽測試將被周全的文件、監視和向正確的人(例如程式碼所有者)發出警報所取代。
測試也不應該測試程式碼中的實作細節，比如測試前端程式碼中的某些CSS選擇器，而不是使用數據內容或只是螢幕截圖測試。
7
經常溝通
偉大的系統不是單獨建立起來的。優秀的工程師會進行設計審查，征求反饋，並繼續對他們的初始設計進行叠代。
每個人都有知識盲區，可以由其他人來填補。新的視角通常可以幫助程式碼變得更清晰，或者提供以前可能沒有想到的新方法。
最好的工程師既善於溝通又善於合作——為了更好的最終結果，他們不怕花時間一起工作。
這可以很簡單，比如讓團隊成員快速檢查文件，或者為重要的拉取請求添加額外的程式碼檢查人員。
8
慢，即是快
我所知道的最好的工程師透過慢編碼來快速完成計畫。聽起來很奇怪，對吧?
其實，上述所有這些原則和習慣都增加了首次編碼的時間。但它們允許工程師一步一步地推進計畫的進展。
透過花時間使用標準、適當地測試、使用原則和經常溝通，從長遠來看，他們可以節省更多的時間。
當我還是一名實習生和初級工程師時，我親身經歷過另一種選擇，我相信很多人也有過這種經歷，那就是向前沖3步，撞到一個障礙物，然後不得不後退5步。
9
不要盲目循規蹈矩
以上的「規則」和「原則」只是指導方針。並不是所有的東西都能很好地符合指導方針。
有時候，你寫的程式碼是一個正方形，不能放進那個圓圈裏。沒關系。
在這種情況下，請確保記錄程式碼以某種方式編寫的原因。
如果你不這樣做，那麽有人，比如未來的你，可能會在未來看到當時的程式碼時覺得「哇，我當時真笨。為什麽不符合我們的標準呢?」
然後，他們會花20個小時重新編碼，以符合標準，只是為了得到和以前相同的結論。聽起來是不是很熟悉?
軟體開發的現實是，並不是所有的程式碼都是幹凈的或完全遵循規則的。
但是，它可以是一致的、幹凈的、可理解的、可測試的和有價值的。
10
寫在最後
此外，我還註意到：這些工程師的行為模式還包括：
至少在一個領域有深厚的領域知識。我所記錄的每一位工程師如今都是各自領域的頂尖人物，因為他們專註於某一領域，並成為了該領域的專家，無論是前端基礎設施、分布式系統還是簡潔的UI。
經常適當地推銷自己。這些工程師並沒有藏匿於幕後。他們團隊中的每個人以及與他們一起工作的每個人都知道他們的價值和專長。這是透過適當地行銷自己和從事高影響力計畫的結合而實作的。
參考連結：https://engineercodex.substack.com/p/7-simple-habits-of-the-top-1-of-engineers
— END —
PS：防止找不到本篇文章，可以收藏點贊，方便翻閱尋找哦。
往期推薦
