每個程式設計師/程序猿/碼農 都該問自己的14個問題

---

Coder 又譯

1. 程式設計師
2. 程序猿
3. 碼農
4. 寫代碼的
5. ...

在 IT 環境打滾久了，還是會看到很多有資歷的 Coder 寫出的程式碼難以維護，

邏輯混亂，又臭又長，甚至連註解都沒有。

程式開發並不是寫愈久經驗值就愈高 ... 這不是遊戲啊！

想不想進步，要不要進步都端看個人願不願意學習與精進。

很多寫了 6~7 年以上的 Coder 依然只會 Copy and Paste ，

很多時候連自己 C&P 的 Code 內容是什麼都不知道 ... 😞😞😞

或者按照既有團隊規則與流程就這樣寫下去，一點疑問也沒有，

對原理與過程一點興趣也沒有。😖😖😖

這就是現實啊！

但是既然走了 IT(哀踢) 路，就無法後悔了，正所謂：

IT無涯，回頭無岸

真的是很辛苦的一條路，走下去全靠興趣。

在對岸王爭的專欄《設計模式之美》，其中提到的如何發現程式碼質量問題，

可以從以下幾個方面審視程式碼，

這也是每次開發的過程中都應該要在內心問自己的問題：

1. 專案目錄設置是否合理、模組劃分是否清晰、程式碼結構是否滿足“高內聚、低耦合”？
2. 是否遵循經典的設計原則和設計思想（SOLID、DRY、KISS、YAGNI、LOD 等）？
3. 設計模式是否應用得當？是否有過度設計？
4. 程式碼是否容易擴展？如果要添加新功能，是否容易實現？
5. 程式碼是否可以復用？是否可以復用已有的項目程式碼或類別庫？
   是否有重複造輪子？
6. 程式碼是否容易測試？單元測試是否全面覆蓋了各種正常和異常的情況？
7. 程式碼是否易讀？是否符合團隊的編碼規範
   （比如命名和註釋是否恰當、代碼風格是否一致等）？
8. 程式碼是否實現了預期的業務需求？
9. 邏輯是否正確？是否處理了各種異常情況？是否保留彈性？
10. 日誌紀錄是否得當？是否方便 除錯(debug) 排查問題？
11. API是否易用？是否支持冪等、交易事務等？
12. 程式碼是否存在平行處理問題？是否為安全的執行續？
13. 性能是否有還有優化空間，比如，SQL、算法、邏輯是否可以再優化？
14. 是否有安全漏洞？比如輸入輸出校驗是否完整且全面？

這些問題都很不簡單，但時常問自己，久了就會改善，

過程中經驗值就會提升了。

希望這些對大家有幫助。

All rights reserved.

---

------------------------ 設計模式/Design Pattern/軟體工程/Software Engineering/軟體開發/Software Developement/GoF/四人幫/ 設計模式之禪/大話設計模式/C#/JAVA/SWIFT/PYTHON/Visual Studio/VSCode ------------------------