程序员的工具

程序员的工具2014-10-17 infoq 姚若舟

编码工具

编码本质上来说是一种以键盘输入操作为主的工作。因此，输入代码速度的快慢很大程度上影响了一名程序员的效率。我是通过以下手段来提高输入代码速度的。

键盘布局

很多程序员都不知道我们使用的键盘布局（就是指字母键，数字键和符号键的所处的位置）并非只有一种。绝大部分人使用的是标准键盘布局，也被称为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和快捷键的道理是一样的，就是为了让双手尽量少的离开代码输入区（字母键，数字键和符号键）。如此说来，使用键盘的“上下左右”键也会影响效率，因为这些键通常在键盘的右下角且离开字母键区比较远。

URL：http://www.bianceng.cn/Programming/project/201410/45938.htm

常用的开发环境一般对快捷键的支持都不错，除了预定义的快捷键之外，还可以自定义快捷键。另外，在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）。虽然说这个功能可以简化单元测试的编写，但是我使用后发现，如果大量使用数据驱动测试，会使得单元测试的可读性下降。原因在于数据本身不一定能表达测试和设计的意图，从而导致测试难以维护。