IDE二三事: 性能差是一种美德, Bug是一种Feature

性能差是一种美德

ReSharper已经成为.Net开发必备工具. 其贴心的功能和快捷键设计让coding过程可以行云流水般随心而动. 可最近在客户这边写代码时却总是磕磕绊绊, 只因ReSharper变得奇慢无比, 之前从来没感觉ReSharper这么慢. 原因很简单: 类太大了. 一个.cs文件普遍在4000~5000行之间, 而partial class被大量使用, 通常一个完整的class大约横跨3个上述规模的.cs文件(据客户开发人员介绍说也是因为太大才用的partial class).

开始的几天真是很折磨. 对于比较熟悉的修改, 以前通常Alt+Enter按下去后可以直接再按一下Enter选择第一个选项.可这边直接再按Enter的话就真的回车了, 因为Alt+Enter后ReSharper需要很久才能分析完把选项show出来, 在此过程中居然还会显示一个浅黄色的tooltip说"Analyzing...". 之前从来没见过这个tooltip.

最后的结果是我们把类按职责拆了, 虽然我们本来的目标也是重构. 因此性能差此时是一种美德, 为了好的开发体验, 可以迫使开发者调整代码的结构. 希望ReSharper不要修复这个问题.

甚至ReSharper可以改变它的license model: 按可以打开的文件大小来收费. 只需打开200行以下文件的可以很便宜, 行数越高收费越高, 让你真切的体验一下技术债的现世报.

Eclipse CDT 在打开大文件时有提示, 估计很多人没见过那个对话框. 当时是在另外一个客户那边见到的. 不知道JDT有没有.

Bug是一种Feature

有一次和客户的开发者一起用Visual Studio(忘了哪个版本)调试一个C程序, Step into 一个函数的时候, 发现光标到了第2000多行, 可那个函数的定义明明在6万多行, 2000多行处完全不搭界. 试了几次都这样. 在调试别的函数的时候也有类似情况. 后来试着猜了一下, 可能Visual Studio内部用16位的short类型来保存调试时光标所在的行数. 当行数超出65536时, 它就溢出了, 回到开头了. 随便一想, 没有去仔细求证. 如果是真的, 倒也是一个不需要修复的bug, 应该是一个feature, 还是考虑一下怎么把文件弄小吧.

--IDE 不应该提供粘贴拷贝功能