你好，我是 Kaito。

[[432657]]

今天我想和你聊一聊優(yōu)秀程序員的基本素養(yǎng)。

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

隨著工作時間的增長，漸漸地我也總結(jié)出一些經(jīng)驗，他們身上都保持著一些看似很微小的優(yōu)秀習(xí)慣，但正是因為這些習(xí)慣，體現(xiàn)出了一個優(yōu)秀程序員的基本素養(yǎng)。

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

1、技術(shù)名詞拼寫不規(guī)范

無論是個人簡歷，還是技術(shù)文檔，我經(jīng)?？吹狡磳懖灰?guī)范的技術(shù)名詞，例如 JAVA、javascript、python、MySql、Hbase、restful。

正確的拼寫應(yīng)該是 Java、JavaScript、Python、MySQL、HBase、RESTful，不要小看這個問題，很多面試官很有可能因為這一點刷掉你的簡歷。

2、寫文檔，中英文混排不規(guī)范

中文描述使用英文標點符號，英文和數(shù)字使用了全角字符，中文與英文、數(shù)字之間沒有空格等等。

其中很多人會忽視中文和英文、數(shù)字之間加一個「空格」，這樣排版閱讀起來會更舒服。之前我的文章排版，都是遵循了這些細節(jié)。

3、重要邏輯不寫注釋，或?qū)懙煤芡享?/h3>

復(fù)雜且重要的邏輯代碼，很多程序員不寫注釋，除了自己能看懂代碼邏輯，其他人根本看不懂?；蛘呤亲⑨岆m然寫了，但寫得很拖沓，沒有邏輯可言。

重要的邏輯不止要寫注釋，還要寫得簡潔、清晰。如果是一眼就能讀懂的簡單代碼，可以不加注釋。

4、寫復(fù)雜冗長的函數(shù)

一個函數(shù)幾百行，一個文件上千行代碼，復(fù)雜函數(shù)不做拆分，導(dǎo)致代碼變得越來越難維護，最后誰也不敢動。

基本的設(shè)計模式還是要遵守的，例如單一職責(zé)，一個函數(shù)只做一件事，開閉原則，對擴展開放，對修改關(guān)閉。

如果函數(shù)邏輯確實復(fù)雜，也至少要保證主干邏輯足夠清晰。

5、不看官方文檔，只看垃圾博客

很多人遇到問題不先去看官方文檔，而是熱衷于去看垃圾博客，這些博客的內(nèi)容都是互相抄襲，錯誤百出。

其實很多軟件官方文檔寫得已經(jīng)非常好了，常見問題都能找到答案，認真讀一讀官方文檔，比看垃圾博客強一百倍，要養(yǎng)成看官方文檔的好習(xí)慣。

6、宣揚內(nèi)功無用論

有些人天天追求日新月異的開源項目和框架，卻不肯花時間去啃一啃底層原理，常見問題雖然可以解決，但遇到稍微深一點的問題就束手無策。

很多高大上的架構(gòu)設(shè)計，思路其實都源于底層。想一想，像計算機體系結(jié)構(gòu)、操作系統(tǒng)、網(wǎng)絡(luò)協(xié)議這些東西，經(jīng)過多少年演進才變?yōu)楝F(xiàn)在的樣子，演進過程中遇到的復(fù)雜問題比比皆是，理解了解決這些問題的思路，再看上層技術(shù)會變得很簡單。

7、樂于炫技

有些人天天把「高大上」的技術(shù)名詞掛在嘴邊，生怕別人不知道自己學(xué)了什么高深技術(shù)，嘴上樂于炫技，但別人一問他細節(jié)就會啞口無言。

8、不接受質(zhì)疑

自己設(shè)計的方案，別人提出疑問時只會回懟，而不是理性分析利弊，抱著學(xué)習(xí)的心態(tài)交流。

這些人學(xué)了點東西就覺得自己很有本事，殊不知只是自己見識太少。

9、接口協(xié)議不規(guī)范

和別人定 API 協(xié)議全靠口頭溝通，不給規(guī)范的文檔說明，甚至到了測試聯(lián)調(diào)時會發(fā)現(xiàn)，竟然和協(xié)商的還不一樣，或者改協(xié)議了卻不通知對接方，合作體驗極差。

10、遇到問題自己死磕

很初級程序員容易犯的問題，遇到問題只會自己死磕，拖到 deadline 也沒有產(chǎn)出，領(lǐng)導(dǎo)來問才知道有問題解決不了。

有問題及時反饋才是對自己負責(zé)，對團隊負責(zé)。

11、一說就會，一寫就廢

平時技術(shù)方案吹得天花亂墜，一讓他寫代碼就廢，典型的眼高手低選手。

12、表達沒有邏輯，不站在對方角度看問題

討論問題不交代背景，上來就說自己的方案，別人聽得云里霧里，讓你從頭描述你又講不明白。

學(xué)會溝通和表達，是合作的基礎(chǔ)。

13、不主動思考，伸手黨

遇到問題不去 google，不做思考就向別人提問，喜歡做伸手黨。

每個人的時間都很寶貴，大家都更喜歡你帶著自己的思考來提問，一來可以規(guī)避很多低級問題，二來可以提高交流質(zhì)量。

14、經(jīng)常犯重復(fù)的錯誤

出問題后說下次會注意，但下次問題依舊，對自己不負責(zé)任，說到底是態(tài)度問題。

15、加功能不考慮擴展性

加新功能只關(guān)注某一小塊業(yè)務(wù)，不考慮系統(tǒng)整體的擴展性，堆代碼行為嚴重。

要學(xué)會分析需求和未來可能發(fā)生的變化，設(shè)計更通用的解決方案，降低后期開發(fā)成本。

16、接口不自測，出問題不打日志

自己開發(fā)的接口不自測就和別人聯(lián)調(diào)，出了問題又說沒打日志，協(xié)作效率極低。

17、提交代碼不規(guī)范

很多人提交代碼不寫描述，或者寫的是無意義的描述，尤其是修改很少代碼時，這種情況會導(dǎo)致回溯問題成本變高。

制定代碼提交規(guī)范，能讓你在每一次提交代碼時，不會做太隨意的代碼修改。

18、手動修改生產(chǎn)環(huán)境數(shù)據(jù)庫

直連生產(chǎn)環(huán)境數(shù)據(jù)庫修改數(shù)據(jù)，更有 UPDATE / DELETE SQL 忘寫 WEHRE 條件的情況，產(chǎn)生數(shù)據(jù)事故。

修改生產(chǎn)環(huán)境數(shù)據(jù)庫一定要謹慎再謹慎，建議操作前先找同事 review 代碼再操作。

19、沒理清需求就直接寫代碼

很多程序員接到需求后，不怎么思考就開始寫代碼，需求和自己理解的有偏差，造成無意義返工。

多花些時間梳理需求，能規(guī)避很多不合理的問題。

20、重要設(shè)計不寫文檔

重要的設(shè)計沒有文檔輸出，和別人交接系統(tǒng)時只做口頭描述，丟失關(guān)鍵信息。

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

總結(jié)

以上這些不良習(xí)慣，你命中幾個呢?或者你身邊有沒有碰到這樣的人?

我認為提早規(guī)避這些問題，是成為一個優(yōu)秀程序員必須要做的。這些習(xí)慣總結(jié)起來大致分為這 4 個方面：

• 良好的編程修養(yǎng)
• 謙虛的學(xué)習(xí)心態(tài)
• 良好的溝通和表達
• 注重團隊協(xié)作

優(yōu)秀程序員的專業(yè)技能，我們可能很難在短時間內(nèi)學(xué)會，但這些基本的職業(yè)素養(yǎng)，是可以在短期內(nèi)做到的。

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