打造可高效維護代碼的幾個原則
來源:http://blog.csdn.net/lezhiyong
1 問題
1.1 project
功能越來越多，邏輯越來越復雜。模塊越來越混亂、架構越來越復雜
常見問題：
1、模塊A發消息給其它模塊處理。B模塊-》轉發消息給C-》轉發給D-》轉發給A
2、初始頭文件功能定義清晰，越到後面裏面東西越混亂。
3、各模塊內反復實現基礎功能。
1.2 個人開發
1、對前人代碼：
不能理解前人代碼的思想，新功能自成一套體系。
造成大量反復代碼和反復變量。造成命名反復、沖突的函數、類與變量。
案例1：兩個iStartRecorder，僅參數不一樣。
兩個iStartRecorder，僅參數不一樣，但一個表示啟動錄制編碼器。一個表示啟動錄制server，依據兩個函數編寫時間，非常明顯這是後者不理解前人Recorder的含義而加入上的代碼。後把後者命名調整為iStartRecordService:
案例2：
對於下面的一個project：
以****Impl.cpp標誌的類。一個是繼承****類或者是****的創建者，本案例中須要從類實例化過程中非常easy體會到RssMgrlmpl、RssManager、CrssImpl之間的組合/聚合關系。
RssMgrlmpl：繼承rmManager，是接受到sip信令的實現，是RssManager的創建者。
RssManager：錄制任務的管理者
CRssImpl：是CRssAvRecorderMgr的創建者。
CRssAvRecorderMgr：是任務中ReCorder的管理者
當須要創建新類的時候盡量保持與前人思想一致。（無優劣之分時按加入的代碼量少數服從多數）
2、對自己代碼：
忌不遵從當前project所用的架構，使用自己熟悉的其它方式。
1、使用通用軟件規範和模式設計思想。
2、對有自己想法和創新的代碼做好標註，以便別人理解。
案例：
慎用遞歸架構 （遞歸函數）
一個視頻窗體中實現雙流視頻（標準流+低流），原來已經實現標準流
Class VideoCell//單路標準視頻處理邏輯
{
Public：
//視頻流接收函數
…
Private：
////標準流變量
}
Class WinVideoCell//windows視頻窗體
{
Public：
//windows對視頻窗體的操作方法
…
Private：
VideoCell m_videoCell;
}
Class WinVideoLayout//視頻面板
{
WinVideoCell m_arrWinCell[25];
}
遞歸方式實現：
Class VideoCell//視頻窗體
{
Public：
//標準流方法
…
Private：
//標準流變量
…
VideoCellm_LowFlowCell;
}
弊端：VideoCell的類函數調用假設控制不好，將陷入VideoCell函數遞歸調用的迷魂陣
標準實現方式：
Class WinVideoCell //windows視頻窗體
{
Public：
//windows對視頻窗體的操作方法
Private：
VideoCell m_videoCell;
VideoCellm_LowFlowCell;
}
3、其它常見問題：
數據都以 void * 形式傳遞。然後再造型為合適的結構
Switch 裏邊還有 Switch，這樣的嵌套方式是人類大腦難以破解的
2 幾個原則
2.1 唯一性原則
1、庫函數：僅僅在一個類中使用
2、相同的功能僅僅使用一個接口對外提供功能。
3、僅僅要是反復的東西盡量合並
同樣特征抽象成基類
同樣方法抽象成虛基類或同樣接口
同樣邏輯抽象成同樣函數
2.2 一致性原則
1、不同模塊中的語言與風格、信令結構、宏定義方式
2、分配和釋放資源的結構一致：在同一代碼結構層面上使用，同一個類中提供。同一個各cpp全局函數中提供。
2.3 對稱性原則
1、 命名對稱start-stop。init-uninit。
函數位置對稱
2、project結構對稱，了解一個project結構。其它project結構類似。
3、
3 怎樣做到
3.1 個人要求
1、對自己代碼：持續開發，持續改進
2、對別人代碼：從全局的角度理解前人代碼思想，未了解前保持現狀
3、別人到自己：規範的傳承
3.2 project要求
1、 頭文件看護，架構頭文件，專人看管，提交審核
2、 定期檢視與整改，將走錯門的代碼又一次歸隊，將違規的代碼糾正
3、 新人了解項目結構和頭文件
打造可高效維護代碼的幾個原則