告别沒有成長的爛代碼

程式員的看家本領你得練好

  畢業後我就加入了一家跨境電商企業，至今我還清晰地記得，我第一次送出代碼的時候，短短的 100 多行代碼，被同僚 review 出了 n 多問題，來來回回改了不下十幾個版本才送出上去。我當時有很大的逆反心理，覺得有必要浪費這麼多時間在如此細節的編碼上嗎？隻要代碼能用、能解決問題不就夠了嗎？

  工作一段時間之後，我才發現自己當時的想法有多幼稚。寫代碼可以說是程式員天天要幹的事情，要是代碼都寫不好，最基本的看家本領都練不好，成天堆砌爛代碼，寫代碼還有啥意思呢？那還幹啥程式員啊！寫出“能用”代碼的人比比皆是，但是，并不是每個人都能寫出“好用”的代碼。隻會寫能用的代碼，我們永遠成長不成大牛，成長不成最優秀的那批人。

  後來我熟練掌握了各種編寫高品質代碼的技巧、方法和理論，我發現，實際上，寫爛代碼和好代碼花費的時間是差不多的。當你把寫高品質代碼培養成一種開發習慣之後，在你在編寫代碼的時候，自然就有一種代碼品質意識，自然而然就可以寫出不錯的代碼。即便在我離開加入其他公司之後，項目的代碼品質因為各種原因有所妥協，但我起碼知道什麼樣的代碼是高品質代碼，絲毫不影響我具備寫出高品質代碼的能力。

  我相信，很多工程師都很重視代碼品質，畢竟誰也不想寫被人吐槽的爛代碼。但是，就我的了解來看，毫不誇張地講，很多工程師，甚至一些 BAT 的員工，代碼都寫得慘不忍睹。一方面，在目前這種快糙猛的開發環境下，很多工程師并沒有太多時間去思考如何寫高品質代碼；另一方面，在爛代碼的熏陶下，在沒有人指導的環境裡，很多工程師也搞不大清楚高品質代碼到底長什麼樣。這就導緻很多工程師寫了多年代碼，代碼功力一點都沒長進，編寫的代碼仍然隻是能用即可，能運作就好。平日的工作就是修修補補、抄抄改改，一直在做重複勞動，能力也一直停留在“會幹活”的層面，就像高速路上的收銀員，隻能算是一個“熟練工”。

  一個人悶頭看書效果并不好, 當然，也有一些比較上進的工程師，會去找設計模式、編碼規範、重構等類型的書籍去看，學習如何編寫高品質的代碼。實際上，我也買了很多這類的書籍來看，從這些經典的書籍中，我也學到了很多程式設計技巧和提高代碼品質的方法。不過，這些書籍都有一個特點，那就是比較偏重理論講解，喜歡拿貓、狗之類生活中的例子來舉例。當然，這樣的例子也有優點，那就是能在簡短的時間和篇幅内，很好地幫你了解原理。但同時也存在一個嚴重的問題，那就是過于脫離真實的軟體開發。而且例子本身沒有難度，你一看就覺得懂了，但是看完之後，可能還是不清楚如何将理論落地到實際的項目編碼中。

  比如，我們都知道著名的 KISS 原則（Keep It Simple and Stupid）。這個原則了解起來很簡單，一看貌似就懂了，那我問你，怎樣的代碼才算是足夠簡單呢？怎樣才算不夠簡單需要優化呢？估計很多人都回答不上來，因為大部分書籍都沒有講清楚。 除此之外，一個人自己悶頭看書，在很多時候效果并不好。一方面，每個人的了解能力是不一樣的。對于同一本書，不同了解能力的人看完之後收獲也是不一樣的。跟着有經驗的老師學比悶頭自己看書要更高效、收獲更多、成長更快。另一方面，編碼本身就是一門 ​

​實踐​

​ 課，光悶頭看書本理論肯定是不夠的，更重要的是在實踐中學習如何應用這些理論。

一對一手把手指導才最有效

  從我的經驗來看，我覺得最有效、最快速提高編碼能力的方法就是，找一個比你資深的工程師，一對一、手把手地指導你寫代碼。你送出代碼，他來指出你的問題，你再優化，這樣一來一往，要不了多久，你就會發現，自己的代碼能力突飛猛進。但是，理想很豐滿，現實很骨感。且不說能不能找到這樣有資格指導你的人，即便能找到，他願不願意、有沒有時間來手把手指導你，還是另外一回事。而我比較幸運，在畢業之後就加入了一家跨境電商企業，得到了頂尖工程師的指導，一對一地給我 review 代碼，手把手地指導我如何優化代碼。正因如此，在跨境電商企業的那段時間也成為了我編碼能力提高最快的一段時間。