用户的业务规则应该保存在用户哪里

    在管理软件中，为了某个用户的需求，我们经常会写入一些if else，来针对不同的用户需求做出处理。这样的处理，可以很快见效，因为用户的需求可以很快的得到满足，但是这犹如慢性中毒，这种类似的代码积累的越多，软件病得越厉害，时间越久，越接近不可救药。
    因此，管理软件编写的原则是，不要在程序中写入业务规则，业务规则与用户有关系，既然与用户有关系，那么就应该保存到用户哪里，由用户自己管理，这符合面向对象的原则，而且用户可以管的很好，因为它们可是某个领域的专家，我们不是，我们给用户管理业务规则，只会给用户造成不变，而且给自己添乱。
    用户购买了一个软件，它把需求告诉我们，我们在软件中给它实现了，在当前的状态下，用户可以使用，而且效率很高，但是这是一个高速变化的时代，一切都在改变，你想不变都不可能，用户的业务规则一定会变化，这是必然的。当发生变化时，用户的处理办法是告诉软件公司：我们希望把软件调整一下，需要进行这样这样这样的修改。除去商务谈判的部分，和中间反复的沟通沟通再沟通，当最终用户的目标达到之后，已经过去了一个周、两个周，甚至更长的时间。这个周期就严重影响了用户自己市场应变能力，用户的损失是无形的。
    我们看看从用户提出需求，到需求得到满足，这个过程之中我们做了什么：
    1、最终用户某个部门经理或总经理，或某个工程师，技术人员，管理人员，提出软件系统要进行调整，然后提交给信息管理部门，并且要给信息部门经理进行一些简单的解释，为什么要进行调整。
    2、信息部门有个人员跟软件供应商联系，向软件供应商的客户服务人员解释，他们的需求。
    3、客服人员会通知工程部门经理，工程部门经理再通知开发部经理，某某客户的软件系统要调整。
    4、开发经理安排有关开发人员处理该用户的需求。
    5、开发人员与客户信息部门进行联系，与对应的业务部门进行联系，甚至到现场进行交流，最后完成一个系统调整的方案。
    6、方案审核通过之后，由开发部安排对软件进行修改，由于开发人员都很忙（可能还需要针对其他的用户进行修改，或修改BUG），开发了一个周的时间，然后提交测试。
    7、测试很顺利。
    8、给用户安装。如果顺利的话，皆大欢喜，如果用户感觉不满意，需要进行第一次回炉，如果还不满意，需要进行第二次回炉，......。直到满意。
    9、OK。用户的需求终于得到满足。

    这个是一个比较常见的过程。我们从中可以看到，用户选择了一套管理软件，那么他们的业务就或多或少的被绑定到了这套管理软件，如果软件公司把用户的业务规则写到软件代码中了，那么就更加糟糕：用户的业务的再发展被绑定到了软件公司了。多么可怕，一个销售公司的业务发展，竟然被一家软件公司给制约了，是不是很冤枉？内在的原因在哪里？
    因为软件开发商把用户的业务规则写到软件代码里了，这些代码只有软件供应商可以维护，最终用户任何业务的调整，只有通过软件公司实现。
    好的解决办法是将用户的业务规则从代码中分离出来，保存在用户哪里，由用户自己进行调整，这样，当用户的业务要进行调整，那么它自己调整即可，而不是求助于软件公司。这样就不会出现那么复杂的过程了。用户面对快速的市场变化，可以快速做出反应。
    软件公司也和轻松，他们只需要维护干干净净的软件系统即可。