程序員，盤一盤煉成高效能開發者的 14 個習慣！

「如果你想在重要的事情上取得卓越的成就，那麼就需要在小事情上培養良好的習慣。卓越不是一次例外，而是一種長期的態度。」——科林·鮑威爾（美國第一個黑人國務卿）

習慣的力量不容小覷，放之於開發人員亦如是。本文深入解析了可以永久改變開發者職業生涯的 14 種習慣，這些習慣將幫助你晉級成一名合格的高效能軟體開發人員。

作者 |Paul Isaris

譯者 | 彎月

責編 |仲培藝

出品 |CSDN（ID：CSDNNews）

以下為譯文：

許多人都認為從一位高效的初級開發人員晉級到中級開發只是時間和經驗的問題。但實際上，這兩者的分界線非常不明顯且很主觀，文本也不打算攪和進「究竟如何定義中級開發人員」這一無休止的辯論。

說實話，我堅定地認為真正可以改變一個人的心態並幫助他們從初級開發人員晉級到中級或高級開發人員的只有習慣：

習慣是你開始有計劃地做一件事情，直到你不再對它感到陌生，自然而然地形成的東西。

在專業和個人提升方面，形成與代碼相關以及與工作相關的習慣至關重要。

習慣造就了我們。習慣是我們自己養成的，所以我們有責任儘可能地培養好習慣。如果能培養良好的與工作或學習相關的習慣，我們就能有效地戰勝拖延症、倦怠、厭煩，以及偶爾的懈怠、衝動等阻礙我們的情況。

讓我們來看一看日常習慣的清單，一旦掌握這些習慣，就能幫助你提升到下一個水平並取得卓有成效的進步：

編寫 Small Methods

理想情況下，是都不要超過 20-30 行代碼。這種習慣非常重要，它不僅能迫使你編寫緊湊的代碼，而且在模塊化代碼時也有助於你的分析思考。擁有大量縮進（大量 if、for、loop 等語句）的 big methods 簡直就是一場噩夢。雖然編寫big methods看起來既簡單又省事，但是過不了多久你就很難搞清楚這段代碼究竟在做什麼了。

此外，big methods還有一個弊端，那就是無法重用。編寫這樣的代碼只是為了滿足項目中的某個需求，很難在其他地方使用。

有意義的命名

方法和變數的命名都應該有意義。中級開發人員無法接受名為「x」、「xyz」或者「object」等的變數名。用英語單詞命名變數的目的是為了賦予這些變數一定的意義。

與代碼之間的溝通遠比與文檔或注釋之間的溝通更為重要。

注釋的目的是解釋代碼的「目的」，而不是為了解釋「怎樣」編寫代碼。

有意義的變數可以幫助你與那些閱讀代碼的人更好地溝通，而且還可以減少書寫大量注釋的必要性，變數和 methods 都是如此。此外，如果methods名過長，則可以考慮重構代碼，簡化methods。一個乾淨利落的methods名總歸比一個混亂的名稱更方便使用。

在命名的時候，不要著急，先想一想你命名的組件是否太複雜，是否需要重構。

不要讓過多的參數毀了你的 Methods

凡是擁有太多參數的methods都面臨著重構的可能性。通常，編寫這種methods會違反單一功能原則（Single Responsibility Principle，簡稱SRP），這意味著methods中包含太多功能。一個高效簡潔的 methods只負責做好一個功能。正如 Robert C. Martin 所說，一個methods至多只能擁有 3 個參數。雖然並不一定要如此嚴格，但methods中所需參數的數量也確實和這個值差不多。

要抑制將一些 methods 的局部參數（local parameters）改成 class fields 的衝動。你應該考慮重構代碼，讓每個methods只負責很少的操作，或者乾脆分解成兩個單獨的methods。

「函數應該只有少量參數。最好一個參數也沒有，或者也可以有 1-3 個參數。超過 3 個參數就有問題了，應當極力避免。「——Robert C. Martin

避免在一個類中包含太多 Methods

與 methods 中的參數一樣，類中的 methods 數量也很重要。擁有許多methods的大類通常表示一個組件擁有太多內容或包含太多功能。我們將這些組件稱為上帝類（God Classes），這個詞是高耦合代碼的反面教材。

如果一個類中擁有許多 methods，那麼可以想一下，以後寫代碼時你可能需要經常打開該類並修改其行為。這可能違反了開放封閉原則（Open Closed Principle，簡稱 OCP），即「軟體實體（類、模塊、功能等）應該易於擴展，但盡量避免修改。」

使用第三方庫時，應該使用長期支持和穩定的版本

請時刻為下一個需要使用你的代碼並重新編譯項目的人考慮。使用長期支持版本的庫、插件和框架，雖然可能無法提供最新的酷炫功能，但是在將來如果需要重構或重新編譯代碼時，你就能體會到其中的好處了。

按下使用最新最好版本的工具的衝動，堅持使用最安全、最穩定的工具。將來有一天，你和你的同事都會感激這一選擇！

學習掌握最常見的設計模式

其實，大多數大項目都會用到一個或多個設計模式。設計模式會定義組件的功能描述、組件之間的關係以及抽象級別。你不需要了解或掌握所有的這些設計，但是知道基本的部分不僅對思考和設計有益，而且也有助於你在代碼庫中對其加以識別。

如果能夠在代碼庫中識別這一設計模式，那麼你就知道從哪裡能找到特定的類和對象，當然也可以擴展這些代碼，或添加更多功能。

如果設計模式能得以良好地實現，那麼項目中的每個人都能在設計上達成共識，並通過代碼更有效地進行溝通。

始終為下一個人考慮

無論是你自己還是其他同事，新員工還是其他公司的開發人員，總會有人負責擴展你的代碼或添加更多功能。這一點很難掌握，因為大多數初級開發人員都習慣了大學時期自己做項目，所有代碼都是一個人寫，並沒有其他人的參與。

然而，專業環境中的情況會有所不同。你要改動的項目代碼是好多年前編寫的，而且你的代碼也必須為幾年後出現的「下一個人」做好準備。所以，如果你準備編寫一個臨時的「hack」來實現某個功能，或者你在構建過程中添加一些東西卻沒有記錄下來，又或者你省略了重構，那麼你的這些行為都是在增加技術負債，將來必須有人來處理代償。

每隔幾個小時就停下來檢查一下你的工作。在 README 文件添加所需的記錄，刪除你臨時添加到項目中，實際上並不會使用的代碼和文件。如果你無法確定某個架構或編程決策，那麼請與其他更有經驗的同事交流。這不僅會改善你編寫的代碼，而且還有助於你將來更好地處理此類情況，另外還可以習慣自尊受到傷害這一真實體驗（當你不再是新手時，這種情況會不斷發生）。

習慣於自尊受到傷害

開發人員是一種奇怪的「物種」——我們談論只有我們能理解的事物，而且談論的方式也讓別人十分費解。在某些情況下，我們的工作會讓客戶或產品/項目經理感到不快，但這也在情理之中。某個功能可能沒有正確實現，或者可能因為模糊不清的項目需求而爭辯，這時我們的自尊會受到傷害：

這絕對不是我的錯！我怎麼能犯這樣的錯誤？他們是白痴嗎？他們恨我嗎？為什麼他們不理解重新實現一個功能有多艱難？

所有這些都是軟體工程師普遍的想法，但是這些想法會帶來不良的影響，讓我們無法接受問題並堅持維護自己的自尊。很關鍵的一點是我們需要明白沒有人針對你或你的程序。如果你們之間存在誤會，那麼就去解釋清楚。如果出現了 bug，那麼就記錄下來，然後修復並測試。這才是務實專業的軟體工程師該做的事情，大可不必覺得自尊受損。

你的工作不僅是成為優秀的分析師、程序員和技術人員，還要成為一名出色的專業人士。出色的軟技能可以在你的技術實力碰壁的時候幫助你。

勇於承擔代碼清理工作

有一條著名的童子軍規則：離開時請確保宿營地比你剛到時更加整潔。這實際上適用於我們日常生活的方方面面，軟體開發也不例外。很多時候，我們需要擴展代碼庫的功能並添加新功能。我們設置好開發環境，從版本控制中提取代碼並開始項目，卻只看到一堆 TODO、未使用的 methods 和變數、硬編碼的數字和字元串值以及未使用的依賴項。

既然我們已經參與了這個項目，所以這時我們應該坐下來考慮是否應該做一點清理工作。但是，另一方面，我們不確定我們的改動是否會破壞其他功能。如果我們重命名了代碼其他部分所使用的一個 method（或者是其他項目中的依賴項），該怎麼辦？確定項目所需的重構級別並不容易，然而單元測試和集成測試可以幫助我們找到代碼中遭到破壞的地方，methods 的作用域亦是如此。我們在更改公共方法之前，必須確認我們是否需要相應地修改調用者（調用該方法的代碼）。受保護的 methods 應該比較容易修改，我們只需要檢查子類的顯式實現。通常 Private methods（私有方法）的改動最簡單，因為它們的作用域被限制在自己的範圍內。

除了 methods 的重命名和重構之外，一個負責任的開發人員還有其他工作需要做，例如刪除已被注釋或未使用的代碼，或未使用的文件。大多數專業 IDE 都有工具可以讓你檢查是否有其他地方使用了某個方法。不要害怕刪除被注釋掉或過時的代碼。這些代碼只會增加項目的技術債務，而且我們還可以通過版本控制系統重新獲取某個時間點的舊代碼。

不要害怕參與編程之外的事情

軟體工程師的本職工作是寫代碼。無論是分析用戶故事（User Story），寫需求還是繪製資料庫的概要圖，我們的最終目標都是編寫良好強大的代碼，有效地完成工作。然而，完成非技術性的任務並深入研究軟技能的神奇世界也同樣至關重要。與經理、測試人員和客戶的溝通似乎是一項艱巨又麻煩的工作，但它也具有很大的價值。

培養你的軟技能，更好地溝通和管理，一定會讓你成為一個更出色的專業人士。因為你能夠更好地傳達用戶故事，甚至不使用嚴格的技術語言（免得他們把我們當作外星人）也能解釋清楚技術細節。

此外，能夠與管理人員和客戶進行更好的溝通還有助於你提高分析新的用戶故事或估算完成新功能所需時間的效率。你可以提出更好的問題，所以能夠更好地掌握客戶的需求。

不幸的是，有些人認為軟技能並不重要。然而，幾乎所有與我交談過這個問題的老闆都不這樣認為。我們的工作職責變化非常迅速，而軟技能是為數不多的幾個可以長期使用的技能之一。

記錄一切

不論是添加/刪除插件和第三方庫，還是在代碼中做假設，或者是在設置或構建過程中添加額外的步驟，甚至是使用特定版本的命令行工具時，如果沒有正確的記錄，那麼你將面臨巨大的痛苦。這個規則與第 7 條「始終為下一個人考慮」的規則緊密相關。你應該確保你不是唯一能夠為開發設置項目或運行生產構建的開發人員。

實際上針對這一點有一個非常簡單的規則：在完成項目處理後，將代碼存儲庫克隆到另一台計算機上，並嘗試按照說明文檔進行設置。這個過程中肯定能發現缺少的說明部分，確保你能夠構建健壯又專業的文檔。

放鬆和健身的時間

對普通的開發人員來說，8 小時的睡眠和每日健身難能可貴。我們更加喜歡下班後休息、刷電視劇和玩電子遊戲。健康的飲食和避免垃圾食品對我們來說更是難上加難。然而，健康的飲食和長期的鍛煉確實會對你的工作情緒和表現產生巨大影響。

運動可以增加大腦的血液流量，這有助於提高你的意識，讓你更好地應對下一個大項目。保持最佳的身體健康狀況有助於提高你整體的工作表現能力。鍛煉不僅可以幫助你減輕體重，預防某些疾病，而且還可以改善心血管健康，讓你的日常工作更加充滿活力。

在運動時，你的大腦會釋放血清素，幫助你保持愉悅的心情，改善你的心態，減輕你的工作壓力。血清素是大腦中的神經遞質，可以向身體發送刺激心情和情緒的信息。

除了鍛煉，晚上睡個好覺可以為第二天帶來好心情。繁重的工作，不規律的工作時間，學校和養育孩子的責任會奪走我們的睡眠。所有這些看似正常，卻越來越耗時的現實往往會剝奪我們健康的睡眠時間和內心的平靜，從而影響到我們在工作中的良好記憶和整體表現。

容光煥發（而不像少年時期那樣通宵玩電子遊戲後一臉憔悴）地出現在會議上，一定會讓你更好地工作，而且還能給同事和客戶留下好印象。

學會不要摻雜私人感情

這一條與第 8 條「習慣於自尊受到傷害」緊密相關。但前面那條更重要的是學習如何讓你在感覺自尊受到傷害時坦然處之；當下這條規則是關於學習如何成為一名高效的專業人士，並避免在工作中摻雜私人感情。

雖然你很難接受，但是不斷抱怨產品中錯誤的客戶並是不討厭你。雖然你的同事在審查你的代碼時發現了一些設計缺陷和一些需要改進的技術負債問題，但這並不意味著他們認為你是一個壞人，也並非他們討厭你或想打擊你。學會接受別人的意見（即使你並不認同），並做好工作和項目。

當然，這並不意味著你應該貶低自己的性格或接受每個人向你提出的建議，毫無疑問，你享有爭辯的權利，但請時刻牢記要讓你的爭辯富有成效。你是為了爭辯而爭辯或者只是為了捍衛自己的自尊，還是說你真的提出了一些有助於改善狀況的建議並取得雙贏的局面？

提出富有成效的建議

初級與高級開發人員之間的巨大差距在於，後者擁有提供良好建議和實施有益的代碼審查的能力。當別人徵求你的意見，或你實施代碼審查時，請避免從你的角度考慮問題，你應該注重大局和「共同的利益」。

優秀的軟體工程師應該像優秀的超級英雄一樣，在提供建議時應該採用直接且誠實的方式（當然不能粗魯）。你看到了需要重構的代碼？不要害怕大膽地說出來。如果別人徵詢你的專業意見，那就大方地說出你的專業意見。

這一點最關鍵的部分在於，每當你想提出建議或指出某個缺陷或錯誤時，在內心默默地問自己：「我是否可以提出更好的建議？」沒有建設性的建議並不比投訴強。請確保你的提議可以為當前富有成效的對話錦上添花，並時刻牢記注重大局。

作為一名高級軟體工程師，你不僅需要關心自己的發展，還需要關心他人的進步。避免不斷給自己建議和為他人提供富有成效的指導方針。這種做法會讓你受益匪淺，因為你需要負責整個專業團隊的成長。

總結

從初級開發人員晉級到中級開發人員無法一蹴而就。作為一名專業開發人員，職務提升和編程技術升級是一個培養良好習慣的問題。培養良好的個人習慣和職業習慣可以加速一個人成為有效的專業人士。我們需要長時間的不懈努力。你需要做的是儘可能地將這些習慣應用到你的日常生活中，開始逐步向真正的專業人士過渡！

原文：https://paulisaris.com/the-14-habits-of-highly-effective-developers-part-1/

https://paulisaris.com/the-14-habits-of-highly-effective-developers-part-2/

作者：Paul Isaris，全棧軟體工程師。

本文為 CSDN 翻譯，如需轉載，請註明來源出處。

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！