[FZH] 被Abiword 坑了一下

[Qian Hong]

2014-05-05 16:36 GMT+08:00 Szopen Xiao <chopins.xiao at gmail.com>:
> 既然BUG处理很困难，那么对于条件有限（开发人员有限，时间有限）的项目，应当向开发者建议减少项目功能与特性，减少程序复杂度，降低BUG出现风险，而不是天天解决BUG

做加法容易，做减法难。

假设abiword有三个用户：
A说，砍掉支持那么多格式的功能，我只要支持doc就好，我只要支持中文就好！
B说，砍掉那么多语言支持，我只要支持英文就好，支持越多格式越好！
C说，我用abiword编辑xxx格式很多年了，绝对不要砍掉这个功能！

开发者听谁的？

这里有一个误区是，以为减少功能特性真的能减少bug，实际情况却很复杂，没有量化的证据能证明减少功能一定能减少bug，也没有量化的证据能证明相反的观点。

可以做一个思想实验，看看减少功能是否真的一定能减少bug：假设abiword砍掉了二十多种格式支持，只支持一种格式，那么中文支持会不会自动变好呢？如果没有中文用户/开发者参与开发和测试，那么我认为少几种格式支持并不会让中文支持自动变好，因为原来的开发人员和测试人员仍然不懂中文，并不会因为格式支持少了，他们就自动懂中文了。（但是，有可能因为格式支持少了，他们有更多的时间陪伴家人，这是好事）

我举一个没有办法量化的佐证，试图证明增加功能和减少bug并不是矛盾的。
以Wine项目为例：
几年前，Wine项目不支持ActiveX控件；几年前，Wine项目中文字体乱码问题非常严重（累计有十几个不同的bug引起不同条件下的乱码）；几年前，Wine项目几乎没有中国开发者。
2010年，Wine开始支持ActiveX控件，为了解决网银的问题，我开始给Wine项目报bug，后来报了太多bug，遭到了报应，转变为一名Wine开发者自己面壁修bug，而我最早修复的几个bug都是中文乱码的问题。在这个特例上，“增加功能”吸引了“更多用户”，“更多用户”意味着“更多潜在贡献者”，”更多潜在贡献者”最终帮助完成“减少bug”这个目标。

你可能觉得这是个特例，不过我认识的其他开源开发者朋友，大部分也有自己的一段从用户转变为开发者的故事，这类故事一般都不违背“增加功能”-“增加用户”-“增加贡献者”-“减少bug”这样的套路。

一个更有说服力的例子是编译器。如果把支持的语言算作功能特性，把支持的平台算作功能特性，那么功能特性越多的编译器，核心功能的bug会越少，因为功能越多用户群越大，越多人参与测试bug就越容易得到暴露，恰好编译器的用户群又有不小的几率能转变为临时/长期的贡献者。

举这些例子，并不是为了证明“减少功能特性能减少bug”是错的，也不是为了证明“增加功能特性能减少bug”是对的，只是为了说明：事情往往没有一眼看上去那么简单。






-- 
Regards,
Qian Hong

-
http://www.winehq.org