那些會阻礙程序員成長的細節

羅馬非一日建成，軟件系統也不是一天可以寫出來的，在經年累月的編碼生活中，總會那麼些個不經意的瞬間暴露出來，而這些不經意的外在表現日積月累，猶如水滴石穿，會產生巨大的力量副作用於程序員的成長。我簡單列了幾條，看一看，興許就在你我身邊實實在在發生過。

拿到開發任務後，直接上手寫代碼。缺乏必要的溝通與設計，返工的機率極大。先後端數據的交互格式，功能潛在的關聯點不清晰，接口調用方功能是否完備，存儲結構的設計，複雜業務的流程設計等等，都須要事先溝通肯定好，再動手寫代碼才能遊刃有餘，否則會走一步卡一步，進展緩慢，甚至倒退。

在邏輯混亂的地方加入新東西，而不是去重構。因爲功能的新增或變動，須要在舊有的代碼邏輯中添加新功能，本是一個很好的重構機會，但不少的作法時在原有的基礎上填填補補，結果一片混亂。特別是在本已混亂的地方還要加入新代碼邏輯，運行起來確實沒有問題，但對自身代碼質量的保證零意義。

不肯意與別人分享技術成長。教是學習最快的一條路，將本身所學傳播分享給他人，並使他人能消化吸取，是對本身知識掌握一個最好的檢驗。同時在分享的過程當中溫故而知新，更加深對知識技能的掌握。若是你有教會徒弟餓死師傅的想法，會顯得很落伍。互聯網時代下，還有什麼知識技能，是你獨有而別人歷來沒有的？不如拿出來分享，你們共同成長。一個走的快，但一羣人才走的遠。

遇到BUG首先否認是本身的問題。這是一個普適性的問題，也是程序員遇到BUG時的第一反應。究竟是不是別人的問題呢，每每是問題轉了一圈又回到本身手裏。耽誤了你們的時間，同時下降的解決問題的效率。正解的姿式應該是當即檢查自身，肯定是否是本身的問題，是就當即改正，若不是，能找到問題所在最好，交由他人去處理，這是一種良好的習慣。

缺少驗證條件時，開發的功能不經測試直接交付給測試人員。一種是過於自信的表現，還有一種是懶惰的表現。有自信是好的，但若是能通過實際的場景來檢驗，雙重保險，對本身對團隊都是保證。懶惰就是不負責任的表現，有些功能確實測試起來很複雜，但爲了保證功能的可用性，沒有條件去創造條件也要完成，這也是一種態度。

修復某BUG時，夾帶其它問題。一個未被測試人員發現的BUG，自我發現後私自修復，並提交源碼。這在測試階段比較常見，但後期若是還出現這種問題，對產品/項目的穩定性是個極大的隱患，特別是生產環境。這是一個流程規範問題，也是一個職業素養問題。

先簡單寫到這裏，以上這些都不是大問題，但若是不注意，長此以往會演變成大問題。程序員是個特殊的物種，物種的進化依賴咱們自身的知識結構、思惟層次，更依賴於平常工做生活的三省其身，常常覆盤總結回顧，才能發現問題，近而解決問題。