糟糕程序员的20个坏习惯
糟糕程序員的20個壞習慣
轉自：https://mp.weixin.qq.com/s/6hUU6SZsxGPWAIIByq93Rw
閱讀本文大約需要 5 分鐘。
你好，我是 Kaito。
今天我想和你聊一聊優秀程序員的基本素養。
我想你肯定遇到過這樣一類程序員：他們無論是寫代碼，還是寫文檔，又或是和別****人溝通，都顯得特別專業。每次遇到這類人，我都在想，他們到底是怎么做到的？
隨著工作時間的增長，漸漸地我也總結出一些經驗，他們身上都保持著一些看似很微小的優秀習慣，但正是因為這些習慣，體現出了一個優秀程序員的基本素養。
但今天我們來換個角度，來看看一個糟糕程序員有哪些壞習慣？只要我們都能避開這些問題，就可以逐漸向一個優秀程序員靠近。
1、技術名詞拼寫不規范
無論是個人簡歷，還是技術文檔，我經常看到拼寫不規范的技術名詞，例如 JAVA、javascript、python、MySql、Hbase、restful。
正確的拼寫應該是 Java、JavaScript、Python、MySQL、HBase、RESTful，不要小看這個問題，很多面試官很有可能因為這一點刷掉你的簡歷。
2、寫文檔，中英文混排不規范
中文描述使用英文標點符號，英文和數字使用了全角字符，中文與英文、數字之間沒有空格等等。
其中很多人會忽視中文和英文、數字之間加一個「空格」，這樣排版閱讀起來會更舒服。之前我的文章排版，都是遵循了這些細節。
3、重要邏輯不寫注釋，或寫得很拖沓
復雜且重要的邏輯代碼，很多程序員不寫注釋，除了自己能看懂代碼邏輯，其他人根本看不懂。或者是注釋雖然寫了，但寫得很拖沓，沒有邏輯可言。
重要的邏輯不止要寫注釋，還要寫得簡潔、清晰。如果是一眼就能讀懂的簡單代碼，可以不加注釋。
4、寫復雜冗長的函數
一個函數幾百行，一個文件上千行代碼，復雜函數不做拆分，導致代碼變得越來越難維護，最后誰也不敢動。
基本的設計模式還是要遵守的，例如單一職責，一個函數只做一件事，開閉原則，對擴展開放，對修改關閉。
如果函數邏輯確實復雜，也至少要保證主干邏輯足夠清晰。
5、不看官方文檔，只看垃圾博客
很多人遇到問題不先去看官方文檔，而是熱衷于去看垃圾博客，這些博客的內容都是互相抄襲，錯誤百出。
其實很多軟件官方文檔寫得已經非常好了，常見問題都能找到答案，認真讀一讀官方文檔，比看垃圾博客強一百倍，要養成看官方文檔的好習慣。
6、宣揚內功無用論
有些人天天追求日新月異的開源項目和框架，卻不肯花時間去啃一啃底層原理，常見問題雖然可以解決，但遇到稍微深一點的問題就束手無策。
很多高大上的架構設計，思路其實都源于底層。想一想，像計算機體系結構、操作系統、網絡協議這些東西，經過多少年演進才變為現在的樣子，演進過程中遇到的復雜問題比比皆是，理解了解決這些問題的思路，再看上層技術會變得很簡單。
7、樂于炫技
有些人天天把「高大上」的技術名詞掛在嘴邊，生怕別人不知道自己學了什么高深技術，嘴上樂于炫技，但別人一問他細節就會啞口無言。
8、不接受質疑
自己設計的方案，別人提出疑問時只會回懟，而不是理性分析利弊，抱著學習的心態交流。
這些人學了點東西就覺得自己很有本事，殊不知只是自己見識太少。
9、接口協議不規范
和別人定 API 協議全靠口頭溝通，不給規范的文檔說明，甚至到了測試聯調時會發現，竟然和協商的還不一樣，或者改協議了卻不通知對接方，合作體驗極差。
10、遇到問題自己死磕
很初級程序員容易犯的問題，遇到問題只會自己死磕，拖到 deadline 也沒有產出，領導來問才知道有問題解決不了。
有問題及時反饋才是對自己負責，對團隊負責。
11、一說就會，一寫就廢
平時技術方案吹得天花亂墜，一讓他寫代碼就廢，典型的眼高手低選手。
12、表達沒有邏輯，不站在對方角度看問題
討論問題不交代背景，上來就說自己的方案，別人聽得云里霧里，讓你從頭描述你又講不明白。
學會溝通和表達，是合作的基礎。
13、不主動思考，伸手黨
遇到問題不去 google，不做思考就向別人提問，喜歡做伸手黨。
每個人的時間都很寶貴，大家都更喜歡你帶著自己的思考來提問，一來可以規避很多低級問題，二來可以提高交流質量。
14、經常犯重復的錯誤
出問題后說下次會注意，但下次問題依舊，對自己不負責任，說到底是態度問題。
15、加功能不考慮擴展性
加新功能只關注某一小塊業務，不考慮系統整體的擴展性，堆代碼行為嚴重。
要學會分析需求和未來可能發生的變化，設計更通用的解決方案，降低后期開發成本。
16、接口不自測，出問題不打日志
自己開發的接口不自測就和別人聯調，出了問題又說沒打日志，協作效率極低。
17、提交代碼不規范
很多人提交代碼不寫描述，或者寫的是無意義的描述，尤其是修改很少代碼時，這種情況會導致回溯問題成本變高。
制定代碼提交規范，能讓你在每一次提交代碼時，不會做太隨意的代碼修改。
18、手動修改生產環境數據庫
直連生產環境數據庫修改數據，更有 UPDATE / DELETE SQL 忘寫 WEHRE 條件的情況，產生數據事故。
修改生產環境數據庫一定要謹慎再謹慎，建議操作前先找同事 review 代碼再操作。
19、沒理清需求就直接寫代碼
很多程序員接到需求后，不怎么思考就開始寫代碼，需求和自己理解的有偏差，造成無意義返工。
多花些時間梳理需求，能規避很多不合理的問題。
20、重要設計不寫文檔
重要的設計沒有文檔輸出，和別人交接系統時只做口頭描述，丟失關鍵信息。
有時候理解一個設計方案，一個好的文檔要比看幾百行代碼更高效。
總結
以上這些不良習慣，你命中幾個呢？或者你身邊有沒有碰到這樣的人？
我認為提早規避這些問題，是成為一個優秀程序員必須要做的。這些習慣總結起來大致分為這 4 個方面：
- 良好的編程修養
- 謙虛的學習心態
- 良好的溝通和表達
- 注重團隊協作
優秀程序員的專業技能，我們可能很難在短時間內學會，但這些基本的職業素養，是可以在短期內做到的。
希望你我可以有則改之，無則加勉。
你認為還有哪些程序員的壞習慣，歡迎在評論區留言討論~
總結
以上是生活随笔為你收集整理的糟糕程序员的20个坏习惯的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： leetcode 676. Implem
- 下一篇： 哈夫曼编解码（C语言）