代码改变世界

如何提高程序员的生产率(二)

2009-11-13 12:42  Tower Joo  阅读(3412)  评论(37编辑  收藏  举报

如何提高程序员的生产率(二)

本博客所有内容采用 Creative Commons Licenses 许可使用. 引用本内容时,请保留 朱涛出处 ,并且 非商业 .

点击 订阅 来订阅本博客.(推荐使用 google reader, 如果你的浏览器不支持直接订阅,请直接在 google reader 中手动添加).

点击 下载pdf阅读 (如果浏览器不支持直接打开pdf,请点击右键另存).

摘要

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

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

引入

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

路过的枫 提到的:

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

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

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

自动化

不知道你是否使用过 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篇博文中提到的几点注意起来, 会在实际的程序生活中大大提高生产率, 提高工作效率.

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

过犹不及

在生活中注意去高效的思维和高效的工作,但是不要"过"了,这里所谓的"过",是指诸如你绑定了100多个快捷键, 你事无巨细都写脚本来完成,你收集和学习所有的捷径(甚至在应该去完成工作时)等等等等.

合理的度是,你能够自如,感觉舒适地应对,也无需特别刻意地去将自己的效率达到所谓的最高.

合理判断

有时候自动化一个东西并非是最经济,最高效的方法,在完成一个工作之前你先花2分钟在脑中评估下(有 GTD 的意思了, 呵呵),

你可以问:

  1. 这项工作后面还会遇到吗?
  2. 这项工作可以自动化吗?
  3. 如果要自动化,得有多少时间投入?
  4. 这个时间预估,我能接受吗?

明确这几个问题后,我想无论是自动化或者手动都会是合理而高效的.

结论

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

欢迎交流. 

后记 

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

 

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

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

本文的rst源码

本文的源码链接在 这里 .

点击 下载pdf阅读.