本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

過去的幾年里，筆者一直在為各種大小客戶專業開發軟件。一些軟件已經在非常嚴格的環境中使用了，在這些環境中，安全性和可靠性是最重要的。根據多年的經驗，我整理了一些實用建議。無需贅言，以下是一些自認為實用的建議、經驗和優秀實踐。

[[338899]]

1. 偶爾寫寫垃圾代碼沒關系，應用程序的各個部分并非都是平等的。

2. 無需學習一門新的語言來學習新東西，同樣的事情通常可以用許多語言來完成，深度勝于廣度。

3. 可以編寫一次性代碼來測試不同的方法，只是不要讓一次性代碼變成生產代碼。

4. 防御性代碼。還記得你認為的永遠不會為空的方法參數嗎?是的，事實證明它為空，你的應用程序爆炸了，只需編寫這些保護條款并加以使用即可。

5. 拒絕硬編碼應用程序設置。編寫可配置組件并將環境變量傳遞給它們，重新啟動應用程序比重新編譯和重新部署更容易。

6. 編寫易于測試的代碼。這意味著停止在命令處理程序、服務類等內部“新建”數據庫對象等等，而是將其轉變為依賴項。

圖源：unsplash

7. 僅在發生異常情況時拋出異常。

8. 了解If-Else的合適替代方法。If-Else經常被過度使用，它是設計不良的早期跡象，事實上，許多設計模式都不需要If-Else語句。

9. 并非每個IF都需要ELSE IF或ELSE。

10. 重構就是重構。在進行重構時，請勿嘗試添加新功能，相信我，結果不會很好。

11. 當識別垃圾代碼時，花點時間把它清理干凈，使其變得更好——無論“更好”在特定情況下意味著什么。

12. 若不學習設計模式將會遇到困難。它們無處不在，學習它們可以使工作更輕松。

13. 應用設計模式很可能會改進代碼。

14. 抨擊別人的代碼不會讓你成為更好的程序員，也不能彰顯你的資歷。初學者抨擊其他開發人員的代碼的主要原因是，即使是簡單的概念，他們有時也會很難理解。

15. 在需要界面之前不要先創建界面，從具體的類開始就完全可以了。

16. 確定字段/屬性/方法需要公開嗎?不，將其私有化或內部化即可。

17. 超級簡單的類(就像簡單的方法一樣)是正確的方法。

18. 為簡單問題編寫簡單代碼。

19. 確保對重構的每一部分都進行測試，否則你將不知道自己的問題所在。

20. 剛剛記下的代碼并不比具有1100萬次下載量的NPM / NuGet / pip程序包更好，下載f * kn程序包并繼續。

21. 不要害怕為復雜的問題提出復雜的解決方案，只是要把握好大方向。

[[338900]]

圖源：unsplash

22. 你可以選擇幾種語言。嘗試使用后端、前端和數據庫語言，你會對團隊其他成員正在處理的事情深深地感激。

23. 停止觀看各種無用的教程，試著得出有自己的想法。當然，當遇到問題或需要快速學習時，偶爾使用教程也可以，只是不要受困于教程。

24. 大多數開發人員也編寫垃圾代碼。不要迷失自己的方向，他們這樣做肯定是有原因的。

25. 觀看開發者大會演講，追隨思想領袖，可以吸取豐富的經驗并容易獲得靈感。

26. 在成為更好的開發人員過程中，每個人都會遇到一段停滯期。向有經驗的開發人員尋求建議，不要害怕向任意一位開發人員發送消息。

27. 將GUID / UUID用作實體ID通常會使事情更容易處理，但請注意要做出的權衡。

28. 遵守SOLID原則。它們易于理解，可以提高代碼質量。諸如“遵守或違背原則無所謂”之類的說法會傷害到你。

29. 如果選項數量有限，請用字符串枚舉作為參數。

30. 將代碼排列在模塊中(以.NET術語表示的項目)。不要將所有內容都放在一個模塊中，這樣很快就會失控。

31. 記住，要解決的業務問題或開發的業務應用程序是最重要的事情。對于企業而言，你的代碼只是達到目的的一種手段。

32. 將軟件開發視為一門手藝。編寫目標明確的美觀代碼，積極提高自己的技能。

[[338901]]

圖源：unsplash

這只是筆者自己在實際工作中總結出來的經驗建議，肯定會有人反對上面的一些建議，總是會有不同的意見、方法和心態，多角度考慮是有益的。你要做的是保持批判性，并把你認為有意義的內容融入到自己的思想行為體系當中。

【責任編輯：趙寧寧 TEL：（010）68476606】