posted by wap, platform: HTC Bravo

为了vim蛋痛过两回，最后还是放弃了。说真的，哪怕是高负荷的编码工作，瓶颈也绝对不在打字速度上。随便一个像样的编辑器比如ultraedit，甚至免费的notepad++和text wrangler，至少都能实现98%你会用到的功能。另外2%的功能即便能用vi实现，但这种不常用的功能你也不会记住，还是要当场查文档，测试。一圈搞下来往往发现比暴力解决花的时间还要多。

这是个人经验之谈了。奉劝lz：life is short, play more

对我而言，如果在code review时发现雷同代码出现三次，基本上就是个很好的重构信号。绝大多数代码应该是有意义而且不重复的。如果是语言相关的框架性代码，那么visual assist之类的intellisense工具已经可以减少绝大多数重复性劳动，无需自己去做过多编辑器的定制工作。

当vi出现的时候，其理念是两手不用离开主键盘就能完成几乎所有操作。在当时，多数项目都是一个程序员坐在电脑前敲出几千行代码，vi可以几乎完美的达到这个目标。可如今这样的机会是越来越少。开发时需要cross-reference的内容不再仅限于unix的man或者有限的api，而是google，stackoverflow，wiki，UML，mindmap甚至outlook。对于一个有一定复杂度的项目，程序员生成代码的速度实际上是非常有限的，往往平均一天不超过一二十行。编辑器的效率在开发效率中已经不占太大比重。

posted by wap, platform: iPad

引用:

原帖由 @henvelleng  于 2011-3-13 16:15 发表
不是雷同代码，而是类和模板相关的框架性代码，填充各种属性方法，再调接口把这些对象推入链接符号表中或是链表之类的数据结构上或是单纯地填充方法函数。举个形象的例子就是不停的填写各种不同要求的申请表格，把自 ...

看起来是需求不同。对我而言，平时写代码时需要同时参考或者试验的东西太多，填充框架代码的机会太少，所以输入效率影响不大。

你描述的这种场合我也遇到过几次。如果框架工作量大的话，是否直接做个代码生成器会更有效一点？我遇到类似情况一般都选择生成代码了。手写太累，也容易出错。如果以后框架接口有改动，改改描述文件重新生成一遍就解决问题。描述文件自己一般也有大块适合生成而不是手写的内容，不过一个简单的正则表达式转换工具就可以适应大多数情况。

posted by wap, platform: iPad

完全理解。不过，就这种情况而言，是否能找到现有的开放源码实现？在一个现成的基础上修改，比重新发明轮子会更有效率也更有趣。