如何客观地衡量编辑人员的工作效率？
我不确定 Vim 是否比其他编辑器/IDE（例如 Eclipse）提高了我的工作效率。
但不知何故，当我使用 Vim 时，我有一种充满力量的感觉，并注意到尝试其他编辑器的阻力。
示例：一旦我在其他编辑器中看到一些很酷的功能，我就会想“Vi 可以做到这一点（我只需找到击键或配置插件）”
我如何对编辑器生产力进行基准测试客观地？
我理想的编辑器是： Netbeans 功能集和易用性，但具有 SublimeText 的性能和光滑的外观。
更新
Visual Studio Code 现在是我的主要代码编辑器。
Sublime Text 用于配置文件和快速编辑。
Vim 用于 ssh 会话或使用宏进行编辑。
I'm not sure if Vim makes me more productive compared to other editors/ide's like Eclipse for example.
But somehow I get an empowering feeling when using Vim and noticed resistance to trying others editors.
Example: As soon a I see some cool feature in an other editor I'm thinking "Vi can do that (i just have to find the keystroke or configure a plugin)"
How can I benchmark editor productivity objectively?
My ideal editor would be: Netbeans feature set and ease of use, but with SublimeText's performance and slick looks.
Update
Visual Studio Code is now my primary code editor.
Sublime Text for config files and quick edits.
Vim for ssh sessions or editing with macros.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您喜欢在 vim 中编写代码，那么仅此一点就是使用 vim 的充分理由。
如果一个工具能让你的工作效率提高 2%（根据一些研究），但你却不那么喜欢，那它有什么好处呢？ 我告诉你，使用你喜欢的工具非常重要！
If you like writing code in vim then that alone is a pretty good reason to use vim.
What good would a tool be that made you 2% more productive (according to some study) but that you didn't like as much? I tell you, working with tools you like is pretty darn important!
我还沉迷于 Vi 输入模型，我确信它会让我更有效率。
当我使用其他一些编辑器时，我感觉不舒服。 当我使用 Visual Studio 时，我确实需要 ViEmu，在 Eclipse 中我使用 viPlugin 等。
前段时间我是 Emacs 用户，现在没有 毒蛇。
然而，当您无需思考即可使用命令时，Vi 的生产力才真正体现出来。
因此，无论您使用什么编辑器，为了真正提高工作效率，编辑器必须成为您双手的延伸。
I also I'm addicted to the Vi input model, I'm sure that it makes me more productive.
I feel uncomfortable when I use some other editors. When I use Visual Studio I really need ViEmu, in Eclipse I use viPlugin, and so on.
Some time ago I was an Emacs user, now I can't use it without Viper.
However the productivity with Vi really comes when you are able to use commands without even thinking about them.
So, whatever editor you use, to get a real productivity gain the editor has to become an extension of your hands.
我想说这些症状是主观线索，表明您在 Vim 中的工作效率可能更高 - 对其他工具的挫败感可能是一个相当好的指标。
我可以非常肯定地说，如果您对 Vim 的了解足够深，以至于对其他编辑器感到沮丧，那么转换后的任何生产力提升都可能非常小。
I'd say those symptoms are subjective clues that you're probably more productive in Vim - frustration with other tools is likely to be a fairly good indicator.
I would say with a huge degree of certainty that if you're into Vim deep enough to get frustrated with other editors, any productivity gain from switching is likely to be very small.
为了客观地做到这一点，您需要一些可衡量的东西。
如果您有足够的空闲时间进行实验，我想您可以使用每个编辑器录制几个小时的视频，然后将您与每个编辑器战斗所花费的时间加起来......
To do it objectively, you'd need something measurable.
If you've got enough free time on your hands to experiment, I suppose you could video record yourself using each editor for a few hours then add up the length of time you spent fighting each one...
为什么不尝试几种不同的编辑器，看看您是否可以注意到它们带来的生产力提升。 如果您不选择最吸引您的那个，如果您这样做，您将需要决定生产力的提高是否超过您在使用 vim 时感受到的快乐。
您可能还想考虑针对不同框架/语言使用不同的编辑器。 我使用 vim 进行大部分 C 和 Perl 编程，使用不同的编辑器来处理重要的 Java 应用程序，使用另一个编辑器来进行 Rails 开发，但我还没有找到一个通用的编辑器。
Why not just try out several different editors and see if you can notice any productivity gains from them. If you don't then pick the one that appeals to you the most, if you do you will need to decide if the productivity gain outweighs the happiness you feel when using vim.
You might also want to consider different editors for different frameworks/languages. I use vim for most of my C and Perl programming, a different editor for non-trivial Java applications, and another editor for developing in Rails, I haven't found a one-editor-fits-all yet.
我建议简单地测量一下你的实际输出：
V。E。如果
V<E，那么另一个编辑器具有更好的生产力，否则 vim 是你更好的选择。请注意，最困难的部分是测量实际输出。 例如，一周的代码总行数或
diff输出的大小可能是糟糕的方法。 此外，结果可能是，在第一周你编写了一些简单的代码，而在第二周你试图修复一个非常困难的错误。 因此，您可能真正将一个工作周与另一个工作周进行基准比较，而不是一个编辑器与另一个编辑器进行比较。我想这可以归结为弄清楚您想要实现的目标，然后决定尽可能客观的衡量方法。 然后衡量哪个编辑器获得更好的结果。
我什至不会尝试测量编辑器的实际使用情况。 一个真正高性能的编辑器可以实现为 dd if=/dev/urandom bs=1M count=1 > code.cpp 但变化很大，导致生成的代码质量很差。 如果输出很好，没有人会关心你是如何发出它的。
仅当您无法长时间实际使用编辑器时，才应计算实际的编辑器使用情况； 例如，如果编辑器不断需要在键盘和鼠标之间切换，则您可能会出现 RSI 问题，尽管该编辑器在短期内可以提供最佳的生产力。
I'd suggest simply measuring your actual output:
V.E.If
V<E, then another editor has better productivity, otherwise vim is better choice for you.Note that the hard part is measuring the actual output. For example, total lines of code or the size of
diffoutput for the week could be poor methods. In addition, it may turn out that during the first week you were writing some easy code and during the second week you were trying to fix a really hard bug. As a result, you might be really benchmarking one work week to another, instead of one editor to another.I guess it comes down to figuring out what you're trying to accomplish and then deciding as objective measuring method for that as possible. Then measure which editor gets better result.
I wouldn't even try measure the actual editor usage. A really high perfomance editor could be implemented as
dd if=/dev/urandom bs=1M count=1 > code.cppbut the changes are high that your resulting code quality sucks a lot. If the output is good, nobody should care how you emitted it.The actual editor usage should count only if you cannot physically use the editor for long time; for example, if the editor constantly requires switching between keyboard and mouse, you might develop RSI issues despite the fact that in the short term that editor would provide the best productivity.