MDU某产品OMCI模块代码质量现状分析

说明

本文参考MDU系列某产品OMCI模块现有代码，提取若干实例以说明目前的代码质量，亦可作为甄别不良代码的参考。

本文旨在就事论事，而非否定前人(没有前人的努力也难有后人的进步)。希望以史为鉴，不破不立，最终产出高质量的代码。

一 质量现状

不考虑业务实现，现有的OMCI模块代码质量不甚理想。无论是理解上手、修改扩展和测试排障，可以用举步维艰形容。尤其是二层通道计算相关代码，堪比令史前动物无法自拔的“焦油坑”。

本节将不考虑流程设计，仅就函数粒度列举目前存在的较为突出的代码质量问题。

1.1 巨型函数

通过Source Monitor度量代码复杂度，如下图所示：

if ((dbHandle<1)||(dbHandle>=mm_db_num)||(keyPtr==NULL)||(indexNo>INDEX_NUM-1))
{
GeneralErrorHandler();
return -1;
}
if(SafetyCheck(WRITE_OP,dbHandle)) return -1;
curRecNum=GetRecNum(dbHandle);
if (curRecNum==0)
{
FreeLock(WRITE_OP,dbHandle);
return -1;
}

_Update
其实接口设计者应定义一套错误原因码，校验失败时通过返回值向使用者抛出该错误码。如果接口位于同一源文件，则最简单最偷懒的错误码就是行数(__LINE__)！

另一处晦涩的接口来自1.2节的Omci_List_Query函数，该函数参数长度可变，但没有任何函数签名和注释。使用它的唯一“安全”方式就是搜索已有的调用代码，照猫画虎。

1.8 警告丛生

GCC编译器所提示的模块内警告多达1361处。若再进行更为严苛的pclint检查，则可以预想警告的暴增。

这是前人馈赠给后人的一大“遗产”，其中暗含不计其数的陷阱……

二 小结

以上示出的主要为函数级问题，尚未涉及流程设计。事实上，糟糕的流程设计不仅降低了代码执行效率，而且增加了人工理解和维护的难度。迷失在巨型函数森林里的人们，除了焦虑和绝望别无一物。也许，会有少数人知晓某条林间蹊径，但无法驱散追随者心中的不安。

幸运的是，软件工程先哲们指出了一条路：重构。那么，亲们准备好了吗？