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