软件参数配置项是否越多越好

如果问软件是否需要个性化,很明显需要——因为软件天生就是个性化的服务。如果把软件的工作参数认为是实现个性化的工具,那么真的需要很多参数。软件一般分类通用软件与应用软件,通用软件提供基础服务,比如OS,比如Database;应用软件面向具体的应用,一样又可以细分为很多种类。应用软件又可以简单的分为专业软件与消费类App,专业软件需要专业的知识,而消费类App一般门槛很低,上手即用。所以当我谈到App是否需要配置很多参数时,实际想说的就是软件的准确定位问题——它面向谁,它是否需要向用户提供某些可配置参数;这些参数是否可以为它的主要用户服务;它的用户是否需要这些参数。

回到我的工作上来,一款仪器控制软件,提供基因测序服务,它是否需要更多的可配置参数。这么说还是很笼统,再具体一点:如果一个用户购买了此款基因测序软件(实际是购买了仪器设备),他们是否需要设置某个串口的波特率?是否要设置平台的运动速度?

如果我是一个用户,我会立即回答我不需要。我购买的是测序服务,你让我设置波特率干嘛?我只需要可靠的测序服务。波特率与测序服务的可配置性联系不到一起,它只是一个开发调试参数而已。一旦这些设备组合为一台测序仪时,这些设备的个性(参数)对用户来说就没有了意义。

如果你用过Windows Mobile手机[1],你可能会有点感觉。Windows Moblie是很早的一代与诺基亚塞班进行竞争的智能手机操作系统,它与Windows xp系统具有很大的相似性,它提供了很多可配置功能。Windows Mobile拥有控制面板,可以对很多硬件进行个性的专业化设置。与如今的安卓与IOS系统,你能在手机里改变蓝牙的速率,改变某个口的波特率吗?

          

COM 是什么?调制解调器又是什么?IOS傻白甜会知道?有没有觉得很无语?用到的频次与频率又有多少?

我没有想说明就是因为如此Windows Mobile才失败了,我提起这个系统,是想说这是与现在手机系统截然不同的两种风格。这种差异与我和团队中其他成员对待可配置参数的态度有很大的相似性。这是针对可配置参数的两个截然不同的出发点:

  1. 一些成员:所有可能需要配置的参数必须可配置,即使现在不用,但还是可以能会用到;即使以后不用,现在也会用到;用户需要更改不同的参数,以测试设备的效率。
  2. 我:能少则少,我们需要为用户提供最佳的设备效能;我们设置的或者选定的参数必须是最优的。

我不认为我的看法比其他人的好,也不认为他们比我的好,这只是看问题的两种方向。他们心中的用户是应用研发、测试、以及最终用户,他们给着用户无比巨大的自由,付出的代价是需要维护整个参数可配置系统。我只考虑了软件的消费者,终端用户,系统通过临时方案来测试出最佳参数,然后提供给用户。很明显,这个方案牺牲了一些应用研发用户在后期的可配置型——而我认为后期仪器已经稳定,此阶段已经不需要再通过更改这些极度计算机专业或者电子专业的参数。仪器软件有很长的硬件调试、测试阶段,或许第一种观念更好,但我们是否应该为此付出巨大的努力?比如一套联网的参数系统,同步,即时生效以及各种模板?

或者,是我们的可配置性定位存在问题。研发阶段应该是研发阶段的开发与测试逻辑,而面向最终用户的消费级产品应该是另一套逻辑。我们的产品定位为消费级服务,而在研发过程中,确是为仪器设备以及建立在仪器设备之上的服务测试、验证而服务,这叫造成了我今天的困惑。如果是研发定位,我支持更多的参数配置。但还是应该关注参数的变化频率,僵尸参数还是应该被忽略的。

参考:

[1] Windows Mobile回顾, http://tech.sina.com.cn/mobile/n/2010-11-08/05301556339.shtml 

原文地址:https://www.cnblogs.com/jjseen/p/5763224.html