全文共1918字，預計學習時長5分鐘
圖源：unsplash
過去的幾年裡，筆者一直在為各種大小客戶專業開發軟件。一些軟件已經在非常嚴格的環境中使用了，在這些環境中，安全性和可靠性是最重要的。根據多年的經驗，我整理了一些實用建議。無需贅言，以下是一些自認為實用的建議、經驗和最佳實踐。
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.不要害怕為複雜的問題提出複雜的解決方案，只是要把握好大方向。
圖源：unsplash
22.你可以選擇幾種語言。嘗試使用後端、前端和數據庫語言，你會對團隊其他成員正在處理的事情深深地感激。
23.停止觀看各種無用的教程，試著得出有自己的想法。當然，當遇到問題或需要快速學習時，偶爾使用教程也可以，只是不要受困於教程。
24.大多數開發人員也編寫垃圾代碼。不要迷失自己的方向，他們這樣做肯定是有原因的。
25.觀看開發者大會演講，追隨思想領袖，可以吸取豐富的經驗並容易獲得靈感。
26.在成為更好的開發人員過程中，每個人都會遇到一段停滯期。向有經驗的開發人員尋求建議，不要害怕向任意一位開發人員發送消息。
27.將GUID / UUID用作實體ID通常會使事情更容易處理，但請注意要做出的權衡。
28.遵守SOLID原則。它們易於理解，可以提高代碼質量。諸如“遵守或違背原則無所謂”之類的說法會傷害到你。
29.如果選項數量有限，請用字符串枚舉作為參數。
30.將代碼排列在模塊中（以.NET術語表示的項目）。不要將所有內容都放在一個模塊中，這樣很快就會失控。
31.記住，要解決的業務問題或開發的業務應用程序是最重要的事情。對於企業而言，你的代碼只是達到目的的一種手段。
32.將軟件開發視為一門手藝。編寫目標明確的美觀代碼，積極提高自己的技能。
圖源：unsplash
這只是筆者自己在實際工作中總結出來的經驗建議，肯定會有人反對上面的一些建議，總是會有不同的意見、方法和心態，多角度考慮是有益的。你要做的是保持批判性，並把你認為有意義的內容融入到自己的思想行為體系當中。
留言點贊關注
我們一起分享AI學習與發展的乾貨
如轉載，請後臺留言，遵守轉載規範
