高效能程序員的七個習慣

http://news.cnblogs.com/n/202000/

昨天收到一個讀者留言，問做爲程序員，有什麼學習和工做上的好習慣能夠借鑑？想了想，乾脆附庸風雅一下，總結個『高效能程序員的七個習慣』吧。Disclaimer：一家之言，可不信，但不可全信。

　　擁抱 unix 哲學

　　每一個程序員入門的第一堂和第二堂課應該是和 unix 哲學相關的內容，簡言之就是：作一件事，作好它。具體點：

• 小便是美。
• 讓程序只作好一件事。
• 儘量早地建立原型。
• 可移植性比效率更重要。
• 數據應該保存爲文本文件。
• 儘量地榨取軟件的所有價值。
• 使用 shell 腳原本提升效率和可移植性。
• 避免使用可定製性低下的用戶界面。
• 全部程序都是數據的過濾器。

　　再具體一些（TL;DR）：

In [1]: import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules. Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch. Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

　　選一個樣板，follow 之

　　每一個 NBA 新秀都有本身的樣板，咱們也總習慣稱某足球新星爲『小羅』，『小小羅』。樣板爲你提供了可模仿可追趕的對象，同時也讓你審視本身究竟想成爲何樣的程序員。個人樣板是 Greg Pass 和 Werner Vogels，雖然我這輩子可能也達不到他們的高度，可這並不妨礙向着我心目中的明星一步步靠近。

　　寫代碼，而不是調代碼

　　寫軟件最糟糕的體驗恐怕是邊寫邊調，寫一點，運行一下，再寫一點。是不少程序員都會這麼幹。緣由有二：1. 不熟悉相關的代碼（類庫），須要邊寫邊運行保證代碼的正確。2. 現代編程語言的 REPL (Read-Evaluate-Print-Loop，就是語言的 shell)能力滋長了這一行爲。

　　寫系統軟件的人不多這麼作。他們手頭糟糕的工具讓邊寫邊調的行爲成爲效率殺手 —— 若是稍稍改動，編譯就要花去幾分鐘，甚至更長的時間，你還會這麼幹麼？因此他們每每是寫完一個模塊，再編譯調試。（由此看來，高效的工具備時候是把雙刃劍啊）

　　我以爲寫代碼就跟寫文章同樣，構思好，有了大綱，就應該行雲流水同樣寫下去，一鼓作氣，而後回過頭來再調整語句，修改錯別字。若是寫完一段，就要回溯檢查以前寫的內容，效率很低，思惟也會被打散。

　　靠邊寫邊調作出來的代碼還每每質量不高。雖然局部通過了雕琢，但總體上不那麼協調，看着老是彆扭。這就比如雕刻，拿着一塊石頭，你先是精修了鼻子，而後再一點一點刻畫面部。等修到耳朵的時候，鼻子可能過大或太小，即使再精美，它也得不到讚揚。

　　聰明地調試

　　軟件總會出問題。遇到問題，不少程序員就會用 IDE 在各類可能的地方加斷點調試，若是沒有 IDE，那麼各類 print/log 手段一齊拋出，有棗沒棗打一杆子再說。

　　優秀的程序員會在撰寫代碼的時候就考慮到調試問題，在系統關鍵的節點上注入各類等級的調試信息，而後在須要的時候打開相應的調試級別，順藤摸瓜，避免了不靠譜的臆測。這是調試之『道』。

　　不少問題打開調試開關後就原形畢露，但有時候靠調試信息找到了初步緣由，進一步定位問題還須要具體的工具，也就是調試之『術』，如上文所述之斷點調試。有些時候，遇到靠相似 gdb（如 python 的 pdb）的工具沒法解決的問題時（如性能問題），你還須要更多的調試工具作 runtime profiling，如 systemtap。

　　使用標記語言來寫文檔，而非 word/power point

　　不要使用只能使用特定軟件才能打開的工具寫文檔，如 word/page 或者 power point/keynote。要使用『放之四海而皆可用』的工具。

　　java 的市場口號是：『一次編寫，處處運行』，對於文檔，你也須要這樣的工具。Markdown (md) / Restructured Text (rst)（以及任何編輯語言，甚至是 jade）就是這樣的工具。經過使用一種特定的文本格式，你的文檔能夠被編譯成幾乎任意格式（html，rtf，latex，pdf，epub，...），真正達到了『一次編寫，處處運行』。最重要的是，因爲邏輯層（文章自己）和表現層（各類格式，字體，行距等）分離，一樣的文檔，換個模板，就有徹底不同的形象。

　　除非必須，我如今全部的文檔都是 md 或者 rst 格式。

　　一切皆項目

　　程序員的全部產出應該項目制。軟件自沒必要說，文檔和各類碎片思想也要根據相關性組織成項目。舉一些我本身的例子：

• 個人博客是一個名叫 jobs 的 github 項目
• 個人微信文章所有放在 craftsman 這個項目中
• 我學習某種知識的過程（好比說 golang）會放在一個或若干個項目中
• 我工做上每一個項目的各類產出（包括會議紀要）會按照項目對應生成 git repo

　　項目制的好處是具有可回溯性。每一個項目我能夠用 git 來管理，這樣，幾乎在任何一臺設備上我均可以看到我以前的工做。想一想你三年前寫的某個文檔，你還能找到它麼？你還能找回你的修改歷史麼？

　　項目制的另外一大好處是能夠在其之上使能工具。好比說你看到的這些微信文章，我隨時能夠

make publish YEAR=2014

　　來生成包含了 2014 年我所寫文章的 pdf。

　　心態開放，敢於嘗試

　　在程序員社區裏，語言之爭，系統之爭，軟件思想之爭幾乎是常態。python vs ruby，go vs java vs erlang vs rust，scala vs cljure，OOP vs FP，iOS vs Android。其實無論黑貓白貓，抓到老鼠的就是好貓，facebook 還用 php 呢。程序員應該用開放的心態去包容新的技術，新的思想，敢於嘗試，而不是當即否認。這個世界最悲哀的是，手裏有把錘子，看什麼都是釘子（或者說，眼裏就只能看見釘子）。

　　我接觸 mac 時間不過三年。可這三年時間，我從對 mac 不屑，到深深熱愛，最終成爲 mac 的一個重度用戶。不少東西用過才知道，不嘗試不接觸我可能永遠活在本身下意識構築的無形之牆的另外一邊。

　　最近的兩年裏我學習了 erlang，golang，scala，還看了一點點 clojure 和 rust。目前我熱衷於 golang 開發，但並不妨礙我繼續擁抱 python 和 nodejs。每一個程序員要在不一樣的層級上有一門主力語言，好比說我：

• 系統級（realtime）：C （可能之後會是 rust）
• 系統應用級（realtime）：erlang（養成中）
• 系統應用級（非 realtime）：golang（養成中）
• 應用級：python
• Web 後端：python，nodejs，golang
• Web 前端：javascript
• 設備端：Android Java（暫無計劃）

　　這個列表你沒必要參考，我只是想用此來講明心態越開放，你看到的世界就越大