1.为了赶进度，无法拒绝客户提出的需求，需求修改后没有严格的测试，程序又不稳定，客户又照样拿程序做借口，这就像一个死循环。
2.改程序不怕，怕的就是不稳定。
一家医院已经上完线，程序也基本稳定，但在使用的过程中又提出了一些个性的需求，而程序员正在修改另一家准备要上线的医院的需求，而两家医院的需求不能统一，为了解决目前的困难就只能加参数控制，改完后，因为上线的医院很急，再加上也没有正式的测试人员，所以马上发给准备上线医院使用，升级后却发现以前很多没问题的功能现在反而不能使用了，又只能把问题提交回去给程序员，程序员收到这些以前没有的问题的问题，调试发现根本就是实施人员有个脚本没有升级或某个参数没有设置正确，很恼火，由于实施人员回答说问题都已经解决，客户以使用发现又有这么多问题，虽然新的问题已经解决，但老的问题又出现了，客户就拿这个程序不稳定来推脱上线！已上线的医院照样升级后发现N多问题，非常恼火的提交上去，程序员刚收到问题，现在又来问题，更是恼火，而火焰并没有就此熄灭，而是即将发展为缭然大火。
出现这种情况根本问题，第一，需求做得不到位，为什么两家的需求这么不同，而且为了上线而迎合客户什么问题都改，一改，一个稳定的版本一下变得遥遥欲坠，这是开始，如果能从开始上抑制，那后面的问题也就不存在了。第二，经过第一关，有些需求确实挡不了，那就只能改咯，问题是改完以后一定要经过严格测试，缺少测试那就只能让客户帮你测试咯，客户测试出问题那就引发的不是简单程序上的事了，所以有测试人员封住了第二关的话，后面的问题也就不会发生了。第三，测试人员通过测试没有问题就直接发给客户还不行，因为很多问题的产生并不是程序本身的原因，而是一些配置的正确等，所以必须有人为配置程序，发布版本把关，这样到实施人员手里，到客户手里基本就问题不大了。
总结起来三点：
1.需求控制
2.加强测试
3.完善配置
上面提到了增加参数来解决不同医院不同需求的问题而版本统一的问题，觉得单纯增加参数来控制只会使本来复杂的系统变得更复杂，无法控制，项目做得越多，当然程序的修改、测试和配置起来就越来越困难，人员的工作量就只会越来越多，扩展到一定程度肯定会出现一些疏忽，而疏忽的必然导致客户的不满，所以我们必须解决参数与版本控制这个根本问题！要解决这个问题，第一，可以减少参数的个数，没有参数当然就没有问题了，而参数的来源就是不同客户的需求，如果我们能和这些客户一起讨论约定好一些需求的分支，基本上我们程序就可以不必加参数可以直接写入代码，所以这就是最近的一个理念“约定胜于配置”，这也是程序员积累出来的经验，配置虽然灵活，但灵活过度就回演变为灾难，那为什么不事先把那些可能无法用到的配置给约定写死起来。第二，虽然“约定胜于配置”解决了参数灾难问题，但还是存在参数，版本问题还是存在，当同时在一套代码上修改两个客户不同需求的难度肯定大于两套代码每套修改一个客户代码的难度。因为我们要时刻担心着会不会影响不需要这个功能的客户，对测试配置等后面的人员也都加重了工作量。用参数来控制也有其他的好处，编写功能可以不用重新编写，如果以后客户需要这个功能我们只要打开这个参数就行了，而不需要重新开发一遍。就是多套代码的话，相同功能可以要改多次！但一套代码的话，版本控制就会变得非常死，同一个模块，可能两个人都要修改，那肯定就要排队，如果更多的人一起修改的话，这个排队就会更长，排队就会浪费时间不够灵活。但多套代码的话，整合代码就变得艰难，如果公司需要一个最新的版本出去打单，肯定就需要功能足够强，而很多功能都是分散在不同的代码里面，就需要发时间一套套分析，最后好不容易整合了，但其稳定性又是问题，又需要发时间测试，所以多套代码也是不好。总之一句话，灵活不简单，简单不灵活。
怎么才能做到现场开发的时候很灵活，而整合版本的时候又简单了？我是找不出有什么完美的方案，所以我只能够找一个折中的办法，就是增加一点点灵活，减少一点点简单！上面的灵活与简单都是一个长期的问题，我想花一定的时间把程序分成两部分，一套核心代码与多套外围代码。现场修改的一般都是外围代码，这样就加大了开发的灵活性，整合版本的时候因为核心代码只有一套，就只要整合外围代码了，降低了风险。外围代码的功能最好能统一管理起来，这样在修改某问题时可以先查询一下以前有没有解决过这个历史问题！
核心代码的整合并不是很容易，首先是边界的确定？这必定需要一个有经验的业务高手来协助区分。再就是接口的制定，外围代码以何种形式接入到核心代码？数据库表结构与实体的合理设计，添加一个字段减少依赖？
总结一下关于参数和版本控制的两点：
1.“约定胜于配置”
2.提取核心代码