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