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

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

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

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

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

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

摘要

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

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

Contents

引入

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

路过的枫 提到的:

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

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

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

自动化

不知道你是否使用过 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 的几点: