如何勸說上級更新 GCC 和 VS 的版本，並把項目遷移至 C++11？

01-12

老大說所有的庫和編譯器不能升級。說是為了穩定性。各位大神怎麼看？

放棄吧，別說C++11了，就算你升到C++1111111，你那些豬一樣的同事還是會把它當作C with many bugs 用。

你老大說的沒錯，我們寫代碼可能會使用大量隱式轉換，編譯器特性等，如果後續這些編譯特性變化，可能會隱藏bug。對於穩定性要求高的，應該需要回歸測試。大項目成本太高。你可以說服你們老大，新項目採用新的版本。

被三體星人鎖死了技術的公司，你還是跳槽吧。

我妄自猜測，對你老闆來說，把這種技術債務拖給幾年後接手項目的人去還，最符合他的利益。雖然不一定最符合公司的利益。

到時候他或許跳槽了，或許高升了，不用再為此負責。

重構也是同樣的道理，你花兩天時間把代碼結構理順，結構更清晰，將來開發更有效率，維護成本更小，代碼更易讀，對新人也更友好，這都是對公司有利的。但你老闆卻覺得你鼓搗兩天沒幹正事，沒有做 feature，影響了項目進度，有可能推遲上線日期，影響他的季度獎金……

我廠是3.4.x的g++我會亂說？

你的老大成熟穩重……

自己都說不出遷移帶來的優勢，為什麼要升級，人家是背著可靠性KPI的。

如果代碼只在某個特定版本的編譯器上穩定，那恰恰說明代碼其實寫得不穩定。

如果代碼只在某個特定版本的庫上穩定，那恰恰說明用了不該用的 Hack。

當然以上只是版本升級，C++11 的話，本身還是有若干處和傳統 C++ 不兼容的地方的。

升級容易，測試難。

不是把代碼拿到新編譯器上面編譯通過就好，要從新跑所有的測試，不然半夜三點出了bug你去公司改？

你寫兩遍，然後就會發現vc++2013比2008編譯出來性能免費提高百分之六七十，然後給老闆看

老大多半是對的。不作死就不會死。

這事能不能成取決於你們自動化測試的程度

升級了有什麼好處？有什麼壞處？

你不如想怎麼自己坐到你老大位置上，然後再想自己怎麼背這個坑

我們公司已經升級到VS2012了還是沒人用STL

java 8都出來還有一大片工廠用 java 6呢，說是為了穩定，其實就是懶

如果你想推動，我建議你做以下事情：

1、搞清楚現狀。現有的工程現狀是什麼，適不適合升級？到底是不是有風險？如果有風險要怎麼解決？

2、說清楚收益。也就是為什麼要升級，升級以後有什麼好處

3、你來主動負責。你告訴你老大，如果要升級用什麼步驟來做，怎麼測試，如果出現問題如何回滾。

你要做到這幾點，我相信說服你老大的概率是很大的，

對於大工程來說，升級的風險確實有，工作量可能也不會小，

不可能隨便誰在茶餘飯後頭腦一熱的說一句「我們升級吧」，整個項目就跟著升級。

新項目，老代碼修改的，因為某個依賴的東西不能用低版本編譯，只好換高版本編譯器，並且正在苦逼處理依賴庫……，媽蛋，今天加班加到半夜，處理了十多了依賴庫了，找到合適版本，沒有合適版本的改代碼，做patch，現在感覺是在作死，媽蛋要是弄一星期還沒解決所有依賴的編譯問題，又遇到什麼奇葩的殺手級的坑，那我就去跳樓了。

現在是兩頭怎麼變都會有問題，似乎已經沒有回頭路了，只能向著新版本進發。

According to IBM, the five biggest migration risks are:
1. Technical risks—Is this the right system or technology? Will it work with the applications and data we already have? Do we need special tools and can we get them?

2. Unpredictable costs—Can we do this within the existing budget? How are we funding this? Have we correctly identified all the associated costs? Does it deliver a positive ROI?
3. Scheduling concerns—When will we make this change? How much will it disrupt operations? What is the best time to undertake this? What are the risks of waiting?
4. Skills and culture issues—Can our people operate and maintain this system? Have we lined up the necessary outside experts? Have we planned for additional training? Are we prepared to manage this change?
5. Operations risks—Do we have a contingency plan? Do we have a test strategy? How do we ensure it will deliver the expected performance and reliability levels? What are we forgetting?

Five Big Risk Areas of Technology Migration

根本不要匿名，百度是3.4.5，有時都快絕望了

你的項目有足夠的測試嗎?

如果沒有項目由於依賴於特地版本的某些特性而出了莫名其妙的問題對你的項目有什麼好處?

到了性能瓶頸最穩妥的是平行擴容而不是折騰這些東西。