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

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

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

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

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

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

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

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

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

。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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