蛋疼的维护和开发

    公司内部平台二期开发完了，已经进入了维护期，可是规划的功能还有一些没有做，而且开发完的东西，拿到业务部门中去用时，肯定业务部门会提很多需求和bug。 
   为了在后续发补丁包时，不把新功能加上，弄了一个维护分支和一个开发分支。维护分支主要是对于业务部门提出的需求和bug进行修改，而新功能的增加是在开发分支上弄。弄了两个分支后，矛盾就出来了。假设一个接口或者实现类，为了增加新功能，而修改了代码；然后了，维护分支里也对该接口或者类做了修改。最后维护分支和开发分支合并，同步代码时，那程序员不是累死了。少的几十行代码，多的上百行代码，而且极有可能会出现功能倒退。我们发补丁包的一个重要原因就是为了防止功能倒退，只发修改后的类（不过我倒是极度的怀疑，用户是怎样升级的，因为第一次发平台功能时，是用jar包的形式）。 
    把问题向上级反映，没有结果。仔细想想能不能把开发分支和维护分支合并起来了，个人觉得是可行：
    第一，以目前人力来看，每个人都维护一个大的模块，维护和开发90%是同一个人（因为现在人少得可怜）。 
    第二，发的补丁包里可以包含新功能，但是只要不影响老的功能，这需要程序员把测试用例先写好，每次在发新补丁时，都跑一遍测试用例。如果都跑通了，说明没有什么问题，跑不通再具体分析。 
    额，怎么有点像测试驱动开发的方式，看来要好好研究一下？ 
    突然想到业务部门是怎样维护自己的产品线的了？一个产品做好了，拿到客户那里去，肯定会有个性化的需求，难道多个客户，会在主分支上建立多个分支？