咨询下一个技术问题：如何做到定制版本的敏捷性开发

[oneFresh]

一个项目在多个局点部署，主体流程是一致的，但是每个局点又略有不同，导致现在的代码加了各种开关，导致圈复杂度增加，维护难度极度不堪，虽然提升了B格（一套代码，各地安装），但是作为底层维护的屌丝，还是想从根本上解决这个问题。

请问各位大神有没有此类经验，分享借鉴一下呀？如何敏捷开发定制版本，减少维护量，以及减轻新员工的熟悉难度

[唐家文]

建议把软件不同部分变成可配置项，通过配置文件的变更来打开或者关闭某部分功能，再用配置管理工具如puppet来管理不同服务器的这个配置文件。

[以专业开发人员为伍]

首先，这是一个设计问题。如果靠Copy+Past代码、然后写一堆Switch分支判断，这种做法，首先就是“设计上垃圾”造成的难以维护。 而敏捷开发的好处，就是随时可以对系统进行底层大规模重构，因为有“测试驱动技术”保证你们将设计重构进行到底，你应该能够感到“勇气”的存在。如果没有勇气，那么你一定没有进行真正的敏捷开发。 其次就是，在产品的分解和运维方面，应该也是测试驱动开发的！当一个产品的主程序不变（也不停止），但是其内部加载的模块却在主程序运行过程中动态加载和替换时，特别是当你通过一个服务器将这种变化的模块推送给其它一堆服务器时，你应该现在测试环境的至少2、3台服务器上测试过几百次了（用1分钟至少就能测试100次）。如果没有这个技术，那么先认识清楚“自己到底有没有真正做到敏捷开发、敏捷运维”吧！

[以专业开发人员为伍]

“作为底层维护的屌丝”，你还想“从根本上解决这个问题”？那么我认为这是不切实际的。 从长远来看，我认为一个团队是不需要什么专职维护人员的。这个说法可能会“得罪”一些手工维护人员“。但是如果你能够把这种理念植入开发团队中，你们的开发团队所发布的软件版本的某个层次（服务器主程序）能够把运维模块当作系统自身的一部分来开发和调试测试，那么问题才可能“从根本上解决”。 没有决心去解决，或者“智慧跟在开发人员屁股后边”去空谈“解决问题”，永远无法解决运维上的被动局面。

[以专业开发人员为伍]

智慧跟在开发人员屁股后边 --> 只会跟在开发人员屁股后边 其中最为关键的，是对产品“设计”进行重构。而许多团队由于技术层次问题而做不到这一点，只会在各种细枝末节上堆砌各种网上的免费“外部解决方案”。因此才容易陷入泥潭。