摘要

继续 如何提高程序员的生产率(一) , 除了 命令行 和 快捷键 外,我们在日常生活中还会遇到一些别的琐碎 的事情, 而这些事情通常就是决定一个程序员生产率高低的因素.

本文会主要谈 如何自动化, 编辑器的选择, 还有一些细节问题.

引入

如何提高程序员的生产率(一) 写完后, 有几位朋友的留言我仔细阅读了下, 觉得还是值得拿出来说说的.

路过的枫 提到的:

这些生产率的提高都是流于形式，能提高生产率的是如何带动员工的思考，并总结出自己的智慧。

从某种意义上说我是赞同这个观点的, 上篇和本篇即将阐述的内容多是一些实务性的东西, 它没有思考层面 能够产生的对程序员本身认知的提高(当然也与程序员本身有关,其实追求高生产率从某个角度来看也是一种哲学层面的东西),它只是一些能够在相同条件下节省时间的一些有益的帮助. 个人认为 这种小的细节上的提高.加以时间参数的放大,所带来的效应也不能低估的, 所谓 量变影响质变 是也.

那么,我还是继续我这些实务性的介绍.

自动化

不知道你是否使用过 subversion 来作为版本控制工具,是否遇到过这样的情形,就是现在你不想再使用 subversion 了 我想改用 git 或者 hg 这种分布式的版本控制. 于是一个问题出现了, subversion 为我们的项目中的每个目录 下都生成了一个 .svn 目录,里面有相关的svn信息, 而显然我们不想把这些无关的目录引入我们新的代码库中的.

我们决定删除这些无用的目录.

怎么删?

嗯,我笨,我用鼠标进入每个目录把每个.svn文件都删除了吧. 当然,这是没有问题的,

或者, 我看了你的上篇文章, 我想用命令行了, 于是你在进入每个目录 rm -rf .svn 进行删除. 恭喜你,你已经高效了很多.

不过,我们为什么不想着用程序去自动完成呢?

如果你在linux, 完全可以: find . -name .svn|xargs rm -rf 一个操作即可.

如果你在Win下, 这时候管道可能不好使(我查了下相关的资料, 目前没有找到合适的办法, 大致会是 dir /S | del , 但是 这个是不工作的, del接受不到管道来的数据).

于是有个办法了,我们写脚本吧, 一个简单的脚本如下(python):

import os
import shutil

curdir = os.path.abspath(os.path.dirname(__file__))

def removedir(dirname, name = ".svn"):
    if os.path.isdir(dirname):
        for file in os.listdir(dirname):
            if os.path.isdir(os.path.join(dirname, file)) and file == name:
                thedir = os.path.join(dirname, name)
                shutil.rmtree(thedir)
                print ".",
            else:
                removedir(os.path.join(dirname, file))

不过几行的命令, 但是这个脚本只要是装有python的平台都能够顺利运行成功, 当然win也不例外.

于是我们评估下这三种方法的生产率:

假设.svn的目录数是100个,我们假定所有的.svn都在二级目录下,也就是下面这样

project
   A
     .svn
   B
     .svn
   ...

这样一直有100个.svn目录, 那么 第一种情况, 操作数为:　(1次点击A目录+1次del键+1次回到上一目录)*100=200次鼠标操作+100次输入操作,

第二种情况, 操作数为:　(rm -rf A/.svn) + (光标向上+5次光标向右+1次退格+输入B)*99=13+8*99=805次输入操作

第三种情况, 我们以后者的脚本为比较对象(比较通用), 共计442个源码字符+10个左右的命令行字符=452个输入操作

假设, 每秒3次键盘输入操作, 1次鼠标操作, 那么,用时分别为:

第一种情况, 200/1+100/3=233秒

第二种情况: 805/3=268秒

第三种情况: 452/3 + 3*60 = 330秒

当然第一种情况还存在鼠标操作和键盘操作的切换时间, 第三种情况加入的思考算法的时间可能不准确(比较熟悉python的程序员应该不会超过3分钟).

从而,对于上面这种场景,我们得到的结果是:

第一种情况<第二种情况<第三种情况

你可能会说, 这结果怎么和你的论点是相反的, 或者你开始庆幸自己每次都是使用鼠标来干.

那么让我们来继续这个场景, 如果我们的项目变了,我们不再是100个目录,而是10000个.

第一种情况, 20000/1+10000/3=23333秒

第二种情况: 80005/3=26668秒

第三种情况: 10/3 = 3秒(因为我们的脚本第一次都写好了, 始终要记得DRY)

哇, 这种量级的差别可就不是一点半点, 在这种情况下1,2方式基本不可行.

你会很奇怪,为会什么第二种方法会这么差劲呢?

其实不然,请不要忽略了我们的假设前提, 是很简单的目录结构, 如果我们是有多级嵌套的结构,那么第二种情况会比第一种情况要好很多. 读者不妨自行估算下.

而随着新的类似需求的出现,自动化的力量和效率会愈加突显出来.

所以, 还等什么,赶紧反思下自己老做哪些重复的事情,是否可以写个脚本? 动手去写吧!

编辑器

作为程序员的你我, 无论你使用的是VS, Eclipse还是Emacs, VI 等, 你最主要面对的还是一个编辑窗口, 你需要向其中输入字符, 继而成为你工作的体现.

既然我们每天都在使用编辑器,那么编辑器当然会在很大程度上影响程序员的工作效率.

在这个论点上我不发表任何结论性的意见,我只是想从我个人的角度来分享下我的心得.

从大学开始学习计算机起, 用过VC, VS, eclipse, VI , 记事本等大大小小不下数十种的编辑器, 从启动速度和执行效率上来分, 基本上可以分为 重型 和 轻型 两种, 例如 VC, VS, eclipse这样的IDE可以归为重型, 而 VI , 记事本, Emacs(稍显重了些) 可以归为后者.

相比于重型的编辑,我更加青睐轻型的编辑器, 我个人是受不了漫长的启动过程, 占用过多的内存(影响其它程序的响应), 容易崩溃(越复杂 的程序当然越容易崩溃)等等.

那么,我个人是比较喜欢号称编辑器之王的 VI (如果你是第一次听说,那么不妨现在就开始学习吧,相信你一定会喜欢上的), 我们不去 讨论究竟和Emacs相比哪个更好(随便google vi vs emacs),我只想说说我喜欢 VI 的几点:

1. 轻便(启动速度,响应速度)
2. 多平台支持(无论是Win, LInux, 我都使用)
3. 解放鼠标(基本你不用去动鼠标,从而提高的生产率,请参考 如何提高程序员的生产率(一) 中的部分说明)
4. 强大的功能(只有你想不到,没有你办不到,如正则替换, 大量的提高效率的键盘绑定等)
5. 插件支持(如各种plugin, colorscheme, 如果你不了解这些名词,可以google之)

等等.如果你用过 VI 超过3年,你再回头看这篇文章时,你可能会会意的微笑,弃IDE而从 VI .

其实现在很多的软件也都是将 VI 作为光标导航的标准,如j,h,k,l四个键的作用等.

参考 VIM like tools and softwares Collection 了解更多 VI 相关的工具.

其它的细节

基本上如果你能够在这2篇博文中提到的几点注意起来, 会在实际的程序生活中大大提高生产率, 提高工作效率.

那么,最后我想简单说明几个比较重要的观点.

结论

在世界是平的的今天,程序员的日子也不好过了(呵呵,有如此多的程序员啊),而且 国内的技术氛围也不是太好(君不见国内过35的还有几个人coding而乐此不疲?), 如何不断学习,提高自己,我想是每个不甘于人后的程序员都要反思的.

欢迎交流. 

后记 

感谢OwnWaterloo的留言, 在Win下使用搜索然后手动删除也不失为一种好方法.

当然上面提到的svn的场景也只是一个例子, 我更加希望不要只就事论事,而是向更广的思考, 思考

如何能够自动化自己每日不断重复的琐事 ,从而提高生产率.

参考资料

1. 如何提高程序员的生产率(一)
2. VI
3. VIM like tools and softwares Collection

本文的rst源码

本文的源码链接在 这里 .

点击 下载pdf阅读.