许达哲赴长沙湘江新区综合运输枢纽检查指导春运工作

具体实践时，作者并未进行纯粹的“重构”，还兼做缺陷修改，并增加自动化测试等辅助功能。原则上，对既有代码注重重构，对新增代码注重复用。

OMCI模块代码庞杂，分支众多，上手困难(据称半年勉强入门，一年才能熟练)。若不能有效掌握现有代码，后续难免被迫付出时间健康而又得不到项目认同(事实上，模块内发现的遗留故障源源不断)。反之，若能全面掌握现有代码，后续才可能通过反向工程、系统/代码恢复和重构等手段，将模块改造得更易开发和维护，最终解放编码者自己。

为提高代码研读效率，可采用分工阅读和代码注释的方法。

“分工阅读”是指将模块分为若干块子功能(如协议解析、告警、统计、二层、语音等)，组内每人负责一块或几块，不定期地交流和轮值。

“代码注释”是指在学习代码过程中，随手注释代码(大至流程、函数，小至代码行)，功能、意图、技巧、缺陷、疑问等均可(凡经过思考的地方都是可加注释之处)。其中“疑问”既可咨询兄弟产品同一模块的同事再转换为功能或意图，也可由其他注释者解答。

这样做的好处是：避免重复钻研；经验积累；可供量化。

代码可取产品最新版本，建立服务器公共代码目录(SVN管理更好)。注释时不要覆盖其他人的注释即可。

建议注释统一格式，便于识别和检索，形如”//>”。以下示出一个代码注释实例：

首先，规范变量、函数等命名。具体方法不再赘述。

其次，注释到位，尤其是全局变量和通用函数。举例如下：

最后，整改晦涩难懂的代码。主要有两种手段：

1) 改写方法

以PON光路检测为例，底层接口提供的光功率单位为0.1uW，OMCI协议Test消息上报的光功率单位为0.002dBuW，而Ani-G功率属性单位则为0.002dBmW。

原有代码转换如下(为突出重点有所改编)：

可见，原实现中转换关系非常晦涩难懂。其实借助1dBuW=10*lg(1uW)和1dBuW-1dBmW=30dB两个公式，经过简单的数学推导即可得到更简洁易懂的表达(为突出重点有所改编)：

注意，原实现中误认为Ani-G功率属性与Test结果的单位相同，新实现已修正该错误。

2) 封装函数

以实体属性的掩码校验为例，原有代码如下：

对usSupportMask赋值及判断的语句(第6~7行)，用于校验掩码是否越界。为更具可读性，将其封装为如下函数：

封装后的函数名恰当地起到“自描述”的作用。

该产品作为嵌入式终端，需要在Linux系统中编译打包版本，然后将其下载到目标单板上运行。这种交叉编译方式对于单个模块的调试而言，效率无疑比较低下。

为提高调测效率，在Linux服务器搭建在线调测工程。即提取OMCI模块代码，稍作改造后直接在服务器上编译和运行。这样就可避免每次修改代码都要重启单板升级大版本，调测效率极高。

为使模块可独立运行，需要编写模拟接口以屏蔽底层调用，并裁减暂不必要的特性(如线程和通信)等。

OMCI模块使用某内存数据库来管理需要持久化的实体信息，但该数据库代码内调用了大量平台相关的接口，不利于实现模块的在线调测。因此，作者研读源代码后编写了一个模拟数据库。该库仿照模块使用的几个原库接口及行为，模拟接口内部校验均增加错误信息打印，以便于排障。

此外，在数据库接口原语的基础上二次封装统一接口，一举消除模块内数据库操作代码的凌乱和重复。

没有测试保护网的重构，无异于没有血源的外科手术。

首先，公共接口和函数均提供有相应的测试函数，兼做示例和用例。如：

此外，模块内还增加自动化测试功能(TestSuite)，可用来验证批量或单个实体的配置和查询操作。批量测试结果统计如下(省略各实体的具体测试结果)：

在上述测试结果中，Failed TestCase(s)最为关键，表示失败的用例数目。此外，UnCompared TestCase(s)表示未做比较的条目数，如获取时间等易变属性的实体，无法预置恰当的期望结果，因此未做比较。测试过程中的打印信息可保存为日志文件，然后在打印日志中搜索Failure关键字，即可获知哪些配置失败。

当大量修改当前代码时，借助上述自动化测试功能，可迅速获知修改结果的影响。在开发新功能时，可先设计好测试用例和期望结果，然后按照“测试驱动开发”的模式来编码，提高编码效率和正确率。

传统的重构步骤是先容易后困难，先外围后核心。而作者反其道而行之，首先重构核心公共的代码。这样做的好处是：

1) 便于梳理头文件包含关系

在线调测工程中最初只保留最为公共的代码文件(如日志功能)，重构并调测通过后再逐步添加其他单一功能的目标代码。该过程中会按需拆分和/或组合文件，减少头文件的嵌套和交叉引用。

2) 避免重复工作甚至返工

公共代码重构后并封装后，对较外围的应用代码重构时会更容易消除冗余。若先重构好外围代码，很可能发现某些逻辑可以统一到公共代码内，从而导致大面积返工；而若先着手重构公共代码，则通过研读外围代码对其的使用方式，很容易及早甄别这些冗余性。

3) 迭代验证

在重构后的公共代码基础上逐步叠加外围代码时，也在反复测试公共代码的正确性和易用性。

4) 增强信心

先核心后外围、逐步叠加验证的过程可控，可增强大规模重构时的信心，缓解压力。反之，若先重构好外围代码，等触及核心时牵一发而动全身，压力极大。

在某产品代码基础上，进行OMCI模块DB/LOG/实体存取/消息处理/性能统计等重构。经过三个多月的重构后，模块代码复杂度大幅下降(某核心源文件平均复杂度降为原先1/4)，代码显著精简(据不完全统计已精简万余行)，同时更具可读性。新增代码的过程中，编写大量工具类宏和函数，并增加OMCI自动化测试、内存检测等实用功能。

通过LineCount和Source Monitor度量某功能代码重构效果，如下表所示：

此外，重构过程中积累的通用框架、代码及经验，可进一步应用到新的项目中。