程序員的工具

　　編碼工具

　　編碼本質上來說是一種以鍵盤輸入操作為主的工作。因此，輸入代碼速度的快慢很大程度上影響了一名程序員的效率。我是通過以下手段來提高輸入代碼速度的。

　　鍵盤布局

　　很多程序員都不知道我們使用的鍵盤布局（就是指字母鍵，數字鍵和符號鍵的所處的位置）并非只有一種。絕大部分人使用的是標準鍵盤布局，也被稱為 QWERT 鍵盤（以左手上方那排字母鍵命名的）。但是很遺憾，這種布局的設計初衷其實并不是為了提高打字速度的。

　　我大概從一年多前開始學習使用一種叫做“Dvorak”的鍵盤布局。使用這種布局輸入同樣一段文字時，手指在鍵盤上的移動距離要比標準布局減少 至少 50%。在轉到 Dvorak 布局之前，我使用 QWERT 鍵盤有 20 多年了，但是我實際只花了大概一個多月的時間來完成鍵盤布局的切換。當然，在這一個多月的時間里，我每晚都堅持練習打字一小時左右。

　　其實，我現在使用的也不是標準的 Dvorak 鍵盤，而是一種叫 Programmer Dvorak 的鍵盤布局。這種布局在標準 Dvorak 的基礎上，根據程序員的需要對數字和符號鍵的位置及輸入方式做出了調整，目的就是提高程序員的輸入代碼速度。舉例來說，使用 Programmer Dvorak 布局輸入數字時，需要按 Shift 鍵，而輸入符號（如()， [], {}， =）時則不需要按 Shift。寫代碼時輸入這些符號的次數顯然要遠遠超過數字，這種變化對速度的提升效果不可忽略啊。

　　根據網上找到的研究資料表明，Dvorak 布局對輸入中文同樣會提升速度。程序員每天畢竟還是有不少時間會花在其他事情上面（上網找資料，聊天，寫郵件等等），這些需要打字的事情效率提高了，同樣有幫助。

　　代碼編輯方式

　　相信很多程序員都聽說過“Vi”這種文本編輯方式吧。可以說“Vi”就是為了編碼而設計的，比起使用記事本那樣的編輯方式要高效很多。我在所有 的開發環境中（如 Intelliji 和 Sublime）都會安裝 Vim（Vi improved）的插件。Vim 可以快速定位，查找和修改代碼，另外還有很多非常強大的編輯功能。要學習 Vim，除了網上查資料之外，還可以通過游戲（http://vim-adventures.com/）和挑戰（http://vimgolf.com/）來練習。

　　當然，我并不反對使用 Emacs，只是自己還沒有時間學習，無法給出評價和比較。不過，網上有關 Emacs 和 Vim 孰優孰劣的討論，我都是無視的。

　　開發環境和快捷鍵

　　編碼時，我會盡可能使用快捷鍵，盡量不用鼠標。編碼時使用鼠標，可以說是程序員的效率殺手。因為使用鼠標時程序員的一只手就會離開鍵盤，導致輸 入代碼的間隔加長。其實，使用 Vim 和快捷鍵的道理是一樣的，就是為了讓雙手盡量少的離開代碼輸入區（字母鍵，數字鍵和符號鍵）。如此說來，使用鍵盤的“上下左右”鍵也會影響效率，因為這些 鍵通常在鍵盤的右下角且離開字母鍵區比較遠。

　　常用的開發環境一般對快捷鍵的支持都不錯，除了預定義的快捷鍵之外，還可以自定義快捷鍵。另外，在 Eclipse 和 Intelliji 中有如 mousefeed 和 key promoter 這樣的插件，他們會在程序員沒有使用快捷鍵的時候給出提示，或者提醒程序員為一些使用到但沒有對應快捷鍵的操作設置快捷鍵。

　　我鼓勵程序員根據習慣來設置自己順手的快捷鍵，不要拘泥于開發環境預定義的那些。遇到自己的快捷鍵和預定義的沖突時，如果預定義的操作并不使用 或很少使用，可以果斷解除原有設置，使用自定義快捷鍵。而要熟練掌握快捷鍵并沒有什么竅門，堅持在編程練習和工作中多使用就可以了。去背誦那些快捷鍵手冊 是沒有什么用處的。

　　我目前主要的開發環境是 Intelliji 社區版（針對 Java 和 Scala）和 Sublime（其他語言或者工具，如 Ruby， Python, PLSQL, Robotframework 等等）。他們都是免費的開發環境，可用的插件很多。

　　敏捷工程實踐相關的工具

　　上面提到的編碼工具對效率的提升都很直接。下面我將要提到的工具，和程序員如何來寫代碼和設計代碼有關。

　　單元測試框架

　　測試驅動開發（TDD）是我推崇的編程和設計方法，可以幫助程序員寫出簡潔和設計合理的代碼。而 TDD 中產生的單元測試，通常是用某個單元測試框架（UT 框架）來運行的。UT 框架這個工具并不是 TDD 所必須的，因為編寫和運行測試本身并不復雜。不過使用了 UT 框架之后，可以簡化單元測試編寫，運行和組織，對于測試的維護和管理還是有幫助的。

　　我使用的 UT 框架包括 JUnit（Java），Scala-test（Scala），RSpec（Ruby）等等。有些 UT 框架提供了一些強大的功能，在使用這些功能時要小心，因為用得不好可能會影響單元測試的可讀性。舉例來說，很多 UT 框架都提供了數據驅動測試的功能（Data Driven Test）。雖然說這個功能可以簡化單元測試的編寫，但是我使用后發現，如果大量使用數據驅動測試，會使得單元測試的可讀性下降。原因在于數據本身不一定 能表達測試和設計的意圖，從而導致測試難以維護。

　　重構工具

　　重構指的是在不改變代碼行為的前提下改善代碼的設計，它是測試驅動開發中的重要一環。以 Java 為例，Eclipse 和 Intelliji 都提供了很好的重構工具支持，可以大大減少重構的工作量。不過，在使用重構工具之前，程序員應該很清楚為什么要做某個重構（如發現了代碼臭味），以及要使 用哪種重構方法。有些稍微復雜一點的重構（如移動方法），因為開發環境對其支持有限，無法通過工具來實現時，就需要程序員手工來完成。實際上，我建議每個 初學重構的程序員一開始不要使用工具重構，而是手工重構代碼。這樣對于學習如何小步重構，在重構中如何讓測試失敗的時間最小化，都是很有幫助的。

　　由于代碼的復雜性，有時即使是看上去很安全的重構（如重命名），因為重構工具還不夠智能（不同開發環境的表現也不同），還是可能出現修改之后的 代碼發生了行為上的變化。因此，即使使用工具來重構，也需要有測試來確保代碼原有的行為沒有發生變化。切不可因為使用了重構工具，就在不寫測試的情況下面 對代碼進行修改。

　　Mock 框架

　　Mock 框架指的是在單元測試中使用的那些用來隔離被測代碼依賴的工具。還是以 Java 為例，Mock 框架其實很多，如 EasyMock，JMock，Mockito 等等。和 UT 框架及重構工具類似，使用 Mock 框架可以簡化在單元測試中隔離依賴的工作，避免手工寫隔離代碼的麻煩。同樣和重構工具類似，我建議初學 Mock 的程序員先不要使用這類框架，而是手工來隔離被測代碼的依賴并做相應的驗證。我遇到過很多會使用 Mock 框架的程序員，不會手工寫 Mock 的代碼。究其原因還是他們并沒有理解在測試中到底要如何來隔離依賴，以及要如何來做驗證。

　　有些 Mock 框架（如 PowerMock）過于強大（比如可以隔離一些靜態或 final 方法），我并不推薦使用。原因在于隔離依賴的目的是讓被測代碼的設計更加合理。如果在單元測試中要為被測代碼隔離一些靜態或 final 方法，那么用 PowerMock 固然很方便，但是這樣做會讓程序員忽略代碼可測性差的問題。在這種情況下，只做到為了寫測試而去隔離依賴是不夠的。程序員應該考慮是否先調整代碼的設計， 使得測試更容易寫，并且依賴更容易隔離。實際上，如果改善了代碼的可測性，一般的 Mock 框架也就夠用了。

　　自動運行單元測試的工具

　　我最早是不用這種工具的，因為通過手動運行單元測試（使用快捷鍵）體驗到測試驅動開發中的測試失敗和通過，是實踐和練習 TDD 非常重要的一步。后來習慣 TDD 之后，我嘗試了一個叫 infinitest 的工具（Eclipse 插件），可以在保存代碼的時候自動運行受影響的單元測試。一開始感覺不錯，但是我試用了一段時間之后，發現這個工具運行測試不太穩定，經常莫名其妙的出問 題，而且有時還會運行很多不相關的測試。

　　其實，在 Eclipse 和 Intelliji 中可以定義一個重復運行上一次單元測試的快捷鍵。只要恰當的設置，也可以做到一鍵保存代碼并運行測試的效果。而且，這樣還可以選擇需要運行測試的范圍，避 免運行那些無關的測試。所以，這類自動運行單元測試的工具，我現在不推薦使用。

　　小結

　　上面介紹了不少與寫代碼和設計代碼相關的工具，相信大家已經發現了這類工具的一些共同之處。首先，使用這些工具前要明白相應實踐的目的和原理。 其次，即便工具可以提高效率，以手工的方式來實現代碼仍然是一種很好的學習方法。最后，現在很多工具都存在過度開發的問題，通常是因為忽略了它們自身所服 務領域實踐或原則的本質目標。因此，在使用這些工具時，程序員要學會取舍，真正做到讓工具“為我所用”，而不是“為了工具而工具”。

　　編程語言

　　最后，我想說“編程語言”對程序員來說也是一種“工具”。我覺得討論編程語言的孰優孰劣沒有任何意義。我一直很反對網上各種有關語言好壞的所謂 論戰，程序員為什么只能學一門語言呢？如果你不會一門編程語言，你就無法理解那種語言解決問題的思維模式。我覺得一個程序員至少要學一門面向對象語言，一 門函數式語言，以及一門動態語言，不然他的人生就是不完整的。可惜的是，我看到過很多程序員都只會一門編程語言（其中 Java 居多，而 Java 則是我見過“語法和語言特性”最弱的一門主流語言了），更有甚者還會鄙視或者拒絕學習其他語言。對于這樣程序員，我只想說“雖然你手上有一把榔頭，但這不 表示世界上所有的東西就都成釘子了”。

　　時至今日，很多語言都在相互學習和滲透。.Net、C++和 Java 陸續支持 Lambda 表達式（函數式編程）就是一個很好的例子。我非常喜歡函數式編程中的一些語言特性，如不可變量，高階函數等等。這些特性都可以幫助程序員寫出更加簡潔和可 讀的代碼來。另外，嘗試一下多語言編程，是件非常有趣的事情。我最近就試過用 RSpec 來測試驅動開發 PLSQL 的代碼。說到底，項目或產品開發時，使用的編程語言也應該是“浮現”出來的。哪種語言解決問題最有效就應該用哪個。

　　有些程序員說學語言要忌“多而不精”，這點我很贊同。不過，對于“精通一門編程語言”的定義，每個人的理解不盡相同。我自己的定義是（以 Java 為例），熟練使用所有可以簡化代碼的語法，以及熟悉基本類庫的使用（比如數據類型和集合類型），其他一些類庫可以視需要再學習。另一方面，我覺得沒有必要 強求“精通”了一門語言之后再去學下一門語言。畢竟對語言的精通程度是和你在練習和工作中使用這門語言的時間長短有關的，而且語言本身也是一個不斷發展的 東西。通常抱有這種想法的程序員，只是為了逃避學習新語言找借口罷了。

　　總結

　　程序員的工具遠遠不止我上面提到的這些。很多開源的技術框架和工具軟件，我覺得都應該算進來。好的程序員其實都很“懶”，因為他們總是想著把復 雜繁瑣的事情變得簡單快捷，可以花更少的時間達到同樣的效果，所以他們選擇了一些“工具”來提高效率。同時，好的程序員也很清楚使用這些工具背后的原因， 只會根據需要來選擇合適的“工具”，不會“為了工具而工具”。對我來說，如果使用工具可以幫助提高工作的效率，就會考慮使用或試用。反之，如果降低效率， 則堅決不用。如果提高效率不明顯，則要慎用并要持續關注效果。

　　要用好工具都離不開練習和工作中的不斷使用，希望本文可以幫助程序員找到合適自己的工具，從現在開始，從“我”做起，為了提高效率而努力。

                    <span id="shareA4" class="fl">                          </span>