程式設計師安身立命的138條忠告

讓我們面對現實，每個開發人員都希望個人的技術能力以及團隊協同能力可以隨著時間的推移不斷得到提高。但大多數開發者都會提出的一個重要且關鍵性的問題：如何才能做到這一點呢？接下來，本文作者以自身的開發經驗分享在程式設計時作為開發者應該牢記的 139 條忠告，以成為更好的程式設計師。

程式碼外觀

關於程式碼佈局的討論越多，越有可能陷入沒有結果的爭辯中。眾所周知的爭論有 TAB 鍵與空格縮排的爭論，以及大括號要不要另起一行的爭論等。

良好的程式碼格式不一定是你覺得最漂亮的那個。良好的格式是更易於瀏覽和閱讀的程式碼格式。

良好的程式碼外觀揭示了程式碼的意圖。這不是一項藝術工作。

我們需要通過良好的外觀避免出現程式碼錯誤。不是為了表現我們可以創造漂亮的 ASCII 藝術。

雖然我們寫的程式碼是通過計算機執行的，但卻要給人類閱讀。

如果有人想寫清晰的風格，那麼首先讓他弄清楚自己的想法。

選擇一種佈局樣式，然後堅持使用這種樣式，或採用編碼標準或樣式指南。

如果你正在處理的檔案不符合專案其餘部分的佈局約定，那麼請遵循該檔案中的佈局約定。

命名

良好的命名具有描述性、正確性和慣用性。

如果你非常瞭解命名物件，那麼你可以為它起一個好名字。在為變數提供神祕的名稱之前，請確保你明白它是什麼。

避免冗餘。冗餘表明你沒有充分考慮正在建立的東西的名字。無論是類，函式還是變數。

採用你使用的語言中最常用的大寫慣例。比如在C＃方法中，大寫的Console.WriteLine（“Hello World”）

確保明明準確無拼寫錯誤。

切勿同時修改外觀和行為。用不同的版本管理它們的更改。

隨著獲得的經驗調整程式碼外觀風格。新手並不能總是保持良好的程式碼外觀，你更應該關注程式的功能。

減少程式碼量

寫的程式碼多不一定意味著你寫了很多軟體。這可能只是意味著你寫了很多 Bug。

程式碼越多，意味著需要閱讀和理解的越多，這會讓程式更加難以理解。

程式碼量越大，隱藏 Bug 的地方就越多，追蹤 Bug 就會越難。

避免非必要的程式碼

常見的沒有意義的程式碼包括使用非必要性的條件語句和重複的邏輯構造。混亂的邏輯代表著混亂的思路。

程式碼保持明確簡潔。避免不必要的冗長語句。它們不會為程式碼帶來任何價值。

複製

不要複製程式碼段。將它們重構成通用的函式。通過參數列示差異性。

如果發現重複程式碼，請將其刪除。

無效程式碼

無效程式碼是指永遠不會執行，或永遠無法訪問的程式碼。

要麼給程式碼執行的機會，要麼乾脆刪掉。

無效程式碼的其他表現形式包括：

永遠不會給呼叫的函式；

定義的變數永遠沒有不會被使用；

傳遞給內部方法的引數永遠不會被使用；

從未使用過的列舉、結構、類或介面。

註釋

良好的程式碼不需要大量註釋的支援，也不需要解釋它的工作原理。

確保每個註釋都有新增的價值。程式碼本身就是工作原理以及方法的最好的說明。註釋應該解釋為什麼——只有程式碼本身不夠清楚的時候。

刪除程式碼時不要將其註釋掉。這會讓讀者感到困惑，而且很礙事。

每天都讓你的程式碼變得更好。如果找到冗餘和重複時，請將它們刪除。

通過刪除程式碼來改進系統

新增新程式碼可以改進系統。你也可以通過刪除程式碼來改進系統。

無效程式碼會在開發過程中積累

應用程式的使用者介面的功能已被刪除，但是後臺的支援程式碼依然保留了下來。

通過嚮導生成的使用者介面程式碼經常會插入一些永遠不會被使用的邏輯。

隨時隨地刪除無效程式碼。這些程式碼很礙事，會影響你的工作速度。

刪掉將來可能需要的程式碼也是安全的。屆時你可以從版本控制中恢復。

清理程式碼始終應該和功能改變分開提交。

即使最好的程式碼庫也有無效程式碼 。

警惕過去

在寫程式碼的時候，你覺得它是完美的，但是通過認真審視舊程式碼，你可以發現所有程式碼中的陷阱。

回顧舊程式碼可以幫助你提高程式設計技術。

如何處置現有的程式碼庫

接管現有的大型程式碼庫是一件很困難的事。你必須迅速開始：

瞭解從哪裡開始檢視程式碼

弄清楚程式碼每個部分的作用以及實現方法

衡量程式碼的質量

瞭解如何操控系統

瞭解程式碼的慣用語，這樣你的修改就可以完全融入

找到所有功能的可能位置（以及由此引起的後續bug）

瞭解程式碼的最佳方式是由知情人士為你講解。大膽地尋求幫助！

學習程式碼的最佳方法是修改程式碼。然後從你的錯誤中吸取教訓。

許多程式設計師不是努力閱讀和理解現有程式碼，而是更喜歡說“程式碼很糟糕”並重寫。

準備好遭遇很差的程式碼。準備好得力的工具來處理這些程式碼。

一些慘不忍睹的程式碼可能只是一個能力較弱的程式設計師編寫的。或者是一個有能力的程式設計師在心情糟糕的時候寫的。

遇到很糟糕的程式碼時，控制好自己的厭惡情緒。你需要尋找實際的方法改進這些程式碼。

不要指望任何程式碼（甚至是你自己的程式碼）完美。

遵循童子軍規則。無論何時遇到程式碼，確保你離開時的程式碼更好。

緩慢而謹慎地修改程式碼。一次只改動一個地方。

錯誤處理

不要忽視程式碼中可能出現的錯誤。不要一再推脫錯誤處理（逃避不是辦法）。

規規矩矩使用異常。瞭解語言的慣例和需求，有效地使用異常。

程式設計師必須瞭解程式錯誤。使用者必須瞭解使用錯誤。

記錄錯誤還不夠好，必須要讓勤奮的操作員每天注意到錯誤並處理好錯誤。

做好異常準備

每一步都要考慮所有可能發生的不尋常，無論你認為它們出現的機率有多低。

時時刻刻都要考慮從錯誤中恢復，並編寫合適的恢復程式碼。

確保你的錯誤處理是慣用手法，並使用適當的語言機制。

在寫程式碼的時候，嚴密考慮程式碼的執行分支。不要推遲處理“不尋常”的情況：轉頭你就忘了，導致程式碼到處是 Bug。

追蹤 Bug

程式設計師寫程式碼。但程式設計師不是完美的，所以程式設計師的程式碼也不是完美的。因此程式碼第一次不能正常工作也很正常。所以我們有 Bug。

我們應該採用合理的工程技術，量減少令人不快的意外事故。

首先除錯的難度是寫程式碼的兩倍。因此，如果你儘可能巧妙地編寫程式碼，那麼顯然這對於除錯是不明智的。

將重現 Bug 的步驟降到最少。

確保你只專注於一個問題。

斷言和日誌（即便是簡陋的 console.log 和 nodejs 斷言）是有效的除錯工具。可以經常利用。

二進位制刪除空格的問題可以更快地獲得結果。

在開發軟體時，花點時間寫一套單元測試。

未經測試的程式碼是 Bug 的溫床。而測試是殺蟲劑。

瞭解如何使用偵錯程式。然後在正確的時間內使用。

儘快修復 Bug。不要讓它們累積成災。

除錯並不容易。這是我們的錯。我們寫了 Bug。

別忘了測試程式碼

單元測試是專門針對最小“單元”的功能展開的測試，以確保它們可以獨立正常執行。這裡的獨立意味著單元測試不涉及任何外部訪問：不執行任何資料庫、網路或檔案系統操作。

質量是免費的，但只有那些願意為此付出高昂代價的人才能享有。

為了改進軟體開發，我們需要快速反饋，以便在出現問題時立即掌握問題。良好的測試策略可以提供快速的反饋迴路。

在編寫程式碼時編寫測試。不要推遲測試，否則測試就不會那麼有效了。

所有測試都應作為持續整合工具鏈的一部分在構建伺服器上執行。

測試應用程式中的重要內容。

全域性變數和單例物件是可靠測試的噩夢。你無法輕易測試擁有隱藏依賴項的單元。

重構程式碼，提高可測試性，以便獲得更好的程式碼設計。

程式測試可以展示 Bug 的存在，但永遠無法證明沒有 Bug。

如何處理複雜性

簡單性是偉大的品質，但需要付諸福利才能實現，人人都應該重視簡單性。但糟糕的是：大家更喜歡複雜性。

複雜性通常是偶然的，很少有人會故意新增。

推遲設計決策，直到你必須做決定的時候。在還不瞭解需求時，不要做出架構決策。不要猜。

完美的實踐

程式設計師需要良好的品味和美感才能編寫出色的程式碼。

任何聰明的傻瓜都會讓程式碼變得更大、更復雜和濫用。我們需要一點天才的力量以及很大的勇氣，才能朝著正確的方向前進。

良好的軟體開發不是牛仔式程式設計，扔掉第一個你能想到的程式碼。這是一項需要深思熟慮和朝著正確方向努力的工作。

優秀的程式設計師在工作中很謙虛。他們敢於承認他們並不知道所有的一切。

良好的程式碼和良好的程式設計師源於以正確的方式編寫正確的東西的願望。

團隊合作

程式設計師團隊有一套規則。這些規則定義了我們的工作以及我們的工作方式。同時也描述了程式設計文化。

不要依賴模糊的不成文的團隊“規則”。要明確隱含的規則，並控制你的程式設計文化。

要從根本原因上修復 Bug，而不是表面症狀出現的位置。堅持修復表面症狀不會簡化程式碼。

避免在程式碼中隱含假設。

只需編寫所需的程式碼。任何額外的複雜性都將成為負擔。

停下來想一想。不要寫愚蠢的程式碼。

承認你的錯誤和錯誤的程式設計決定。並從中吸取經驗教訓。

勇敢地使用你的大腦。你有權批評程式碼並做出改進程式碼的決定。

瞭解使軟體易於修改的原因，並努力建立具有這些屬性的軟體。

修改程式碼需要的是勇氣和技巧。而不是魯莽。

通常最好進行一系列頻繁、少量、可驗證的改動，而不是一次大規模的程式碼變動。

避免複製和貼上編碼。重構邏輯建立共享函式和公共庫，避免重複程式碼（和重複的 Bug）。

編寫小的模組化程式碼段。保持乾淨整潔。

程式碼應該“共享”，因為它可以用於多個客戶端，而不是因為開發人員想要建立一個漂亮的共享庫。

不要拒絕別人的程式碼。使用現有的庫可能更好，避免編寫自己的版本。

建立軟體版本需要規範和規劃。這不僅僅是在開發人員的 IDE 中點選“構建”。

始終從頭開始構建新的軟體。切勿重複使用構建軟體的舊程式碼。

簡化構建過程，只需一步即可自動完成流程的所有部分。使用指令碼語言執行該操作。

在 CI 伺服器上部署構建以確保其健康。從同一系統釋出正式版本。

不斷學習。積極學習新知識。

我們的學習往往過於狹隘。考慮更廣泛的參考範圍。從許多領域中汲取靈感。

學習時記筆記。即使過後你會扔掉它們。

如果不能用簡單的方式做出解釋，那麼意味著你理解的不夠透徹。

教別人學習一個主題，可以促進自己更好地學習該主題。

耳聽為虛，眼見為實。實踐出真知。

使用你剛學到的東西可以加強記憶。嘗試示例，回答問題，建立業餘專案。

警惕停滯不前。渴望成為更好的程式設計師，就必須掙脫最舒適的生活方式。

投入時間和精力來提高你的技術力。這項投資物有所值，你會收穫豐厚的回報。

不要試圖通過編寫不可讀或不必要的“聰明”程式碼來證明自己“不可或缺”。

獲取軟體資格證是一種榮譽。

不要一葉障目。要準備好面對新挑戰，學習成長為更好的開發人員。

愛所有的程式語言。

學習遵循不同語言的慣例和範例。

考慮學習一些不再常用的語言，以瞭解程式設計歷史。

一個優秀的程式設計師知道多種語言和多種慣例，這可以拓寬他們的解決方案。改進他們編寫的程式碼。

使用程式語言是你每天的例行工作。

要用語言編寫最好的程式碼，你應該接受它的風格和慣例，而不是強迫你自己。

優秀的程式設計師是良好的溝通者。他們會聽說讀寫以及程式設計。

不要指望一夜之間成為語言大師，在工作中不要感到沮喪。

首先集中精力處理最重要的事情。什麼是最緊迫的，什麼會產生最大的價值？

讓計算機幫忙處理重複性的工作。使用指令碼完成自動化。

將大型任務分解為一系列小任務，這樣易於理解的任務。並且可以使你更準確地判斷這些進展。

確認你定義的“已完成”是什麼。

如果你不知道什麼時候能夠完成，那請不要著急動手。

使用程式碼中編寫的測試來定義程式碼的完成和工作的時間。

不要做非必要的工作。只做必須完成的工作。然後住手。

遇到問題，在開始解決問題前，請確保你考慮過多種解決方案。

目標明確是優秀程式設計師的品質。

註釋並不一定能改善程式碼。簡單明瞭的程式碼不需要額外的註釋支援。

瞭解開發的方法、趨勢、宣言和流行。