该不该接这个烫手山芋，代码合并

Question

目前公司有两套系统A和B，B糸统开始是从A所在分支拉的新分支，随着B糸统的不断迭代，A、B两套系统差距越来越大，某一天，领导突然要求将B糸统的代码合并到A系统中，目前大致梳理了两套系统的差异点，但不知道具体的功能点，写代码跟合代码也是两波人，而且A系统生产环境还有重要客户在使用(经常被这个客户投诉)，大家都觉得没法做，但领导始终要求进行合并，认为B系统只是私有化版本，A系统才是基线版本，B系统的功能在A系统都应该有。
大伙觉得这事应该怎么办，有碰到过这种情况吗，大伙可以说说想法交流一下，优秀回答我会适当打赏。

Answer 1

“B系统只是私有化版本”
这个认识是完全正确的
但是正说明A系统的功能不能满足私有化定制的需要，所以只能改动源码来适应需要
B系统改动的部分是针对B客户的需要，把它放到A系统中，是不可能适应A用户需要的
如果只是单纯的合并代码，完全是画蛇添足的行为
真想好好打磨A系统，那就要仔细去观察B系统到底做了哪些定制化的修改
然后在A系统中将这些功能实现，而不仅仅是复制代码
否则早晚还会有个客户C，定制化一套C系统出来
将来还会有DEFGHIJK系统，无穷无尽
这不叫迭代，这就是小作坊式的开发，每个用户一套单独的系统
-=-=-=-=
举个简单的例子
A用户希望主页背景是红色的
B用户希望主页背景是蓝色的
按照小作坊式的开发，它们的源码都写死了红色或蓝色
如果仅仅按照领导字面意思merge一下，那你将拥有两个主页文件
但是实际上你应该增加一个后台管理功能，可以随时修改配色，甚至自己上传背景图片
-=-=-=
这条路当然是不那么好走的
但是正路一般来说都不好走，因为它是通向山顶的路
看起来好走的路都是下坡路
-=-=
最后，如果这个产品想要推广，想延续生命，那必定是要整合功能，升级迭代
整合的是功能，不是代码
那么你自己是否愿意接这个项目，最终还看你有没有能力接
有能力接就接，有多大本事干多大事，不要勉强