一個維護了數年的龐大的C++ codebase如何一步一步增加testcase，讓項目工程化，可靠。？

01-26

提了一個比較大的問題，想討論一下這樣的code如何改進的問題。
一些現狀：
1. 這是一個圖形渲染相關的項目，有的改動影響到性能，如果不能及時覆蓋到測試，短時間也看不出來。
2. 項目里有大量的單例，依賴關係含糊不清。
3. 項目里有多種編碼風格，還有很多legacy code。

4. 項目橫跨iOS，Android，H5三個平台，並且還有Lua，JS binding。
以上任何一點拿出來都比較棘手……
想聽聽各位資深開發者的意見，先謝過。

建議把你的項目中觀察到的問題，分而治之，雖然問題可能比較多，有些問題也很棘手，但是也別希望有人給你方案讓你一夜之間就解決所有的問題。

作者是來吐槽cocos2dx的？

這一般沒啥好辦法，幾點建議:

1. 試著把業務邏輯的代碼和非業務邏輯的代碼隔離。見過一些code，會把一些utility class散落在業務邏輯的各個角落，當把這些utility class abstract 出來，第一可以充分測試這些utility class, 第二業務邏輯的code 看上去會更清楚

2. 如果沒有強烈的理由，不要試著發明一種新的coding style,盡量把已有的幾種coding style 統一

3. 老的code通常會用一些自己的類似std::string, std::thread的實現，如果可行的話，可以試著提換成c++11/14的實現，這樣也可以減少一些code

4.最重要的是一定有足夠的unit tests

5. 還有在重構時，一次只能重構一個方向，千萬不要幾個方向一起重構，這會大大加大重構的難度，和code review的難度

接受過多個垃圾項目的來怒答一發

首先不要重寫，不要重寫，不要重寫

除非你有高出你們公司一大截的實力不然重寫大概率只是又寫出了一坨垃圾代碼

根據你的描述，之所以變成這樣一坨的原因很可能是不斷更改的需求導致整個系統沒有好好設計

所以在你沒有對整個系統了如指掌之前不要動手去改代碼。

把代碼劃分出模塊補齊大致的UML圖

這部分工作費時費力但是可以幫你把整個系統的架構理清楚

順帶可以發現過去沒有來的及填的坑

在時間許可的範圍內可以一做，具體做到多少詳細可以根據具體情況來決定

如果你劃分好模塊就可以搞明白到底哪個模塊問題比較多。按模塊設計爛的程度排序。然後先給最爛的代碼按重構的原則重新劃分函數，第一步可以不改任何邏輯，只是把命名統一，第二步嘗試把重複的代碼歸一，第三步考慮哪些重寫哪些繼續用，這裡可以開始一個個函數加入unit test。

非常浩大的工程。

我記得看過一本書裡面也有類似的問題，這本書里的答案是----趕緊跑路

對了，書名程序員的吶喊

一：不擇一切手段往死里砸錢，通過資金和人員強行維護。

二：放棄代碼，重新開發。

C++其中一個缺點就是對開發者的能力要求很高，如果一開始沒有建立好適合C++的代碼組織結構和規範以及軟體底層基礎庫和整體結構設計，那麼很快就會使代碼腐爛以至於不可維護。

一般來說，「察覺出一個C++項目代碼開始龐大混亂需要維護時」，其實已經錯過了可維護期。

三：保留一部分，重構一部分。看上去很美，但重構的那部分和原有的代碼容易出現衝突，不久又會回到混亂狀態。

四：保留核心和底層基礎C++代碼繼續維護。其他代碼全部放棄，改用其他語言。例如Blender，外圍是屁眼通寫的。很多遊戲引擎/框架都是好例子，C++只用於核心/底層基礎，其他都靠腳本。

「跨越三個平台，有lua，有js」，那就對了。把lua/js的使用範圍擴大，讓原本C++做的盡量用這些外圍語言做。lua/js正好就很適合做這些實際業務/膠水/雜項的事，就像python。

」跨

建議拉個開發分支，按照功能模塊切成多個微服務，服務化運營

自底向上提取必須的代碼（放到另外的目錄結構中，但還在一個repository)， modernize, 加測試,perf測試. 這其中會發現很多沒有用的代碼，刪； utility/tools/scripts 整理好。過時的class考慮用新的標準和github開源項目
如果需要重構核心框架
如果需要重構各個組件

我覺得題主並不是想改進這個東西

而是想直接重寫。