Vim 开发 Rails 的那些坑

最近两个多月一直在用号称编辑器之神的 Vim 做着 Ruby on Rails 的开发。今天就来总结一下,讲讲我对文本编辑器、脚本语言的一些想法和遇到的坑。

  1. 麻烦的代码跳转,查看代码不方便。使用 IDE 的一大优势就是查看代码非常方便,Vim 这样的文本编辑器当然也可以使用 ctags 这样的插件支持代码跳转。但是只要你新加了一个方法,就要重新生成一次 tag 文件,你说麻烦不麻烦?

  2. 缺乏函数的outline(Vim 也许有这样的插件,只是我没有用到)。有的时候写了一个方法,过的时间久了你就忘了这个方法的存在。假设你开始写一个旧的项目,那么你每当要写一个新的函数的时候,你就要思索一下了,到底有没有写过类似的方法?总不见得每次都把相关源码重新看一遍吧!

  3. 鸡肋的代码补全。Vim 的代码补全基本靠猜,猜的策略大概就是根据你当前打开的页面中的关键词、过往的输入词频之类的,还是不能根据程序的上下文进行代码提示。我见过的比较智能的 IDE 比如 RubyMine,甚至能够对你的代码风格进行指导,在写的过程中就能提高你的代码质量。

  4. 快捷键的配置五花八门。Vim 的强大很多时候是依靠强大的插件功能和自定义配置文件。每个人都有自己的偏好和习惯,时间长了就固化了。不同人之间配置不同、操作习惯不同,那么无形中就给团队协作制造了一堵屏障。

  5. 静态语言的一大优势是在代码编写阶段就可以做类型检查,因此借助 IDE 就可以做到查看当前对象的可用方法以及使用说明。而写脚本语言则必须时常上网查看一下语言手册,冷不丁还可能遇到拼写错误。这些重复的行为和低级的错误一定程度上抵消了脚本语言带来的生产力优势。

说一些关于 IDE 和文本编辑器的话题。总有感觉很 Geek 的家伙会冒出来说使用 IDE 会让人变傻之类云云。但是我的观点恰恰相反,程序员的本职功能还是尽可能地解放出生产力,解决当前的业务问题。专注于业务本身而不是纠结这么些个细枝末节才是正确的态度。

一些观点认为:Vim 这样的文本编辑器的优势在于远程调试(例如 SSH 连接远程设备)的时候无法使用图形界面,而终端使用文本编辑器则不受影响。

但是我们有 Git

借助 Git 我们可以把远程的代码克隆到本地进行修改,修改完直接推送然后远程更新即可。使用 SSH 进行远程连接需要保证网络连接持续稳定,而使用 Git 只要求克隆和推送时两次连接的网络稳定即可!

历史证明编程工具总是向着以性能换取开发效率的方向演进。未来的程序员应该是 problems solver,而不是 coder。

“Vim 开发 Rails 的那些坑”的4个回复

  1. Integration with other plugins. If dbext.vim is installed, it will be transparently configured to reflect

发表评论