软件设计过程中的诱惑

 在软件设计的过程中，我们经常会面临这样的诱惑：

在工作过程中，突然出现了一个问题如鲠在喉，阻塞住了当前整个的工作进度，

而同时，你立刻能够想到一个快速搞定该问题的方案，这种情形下开发人员，很

容易就会受到快速解决问题的诱惑，快速地给出fix，然后继续推进到后面的内容，

维持那种开发过程中酣畅淋漓的快感。但是在开发过程中，不可避免会经常性地遇

到问题，如果经常性地给出快速的fix，到了一定的阶段，可能就会发现，现有的

系统处于一种补丁落补丁的状态，看上去不舒服，在这个不舒服的基础上作后续

的开发也很难受。如果一定要继续坚持维持这个不够好的设计，也许，最终产品

还是能够开发完成，但是它的扩展性，稳定性，可复用性，可修改性都会大打折扣

。

这种对问题快速给出fix的方式，在产品维护的阶段，尚可运用，当然前提是产

品本身的架构设计得足够好。但是在产品的设计阶段，在早期开发阶段，还使用

这种方式，则可能会带来较大的负面影响。

这样的体验，最近自己就有这一回。

最近一直在设计一个处理语意部分的evaluator，期间也遇到了不少问题。初始

给出的设计在后续的实现环节中发现有一些局限，但是 在实现的过程中因为过于关

注进度，也在一定程度上受到持续推进的顺畅感的诱惑，自己并没有停顿下来审视

原先的设计，而是稍作思考，给出一个快速的fix，能够解决当前的需要之后，就

继续进行到后续的开发中。虽然在编码的过程中，已经感觉到有些底层数据结构设计的

实在谈不上舒服，为了解决设计问题，引入coding trick的场景也不只一处，但

是身陷其中，并没有想过站起来，从更高的角度进行思考。及至代码基本编写完毕

，开始测试，暴露出一些bug，需要进行修改的时候，才更充分地体会到现有的设计

的局限性以及这种局限性给维护和扩展带来的开销。这样束手束脚地调试了差不多

一周的时间，基本功能倒是调通了，但是有些不爽的是，这种调通的感觉完全是建立

在调试经验之上的，刨开调试的经验和fix的一些bug，从流程上和框架上来看，自己

对现有的这个版本实现的品质并没有太大的信心， 简单来说，让自己闭上眼想一想，

现在的这个设计，这个实现，在品质上是不是达到了自己的要求，是不是在自己的控制

范围内，还是一件说不太清楚的事情。对于一个工业级的软件产品来说，这种控制感实

在是太虚弱了。考虑了一天，跟老大也沟通了一下，决定对evaluator进行重构。从底

层的数据结构的定义，到基本的流程框架，乃至具体的实现，几乎全部要作一番调整。

短期来看，这种调整会给进度带来一定的影响，但是在项目的初期阶段，对于根基性的

东西，还是值得花费较多的资源作精作细，这样后续的开发才可能有一个良好的基础。


P.S. 这段时间一个比较深的体会就是，当你感觉需要实现的某个模块过于复杂，条理

不是非常清晰，或是需要引入特殊的coding技巧来解决一个问题的时候，往往意味着更高

层次上的设计和架构潜伏着问题，所以这种时候，要控制住埋头实现复杂逻辑，引入trick

快速解决问题的冲动，缓冲一下，站起来，审视一下，是不是可以从更高的层次来简化问

题，给出更好的设计，消除引入特殊trick的必要性。