壞習慣

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、重要設計不寫文檔

重要的設計沒有文檔輸出，和别人交接系統時隻做口頭描述，丢失關鍵資訊。

有時候了解一個設計方案，一個好的文檔要比看幾百行代碼更高效。