程序的健壮性是否该有一个度？

我想用项目里的具体例子来开始这次讨论。我自己的一个小项目。。。可以当成一个具有代码提示功能的编辑器。现在我要实现两个功能：
1, 按键序列的映射。例如 vim 风格的:
map ^X x
map ^X^A ggvGx
（这两个映射随便写的，没什么特殊意义。）
2，属性名称的智能补全, 像输入"string.l"时，提示:
string.length,
string.lastIndexOf

要实现这两个功能，在编程上需要一个数据结构，来搜集用户绑定按键序列（例如"^X", "^X^A"),或是对象的属性名称（例如"length", "lastIndexOf")。
有两个选择（哈希表被排除了，因为这里需要对字符串排序）：
1,普通数组。排序存储+二分查找。
2,AVL 树。

现在我的问题是，应该选哪一个？这两者的区别仅在于插入 /删除元素时，后者是稳定的，前者在 100 以内通常快，但会随着容量增加而线性变慢。

如果按照“量体裁衣”的原则，数组似乎是更好的选择，毕竟很少有用户绑定超过 100 个快捷键，也很少有一个对象的属性 /方法超过 100 个，即使超过，在 1000 范围内，速度都还是可接受的。

但问题是，如果有某个用户绑定超过 1000 个快捷键，或者某个用户的对象的属性超过 1000 个，甚至是一万，十万，然后他感觉到程序变迟钝了。那这是谁的错？我们怪用户的行为稀奇古怪，用户也可能觉得我们的程序不够“健壮”。毕竟，我们只需要简单的把数组换成 AVL 树，所有的问题都会消失。而且代价不算大，仅仅是代码稍微复杂了一些。
但如此一来，我们是不是过度的关注程序了健壮性呢？

希望听听各位在这方面的宝贵意见，也想听听大家若遇到帖子里的情形，会怎么选择。如果各位你能分享你在编程生涯中遇到的类似的设计抉择，那就更好了。

wenzhoou

2018-07-19 22:40:23 +08:00

首先，你是一个做刀的。你需要知道你的用户拿着你的刀去做什么，砍柴有砍柴的刀，闯江湖有闯江湖的刀。

恩。上面基本是废话。

针对这个具体的例子。做一个系统参数，默认用数组。用户可以指定为树。

当然也可以做成动态的，自己调优。

如果你还觉得，我一定只能做一个。那就去做用户调查吧。

kongque2016

2018-07-19 23:08:08 +08:00

@whileFalse 对，这种问题能得到用户的反馈最佳。发帖是想听听大家的经验，感觉大家在工作中应该遇到过类似的情形。我阅读过 zsh 和早期 vi 的源码，在这个问题上，前者用 hash 表（它的排序方式我没细看），vi 用的就是简单的链表。可见不同程序员对“健壮”的理解也是不一样的。

kongque2016

2018-07-20 00:36:56 +08:00

@doubleflower
嗯，要高效的编辑大文件，通常要牺牲掉处理常规文件的一部分性能，而且代码量和复杂度会增加不少，就因为弊端明显，反而容易做取舍。我这里用 AVL 树的话，额外引入的代码量和复杂度是有限的，毕竟 AVL 树在项目的别处有用到，函数已经链接进来了，有种“不用白不用”的感觉。而用的好处是明显的：不用考虑用户习惯什么的，一了百了。

loveour

2018-07-20 10:14:04 +08:00

如果是面向大众的，还是尽量优化下吧，但是也要权衡，我觉得先采用简单办法，但是预留接口以后优化比较好。
优化也得注意方式，有个大概是在某种情况下反向优化的例子，某个看图软件，似乎在打开文件夹内一张图片的时候会预先缓存文件夹内其他图片的信息，估计是为了优化切换图片什么的速度，但是，我有一些超过 1W 张图片的文件夹，打开其中一个图片软件就会卡死，我觉得这个就是反向优化了。说实话，打开图片慢一点，切换慢一点，我觉得也能忍。