来源:http://blog.csdn.net/lezhiyong
1 问题
1.1 工程
功能越来越多,逻辑越来越复杂,模块越来越混乱、架构越来越复杂
常见问题:
1、模块A发消息给其他模块处理,B模块-》转发消息给C-》转发给D-》转发给A
2、初始头文件功能定义清晰,越到后面里面东西越混乱。
3、各模块内重复实现基础功能。
1.2 个人开发
1、对前人代码:
不能理解前人代码的思想,新功能自成一套体系。
造成大量重复代码和重复变量,造成命名重复、冲突的函数、类与变量。
案例1:两个iStartRecorder,仅参数不一样。
两个iStartRecorder,仅参数不一样,但一个表示启动录制编码器,一个表示启动录制服务器,根据两个函数编写时间,很明显这是后者不理解前人Recorder的含义而添加上的代码。后把后者命名调整为iStartRecordService:
案例2:
对于以下的一个工程:
以****Impl.cpp标志的类,一个是继承****类或者是****的创建者,本案例中需要从类实例化过程中很容易体会到RssMgrlmpl、RssManager、CrssImpl之间的组合/聚合关系。
RssMgrlmpl:继承rmManager,是接受到sip信令的实现,是RssManager的创建者。
RssManager:录制任务的管理者
CRssImpl:是CRssAvRecorderMgr的创建者。
CRssAvRecorderMgr:是任务中ReCorder的管理者
当需要创建新类的时候尽量保持与前人思想一致。(无优劣之分时按添加的代码量少数服从多数)
2、对自己代码:
忌不遵从当前工程所用的架构,使用自己熟悉的其他方式。
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、工程结构对称,了解一个工程结构,其他工程结构类似。
3、
3 如何做到
3.1 个人要求
1、对自己代码:持续开发,持续改进
2、对别人代码:从全局的角度理解前人代码思想,未了解前保持现状
3、别人到自己:规范的传承
3.2 工程要求
1、 头文件看护,架构头文件,专人看管,提交审核
2、 定期检视与整改,将走错门的代码重新归队,将违规的代码纠正
3、 新人了解项目结构和头文件