1、有時候寫垃圾代碼也沒關系。不是所有軟件的組成部分都是生來平等的。

2、你不需要通過學習一門新的語言來學習新的東西，同樣的事情不同的編程語言都可以做到，應該注重深度而不是廣度。

3、編寫拋棄型代碼以測試不同的方法。別把這些拋棄型代碼變成產品代碼。

4、防御性編程：你還記得你曾經認為的不會為空的方法參數么？是啊，結果它還是變成了空值，你的應用程序“爆炸”了。你只要編寫這些保護條款并完成它就可以了。

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

6、編寫易于測試的代碼。這意味著停止在命令處理程序、服務類等內部“更新”數據庫對象。相反，應該把它變成一種依賴項。

7、只有在異常發生時才會報錯

8、學習If-Else的適當替換。If-Else經常被過度使用，并且是糟糕設計的早期標志。很多設計模式都不需要If-Else語句。

9、并不是每個IF都需要一個ELSE IF或ELSE。“IF”本身是好的，應該被廣泛使用

10、學會重構，在重構過程中，不要試圖添加新功能。不會有好結果的。

11、如果發現了垃圾代碼，請花時間清理它，使之更好。

12、如果你不學習設計模式，你將寸步難行，因為它們無處不在

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

14、抨擊別人的代碼并不能讓你成為更好的程序員，也不能顯示你的資歷。首先，初學者抨擊其他開發人員的代碼，那是因為他們很難理解別人的代碼，即使是簡單的概念。

15、如非必要別創建接口，由具體的類開始完全沒有問題。

16、你是否確定該字段 / 屬性 / 方法需要公開？沒有，我也這么認為，將其設為私有或者內部。

17、超簡單類——比如一個簡單的方法——是可行的。

18、為簡單的問題匹配簡單的代碼

19、確保對要重構的每個部分都進行了測試。否則，你不會知道你破壞了什么。

20、剛剛草草記下的代碼并不比下載量為 1100 萬的 npm/nuget/pip 包好。下載那個該死的軟件包，并繼續前進。

21、不要害怕為復雜的問題想出復雜的解決方案。

22、學幾門語言是可以的。嘗試使用一種后端、前端和數據庫語言。這樣你就會更欣賞你的團隊成員在處理什么。

23、不要再看過多的教程了，多自己思考，當然，當你遇到問題或需要快速學習某些內容時，偶爾的教程是不錯的選擇。

24、大多數其他開發人員也會編寫垃圾代碼，但也不要因此就喪失信心。

25、觀看開發者會議的講座，并關注思想領袖。有很多很好的經驗可以借鑒，而且很容易得到啟發。

26、在成為更好的開發者的過程中，我們都遇到了瓶頸。向成熟的開發人員尋求建議。不要害怕向優秀的人討教。

27、以 GUID/UUID 作為實體 ID，這使得處理起來更加簡單。但是，請注意你的取舍。

28、遵守 SOLID 原則，它們很容易理解并提高代碼質量。

29、如果選項的數量有限，那么使用枚舉而不是字符串作為參數。

30、在模塊中安排代碼（項目以 .NET 術語表示）。別把所有的東西都放在一個模塊里。很快就會失去控制。

31、對于企業來說，代碼只是實現目標的一種手段。

32、將軟件開發視為一種手藝。編寫出有目的、漂亮的代碼。主動去提高自己的技能。

程序員書庫（ID：CodingBook） 猿妹編譯

編譯自：https://medium.com/swlh/32-opinionated-advice-and-lessons-learned-in-software-development-cc1939847f0a

IT技術分享社區

個人博客網站：https://programmerblog.xyz

文章推薦程序員效率：畫流程圖常用的工具程序員效率：整理常用的在線筆記軟件遠程辦公：常用的遠程協助軟件，你都知道嗎？51單片機程序下載、ISP及串口基礎知識硬件：斷路器、接觸器、繼電器基礎知識

總結

以上是生活随笔為你收集整理的程序人生：32条软件开发的建议和教训，值得读一读！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。