你好，我是 Kaito。

[[432657]]

今天我想和你聊一聊優秀程序員的基本素養。

我想你肯定遇到過這樣一類程序員：他們無論是寫代碼，還是寫文檔，又或是和別人溝通，都顯得特別專業。每次遇到這類人，我都在想，他們到底是怎么做到的?

隨著工作時間的增長，漸漸地我也總結出一些經驗，他們身上都保持著一些看似很微小的優秀習慣，但正是因為這些習慣，體現出了一個優秀程序員的基本素養。

但今天我們來換個角度，來看看一個糟糕程序員有哪些壞習慣?只要我們都能避開這些問題，就可以逐漸向一個優秀程序員靠近。

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 個方面：

• 良好的編程修養
• 謙虛的學習心態
• 良好的溝通和表達
• 注重團隊協作

優秀程序員的專業技能，我們可能很難在短時間內學會，但這些基本的職業素養，是可以在短期內做到的。

希望你我可以有則改之，無則加勉。