關於編程，其實具體用什麼技術並不重要，很多時候是思想或方法決定了效率。今天我讀到一篇帖子：“The Best Programming Advice I Ever Got”，這些建議都是影響着這些業界精英們的職業生涯的，感覺對我很有用，於是在這裏做一個整理。

  • 「寫更少的代碼。」不要覺得寫很多代碼來修補一個 bug 是一件很光榮的事情，有時問題的關鍵只是多餘的一行代碼，刪除即可。寫更多的代碼只會增加維護成本。可以少寫代碼就少寫。

  • 「在動手修改代碼前，先仔細理解報錯。」這一點看起來是廢話，但是我自己也好、別人也好，都多多少少犯過這樣的錯誤。原因很簡單，因爲人們寫代碼的時候很多是在壓力下完成的，比如要在下班前完成某個功能，或者在這禮拜前完成教授佈置的編程作業。所以經常就有人在沒有理解報錯的情況下枉自猜測着 debug。結果是反而浪費了很多時間在無用地猜測和推理上。這種現象在新手身上尤爲顯著，這裏的新手跟你寫程序的時間沒有關係，我雖然寫了十餘年程序，但對 Lisp 這門語言來說我仍然是新手。

  • 「讀多於寫，只讀高質量的書籍，一直更新知識庫。」程序員，尤其是老程序員，會傾向與專攻一項技術。當知識水平滿足了現在的工作需求的時候，一些人可能會停止繼續學習。這樣的程序員往往會遇到以下的情況：比如他是 C++ 程序員，兩年後再看別人新寫的 C++ 代碼，可能會很不能理解。因爲他們的知識體系老化了。技術也是隨着摩爾定律一起發展的。所以當你完成了四年的大學，你已經有一半的知識快要淘汰。所以，繼續學習，學習更好更新的知識。

  • 「學習新的知識，要從更小的切入點進入。」學習新的知識對於程序員來說可以說是家常便飯，可是學得效果是好是壞往往因人而異。導致這種差異的原因有很多，但是我認爲這一點非常關鍵。很多人在學習一個新技術或編程語言的時候偏向於廣泛地學習。事實上這並無助於你對知識的掌握和理解；相反，如果縮小切入點，你能夠學得更好。比如不是學習 JavaScript 一整本厚厚的書，而是學習 JavaScript 的語義學。這樣學習的知識相對少，但是足夠深入；深入之後逐漸會使你學到更廣泛的其他相關知識。這樣你自然能比別人學得好。這也就能解釋爲什麼有些人能夠在短短幾年內成長爲某領域的專家。

  • 「以後別碰別人的代碼。」必須在此聲明，這不是個好建議；相反，你應該更加積極地團隊合作，讓權利鬥爭、包幹領域和理讓得體去見鬼。事實上這個建議是作者早年在一個大企業裏做的時候某個上司給他的。因爲他私自修改了別人的代碼而帶來了很多人際關係上的麻煩。我覺得這個很大程度上跟企業文化有關係。我相信程序員們都是或多或少有 Hacker 情懷的，所以自由開放的工作環境才是適合我們的。遇到這樣的公司，無論薪資怎樣，都請跳槽吧，這樣的企業不值得你在那裏浪費青春。

  • 「debug 前先深入思考。」這一點跟上面的第二點很像。但是作者在文章中提到了在腦中建立模型，深入地理解 bug，這往往不僅可以讓你很快能夠解決局部的 bug，你甚至還能預見更高層次的 bug。

  • 「你要重構代碼，你要 TDD」。代碼重構的目的就在於最大程度地使代碼能夠被重用，要做到這一點，最佳方式是銘記「一個 function 只做一件事，並且把這件事做好」。重構後的代碼通常更加短小便於理解，而且小巧的 function debug 起來也更加方便。其二就是你要貫徹 TDD (Test Driven Design/Development)。筆者一度是 TDD 的反對者，因爲我覺得它太麻煩，浪費了太多時間。而事實上，TDD 恰好可以幫助你節省很多時間。此話怎講？當系統越來越複雜時，任何一個模塊的小變動都有可能引起系統其他部分出錯，那這個時候你可能就需要深入到各個可能出錯的地方尋找癥結。但是如果之前你是一直做 Test 的，那任何新加的模塊或是修改的模塊，只要跑了 Test Suite 你就知道哪兒有問題，而不是等到 release 了，等用戶來給你反饋哪兒哪兒有問題。

  • 「重用之前先確保代碼能用」。其實我認爲這是「不要過早重構」的另一種說法。首先你代碼還不能滿足功用的時候你是不知道哪些東西是要擴展的哪些是要重用的。其次如果過早重構很可能讓你一直停滯不前。

我在總結的時候就已經對以上的好多條深有共鳴了，這些確確實實對我的工作很有幫助。如果還沒有共鳴那恐怕也只是時間問題吧。

最後我也來分享一下對我一直有深遠影響的建議：「70% 思考，30% 做」。