Worse Is Better

最近做的几件事和最近刚读到这篇文章（http://www.jwz.org/doc/worse-is-better.html）让我重新认识了KISS和这个所谓的Worse-is-better原则。

软件是一个相当复杂的系统，哪怕仅仅是一个数百行的程序，也往往在运行时会出现很多不可预知的场景；作为程序员，我们总是想尽可能的保证所有的场景都能得到正确的处理，但这只能是一个美好的愿望：或者这个是类似于一个NP的问题，或者是我们自身能力有限。做超出我们能力的事还想把它做好做完美，那是绝对不可能的。就像俄罗斯轮盘赌一样，只有一颗子弹，不可能同事搞定两个赌徒。

程序员往往就是这个俄罗斯轮盘赌的操控者，时常纠结于把这颗子弹给谁。有些必要的纠结是必须的，当回过头来看，往往花费我们大量时间和精力的纠结发生在一些细枝末节的事上，而那些往往真正需要我们去考虑、权衡的地方却因为我们对问题本身理解的深度或广度，仓促的做了决定。我想很多人都会有和我类似的体会，例如我们常常会想某个功能是放在class A里面还是class B里面更合理？某个函数我们是让它返回boolean还是抛出异常。。。等等之类

这类选择往往并没有对错之分，就和我们日常中会碰到的很多小事一样；既然如此，我们何必需要耗费大量的时间和精力进行权衡呢？直接采用简单粗暴的方式可能和最完美的解决方法比起来会有这样或那样的不足，但它能节约你的时间和精力，让你能专注于更大更重要的事上，综合起来你能获得的回报可能会远远大于你坚持选择最完美方案所带来的回报。

另外一个需要坚持KISS和Worse-is-better做法的原因在于，我们对问题域的理解总是随着对问题的深入而越来越深入的（从时间和空间上都是如此）；我们在做选择时受限于当时对问题域的理解，很难真正做出最合适的决策。所谓的计划没有变化快，过多的计划往往会被证明为是没有任何益处的，我们过多的在对问题充分了解时做出所谓正确选择也是没有任何意义的：能容忍你的实现有些不足深证是bug也是一种能力和境界。

总之在系统设计和程序实现时，能尽量弄清楚那些是自己已经清楚的部分，那些是自己尚不能确定（从而只能做假设）的部分；在决策时遵从简单粗暴原则寻找一个次优的决策；在适当的时候能进行重构对自己当初的设计和实现进行修正（甚至抛弃），利用对问题域更多的理解来做出一个比你上次决策显得更好更合理的决策。