十个现象，识别程序员的“水份”
大家好，我是Z哥。
下周五正好是國慶，我也給自己放個假，就不發文了。所以今天是節前最后一篇文章，先提前祝大家國慶快樂，可以好好放松一下。
今天我們不聊干貨了，聊點輕松的，來吐槽一下程序員的那些事兒。
在軟件開發領域一直流傳著一句話，它說明了程序員的水平和資歷之間并不存在著相關性，并且可能相差特別大。
到底是貨真價實的十年經驗？還是一年經驗重復用了十年？
隨著我在工作中遇到過的人越來越多、面試過的人越來越多，發現這句看似夸張的話講述的的確是事實。
有些人工作了 7、8 年，所表現出來的專業性就像剛入行 1、2 年的新人。并且,比新人還不如的是，他們身上往往也沒有了新人的那種學習欲望。
與之相對的，我也與剛畢業就加入公司的應屆生共事過，他們身上所表現出的驚人成長能力，讓他們在不到一年的時間內就挑起了項目組的大梁。
經過我對所接觸過的程序員們的觀察，我總結出了一些“信號”，他們可以幫助你識別出與你一起工作的同事到底是不是“貨真價值”。
然后，你就可以與那些“貨真價實”的資深程序員們多打交道、多交流，與厲害的人多在一起，自己也更容易變得厲害。
好了，下面開始。
如果你發現某位工作多年的程序員身上有這些現象出來，那么他大概率就是一位“有水份的高級程序員”。符合的現象越多，水份越大……
/01? 總是喜歡“攢”一些代碼后再提交代碼/
不知道你有沒有留意過，一個團隊里只要有一個人喜歡“攢”代碼，那么這個項目的代碼合并將會長期面臨代碼沖突的痛苦。
道理很好理解，兩個胖子之間的碰撞面積，總比兩個瘦子大吧。
而且喜歡這么干的人往往也不太認可 CodeReview 這事，為啥？
因為他大概率沒有想過，做 CodeReview 的人，一次性看到幾十上百個變更文件時的感受。
我們可以建議他們，實現或者修復一個完整的小問題和小任務，就提交一次代碼。最差也得每天提交一次，當然，需要將未實現的部分做好處理，避免編譯報錯。
/02? 總是很早就開始 coding，但是很晚才通過驗收/
用馬保國老師的話來說，“有些程序員寫代碼很快啊，pia 一下，我都來不及閃，他就寫了好幾行代碼了。”
他們實現功能很快，不熟悉的人還以為是高手。但是實際上，他們修 bug 的時間往往會明顯多于其他人，最終可能反而導致拖整個項目進度的后腿。
雖說不一定非得每次花時間正兒八經的畫圖，做設計。但是真正有經驗的程序員，他們寫代碼之前腦子里是會先梳理好思路的，有一個清晰的達到終點的“路線”。這樣他在寫下每一行代碼的時候，都知道他在做什么，而且下一步是什么。
所以，我們可以建議他們寫代碼之前，稍微多花點時間去搞清楚一些業務問題，梳理清楚需求。并且在寫代碼之前做一下規劃，避免后來你的代碼只有你自己看得懂，甚至是自己都看不懂。
/03? 看上去很忙，在多件事之間來回奔波/
在團隊里越是核心的人員總是越忙的，但并不是所有忙的人都是核心人員。因為有些忙是自己導致的。比如，當我們面前有多個問題需要處理的時候，不是誰來催得緊，你就先處理哪個。還得自己心里有一桿秤，根據優先級來處理。
否則，花費了大量時間在多個事情之間切換，實際真正的有效工作時間可能連一半都不到。
我們可以建議他們不管是做任何還是修 bug，搞定一個之后再進行下一個，除非每次新來的問題都比之前的優先級高。但是，應該沒那么巧吧？
另外，將任務分解成小任務，也更有利于自己掌控時間。
/04? 固執己見/
如果一位缺乏經驗的程序員恰好又是團隊里資歷比較老的，那就很容易出現固執己見的情況。
這會使得他進入一個不太好的循環里去。自我感覺良好 -> 無法改掉身上的壞毛病 -> 資歷老，聽不進別人的 -> 自我感覺良好。
但是往往獲取經驗最快的方式是以開放的心態與別人交流，學習別人的長處，補足自己的短處。
所以，我們可以建議他們多考慮一下事物好壞的另一面，畢竟任何事物都有兩面性。
/05? 不斷地重復掉進同一個坑/
畢竟有了不少工作年限，所以當遇到生產環境的 bug 時，不會出現真正的新手那樣不知從何下手的情況。他們會祭出打 log 大法，或者是調試大法，用最快的速度解決問題。然后，就沒有然后了。
從別人眼中看來，他們這是頭痛醫頭，腳疼醫腳。但是在他們眼里，沒有任何兩個“坑”是一樣的，每個都不同，所以，下次相同的問題再次出現也是正常的。這種做法真的難以給人靠譜、放心的感覺。
所以，我們可以建議他們。在出問題后，先通過邏輯分析思考一下問題可能出在哪里，梳理相關的信息和思路。然后，即使解開了 Bug ，也應該多思考一下是否其它部分也有類似的問題。
/06? 盲目追逐技術潮流/
你說他們完全不學習吧，也不是。當從身邊很多人的嘴里聽到同一個技術名詞的時候，他會視該技術為傳說中的“ SliverBullet ”，趕緊去學習官方教程。
但是，往往跟著入門教程走完一遍之后，就覺得這也沒什么難的，自己已經掌握了。實際上，沒有經過實戰的使用就覺得掌握，僅僅是一種幻覺而已。因為一旦實際進行落地，往往會出現各種意料之外的問題等待著你去解決，甚至有些是連官網都未發現的bug。
他們對新技術的崇拜，其實是他們覺得，如果自己不了解這個新技術，會覺得錯過些什么。
所以，我們建議他們抱著學以致用的心態去學新技術，或者至少不要只停留在官方教程上，找一個自己工作或者生活中的場景，用新技術來實現一個功能。
/07 ?代碼寫得很隨意/
寫代碼隨意的場景有很多，小到變量、方法的命名規范與否，大到整體的架構設計上是否有考慮到一些非顯性的問題，如性能、擴展性等等。
缺乏經驗的程序員，不但全部命中上面這些點，而且寫出來的代碼，其它人很難看懂，特別在一些業務本身就有一定復雜度的場景中。
相反，優秀的程序員們在編寫自認為復雜的代碼段的時候，會寫下清晰的注釋來幫助后來人理解。因為他們知道代碼不僅是讓計算機執行，更是需要讓別人也理解的，因為項目開發大多是團隊協作。
所以，我們可以建議他們在寫代碼的時候考慮一下，如果兩年后回頭來看今天寫下的代碼，還看得懂嗎？
/08? 總喜歡直接調試生產環境/
“線上有問題？來說下你怎么操作的，我調試一下。”
“接口報錯？參數發我，我調試一下。”
這些是他們的口頭禪。不可否認，從理論上來說，直接調試線上必然是解決問題最快的方式，畢竟直接面對案發現場。但也正是因為解決地過于容易，導致自己不容易“長記性”，下次大概率還會犯一樣的錯誤。所謂，“捷徑走多了，人就廢了。”
另外，一旦對項目不是100%的熟悉，那么搞不好在調試的過程中，不知不覺給生產環境產生了垃圾數據，可能進一步導致埋下了新的隱患。
所以，我們可以建議他們，遇到問題先思考，用你的專業知識和業務經驗進行邏輯分析，如此，也能提煉出一些普適性的規律避免自己后續再犯相同的錯誤。
/09? 不做自測/
前面提到過有些伙計寫代碼很快，其實他們之中的大部分也不會做自測，畢竟這會降低他們的開發速度。而且，在他們心里可能覺得測試嘛，不是應該測試工程師干的么，我都自測過一遍的話，不是搶他們飯碗么。
當然，如果有些公司有明確的工作要求需要自測，他們也會做，但不是去盡量模仿真實的數據，而是用很隨意的數據來測試，效果其實是很差的。
自測的好處有很多，最直接的就是可以降低修復bug總時間，畢竟，開發和測試之間溝通bug的時間肯定就節省掉了。
所以，我們可以建議他們做自測，因為這不但可以讓整個項目的工期得以更快完成，也能讓自己和其他人擺脫加班、擺脫996，不香么。
/10? 不主動推進項目進度/
資深的程序員身上會有那種領袖氣質，這種領袖氣質并不是憑空出現的，而是需要有主動推進一件事往前發展的意愿。
而那些有資歷卻缺乏經驗的程序員們則完全相反，只著眼于自己的一畝三分地，其它的都與我無關。如此一來他們也錯失了快速擴大自己能力圈的機會。
從資歷的這個角度上來說，作為團隊里懂得最多的人，是推動項目往前的最佳人選。
所以，我們可以建議他們多給出自己積累多年的經驗，因為“你是專家”。
怎么樣？是不是很多現象都很熟悉？
其實還有很多其它的現象，只是上面這些是比較常見的。
其實我們不是在吐槽他們，而是希望他們能夠發揮自己真正的價值，這不僅僅是為了整個團隊創造更好的工作環境，也是為了避免他們迷失在走向中年危機的道路上。
希望大家能夠多多轉發，能叫醒一個算一個，幫助他人，也是幫助自己，不香么。
推薦閱讀：
10個人里有幾個大學生？
提高「搜商」，掙大錢
原創不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創作 ：）
也可以分享我的公眾號名片給有需要的朋友們。
如果你有關于軟件架構、分布式系統、產品、運營的困惑
可以試試點擊「閱讀原文」
總結
以上是生活随笔為你收集整理的十个现象，识别程序员的“水份”的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【.NET】实现CI/CD（二）运行镜像
- 下一篇： EF 更新大量的数据时出现重复键错误