太可怕了，一個項目竟然由三個團隊同時寫了三套代碼！

太可怕了！一個項目三套代碼，你們見過這種事情嗎？所謂的三套代碼，不是一套一套重構出來的，而是正在開發中的項目，由三個團隊同時開發，哪個團隊事先開發出來就用哪個團隊的，至于剩下的兩個團隊，大概率是要全部開掉的！這是什么操作呢？

我們公司有個項目，開發過程極其困難，耗時半年，但是項目組長一句：“剩下的功能還需要半年”，徹底把老板給惹毛了！而事實是怎樣的呢？

其實項目組長說的沒錯，目前的項目代碼只能應付客戶，幾乎所有的業務代碼都是在著急忙慌的情況下寫出來的，里面的坑多得很，再加上很多代碼邏輯需要優化，客戶很多需求需要補充，UI也需要優化，想要完全放心得交給客戶使用，不花個半年左右的時間重構，那肯定是不行的！

當項目組長跟老板說接下來需要花時間好好重構代碼時，老板不愿意，因為項目進度還得往前推，不重構的話，一兩個月就可以把項目糊弄過去，重構的話就遙遙無期了，現在說是半年，到時候再推遲個一兩個月，黃花菜都涼了！

所以，老板說：“你們繼續往前趕，我找人去重構代碼！”

研發組長雖然不愿意，但是奈何老板比較堅定，所以研發組長也拿老板沒辦法。

但是，接下來老板的操作，直接把研發組長看傻了，老板先是招了一批人，去重構現在項目組的代碼，結果發現好像新來的那批人的效率也不咋樣，搞了兩個月連項目都沒跑起來。

于是，又招了一批人，這已經是第三波人了，最開始沒想著要搞第三套代碼，只是想著人多力量大，幫第二波人打下手。

結果老板中途又接了另外一個同樣的項目，眼看人手不夠了，把第三波人安排到了那個項目里面去了，因為第二波人還沒讓項目動起來，所以就讓第三撥人在最開始的項目組代碼基礎上直接繼續開發。

所以，就有了現在三套代碼，看著是不是挺可笑？但是這種事情就是在現實中發生了！于是，就出現了以下矛盾。

第一個矛盾在于最開始的項目組，我們就叫項目組A吧，項目組A的成員對于老板的安排很有意見：“什么意思？覺得我們代碼不能用，所以要重構？重構完了那我們干啥？”，而且，每個團隊的代碼風格都不一樣，代碼思想也不一樣，即使重構完了，項目組A也不可能再去重頭研讀和理解第二波人下稱項目組B的代碼，最后的結果可能就是被全員放棄。

所以，項目組A的成員開始出現了消極態度，他們覺得反正最后寫出來的代碼都不會被公司使用，干脆就愛咋咋地了唄！

再看項目組B，項目組B本來就是臨插一腳，老板認為前期該踩的坑項目組A都幫他們踩過了，所以給他們的研發時間是壓縮過的，所以項目組B的成員壓力巨大。

實際上，項目組A的“成功經驗”項目組B吸收不了多少，因為項目組A本來就很忙，根本就沒有多少時間去跟項目組B去討論項目細節，所以項目組B只能通過看項目組A開發的代碼去理解項目，所以進度非常慢，而老板又不懂這些，所以對他們的進度很有意見，所以，項目組B很憋屈。

再看第三波人，也就是項目組C，他們才是妥妥的大冤種，不光要像項目組B那樣去通過代碼理解業務，而且還要往前推進第二個相同的項目。項目組A踩過的坑他們要踩，項目組A沒踩過的坑他們同時也在踩！

而且，因為三個項目組搞得是同一個項目，但是目前環境就一個，所以調試項目還得排時間，經常為了搶調試機會而爭得面紅耳赤！

關鍵是，老板也有自己的小心思，因為現在三個團隊都很危險，因為雖然現在是兩個項目同時在進行，但是所有東西都是一樣的。

對于這三個團隊來說，現在他們是競爭關系，誰先把項目搞好，其他兩個團隊就沒有了存在的意義，最好的結果就是留兩個團隊，最差的結果就是一套代碼復制粘貼到另外一個項目里面去，其他兩個團隊的代碼棄用！

代碼都棄用了，團隊還有存在的意義嗎？

結語

不得不說，老板的小算盤打得噼里啪啦響，搞得大家人心惶惶，我現在很懷疑，估計搞到最后三個團隊的代碼都寫不好，而且很容易出現第四套和第五套代碼！

說起來理由很簡單，這種項目壓力和三個團隊的競爭壓力下，很難保證這三個團隊有人撐不住而離職，而團隊的核心成員一旦離職，就會產生雪崩效應，演變成團隊集體離職。

到時候老板勢必會再招一撥人來接手他們的代碼，此時，以很多程序員的性格，多半可能還是會選擇重構代碼，所以，就會出現第四套、第五套甚至更多套代碼。

想到這里，細思極恐啊！