太可怕了，一个项目竟然由三个团队同时写了三套代码！

太可怕了！一个项目三套代码，你们见过这种事情吗？所谓的三套代码，不是一套一套重构出来的，而是正在开发中的项目，由三个团队同时开发，哪个团队事先开发出来就用哪个团队的，至于剩下的两个团队，大概率是要全部开掉的！这是什么操作呢？

我们公司有个项目，开发过程极其困难，耗时半年，但是项目组长一句：“剩下的功能还需要半年”，彻底把老板给惹毛了！而事实是怎样的呢？

其实项目组长说的没错，目前的项目代码只能应付客户，几乎所有的业务代码都是在着急忙慌的情况下写出来的，里面的坑多得很，再加上很多代码逻辑需要优化，客户很多需求需要补充，UI也需要优化，想要完全放心得交给客户使用，不花个半年左右的时间重构，那肯定是不行的！

当项目组长跟老板说接下来需要花时间好好重构代码时，老板不愿意，因为项目进度还得往前推，不重构的话，一两个月就可以把项目糊弄过去，重构的话就遥遥无期了，现在说是半年，到时候再推迟个一两个月，黄花菜都凉了！

所以，老板说：“你们继续往前赶，我找人去重构代码！”

研发组长虽然不愿意，但是奈何老板比较坚定，所以研发组长也拿老板没办法。

但是，接下来老板的操作，直接把研发组长看傻了，老板先是招了一批人，去重构现在项目组的代码，结果发现好像新来的那批人的效率也不咋样，搞了两个月连项目都没跑起来。

于是，又招了一批人，这已经是第三波人了，最开始没想着要搞第三套代码，只是想着人多力量大，帮第二波人打下手。

结果老板中途又接了另外一个同样的项目，眼看人手不够了，把第三波人安排到了那个项目里面去了，因为第二波人还没让项目动起来，所以就让第三拨人在最开始的项目组代码基础上直接继续开发。

所以，就有了现在三套代码，看着是不是挺可笑？但是这种事情就是在现实中发生了！于是，就出现了以下矛盾。

第一个矛盾在于最开始的项目组，我们就叫项目组A吧，项目组A的成员对于老板的安排很有意见：“什么意思？觉得我们代码不能用，所以要重构？重构完了那我们干啥？”，而且，每个团队的代码风格都不一样，代码思想也不一样，即使重构完了，项目组A也不可能再去重头研读和理解第二波人下称项目组B的代码，最后的结果可能就是被全员放弃。

所以，项目组A的成员开始出现了消极态度，他们觉得反正最后写出来的代码都不会被公司使用，干脆就爱咋咋地了呗！

再看项目组B，项目组B本来就是临插一脚，老板认为前期该踩的坑项目组A都帮他们踩过了，所以给他们的研发时间是压缩过的，所以项目组B的成员压力巨大。

实际上，项目组A的“成功经验”项目组B吸收不了多少，因为项目组A本来就很忙，根本就没有多少时间去跟项目组B去讨论项目细节，所以项目组B只能通过看项目组A开发的代码去理解项目，所以进度非常慢，而老板又不懂这些，所以对他们的进度很有意见，所以，项目组B很憋屈。

再看第三波人，也就是项目组C，他们才是妥妥的大冤种，不光要像项目组B那样去通过代码理解业务，而且还要往前推进第二个相同的项目。项目组A踩过的坑他们要踩，项目组A没踩过的坑他们同时也在踩！

而且，因为三个项目组搞得是同一个项目，但是目前环境就一个，所以调试项目还得排时间，经常为了抢调试机会而争得面红耳赤！

关键是，老板也有自己的小心思，因为现在三个团队都很危险，因为虽然现在是两个项目同时在进行，但是所有东西都是一样的。

对于这三个团队来说，现在他们是竞争关系，谁先把项目搞好，其他两个团队就没有了存在的意义，最好的结果就是留两个团队，最差的结果就是一套代码复制粘贴到另外一个项目里面去，其他两个团队的代码弃用！

代码都弃用了，团队还有存在的意义吗？

结语

不得不说，老板的小算盘打得噼里啪啦响，搞得大家人心惶惶，我现在很怀疑，估计搞到最后三个团队的代码都写不好，而且很容易出现第四套和第五套代码！

说起来理由很简单，这种项目压力和三个团队的竞争压力下，很难保证这三个团队有人撑不住而离职，而团队的核心成员一旦离职，就会产生雪崩效应，演变成团队集体离职。

到时候老板势必会再招一拨人来接手他们的代码，此时，以很多程序员的性格，多半可能还是会选择重构代码，所以，就会出现第四套、第五套甚至更多套代码。

想到这里，细思极恐啊！