说明：非常抱歉，这周参加了太多的会议。原来写作也是需要心情的，当没有心情的时候，你都懒得动笔。 欧阳明来到云南的最主要的目的，是为了应对昆明客户要求的评标。就是客户邀请了几家资质还可以的公司，分别演示和讲解各自的系统，然后再进行评选。而这一次他们就是要进行讲标。欧阳明没有讲过标，这次也不是他讲，是当地的分支经理亲自上阵。分支经理名字中也有一个“琨”，因此人称琨哥，另外还有一个响当当的名号：“西南王”。是公司西南几个省市的市场负责人。 西南王不是盖的。至少讲标方面，欧阳明一行人都得好好学习。 讲标的前一天晚上，大家都还在进行紧张调试，做系统验证。大家的思路很明确，按照讲标的顺序，把系统完整演示一遍。过程中不允许出现任何错误。这个方法他们取名叫“主流程覆盖法”，后来一直持续使用下来。这个方法的最大好处，在于真正结合业务在进行验证，而不是单纯的功能验证，所以目标导向很强。但即使这样，系统也还是一直在报错。 “这个系统的框架太差了，必须进行改进！”欧阳明在旁边给冀扬他们打气，慢慢就聊开了。 “不如重写一个得了！”冀扬也基本同意他的想法，但更愿意自己写，而不是改写。 “嗯，重写一个是必然的，因为这个产品目前是拓展客户，还属于需求收集阶段。需求稳定后，必然会进行大版本升级的。” “那什么时候才可以升级呢？” “这个还得有点时间，目前关键是解决系统的稳定性问题。” “那得从那里着手呢？” “目前，影响稳定性的主要有两个方面：第一个是模块之间存在不必要的耦合，导致数据一致性常常存在问题。” “嗯，是的。” “第二个问题是，数据量大的时候的软件性能问题。常常出现大工程，系统就歇菜了。” “嗯，要解决这两个问题也很麻烦啊。” “是的，不过整体思路还是很明确的。耦合的思路就是解耦，用接口的方式，将模块独立出来，不允许模块对模块的直接引用。” “这个还好说，那性能呢？” “嗯，表面上说，性能问题很复杂，因为形成原因多种多样。不过针对咱们的系统，性能往往来源于大数据量的导入（到SQLServer）和服务端的数据获取。” “那又怎么样？”冀扬继续问道。 “就是说，我们第一解决好导入数据的模型，然后适时优化数据获取的SQL即可。”欧阳明这样解释到。 讨论还没有完，但是时间已经很晚了。为了更好的应对明天的讲标，大家都要好好休息。因此在最后一次流程正常走完之后，下班的命令被欧阳明下达了。 第二天，他们的讲标顺利吗？