华为编程规范及实例分析

简介：
《华为编程规范及实例分析》一书详细阐述了华为公司的软件开发标准和实践案例，旨在提升代码质量和团队协作效率。 【案例1.12.2】 问题描述： 在进行主BCCH载频互助新功能开发的并行联调测试的过程中，发现以下的问题：当数管台设置“TRX倒换是否允许”为“是”，执行整表设定后，关闭基站中一个配有4个TRX的小区的主BCCH所在的TRX电源。此时对应小区能够重新初始化并成功运行，即载频互助功能生效。然而，在对这个站点进行四级复位的同时重启之前被关掉的那个含有原配主BCCH所在TRX的电源时，发现该小区无法正常初始化。 问题定位： 在开始分析这个问题的时候，我们首先检查了载频互助相关代码在基站初始化流程中的处理方式。BTSM程序中，在执行初始化前会判断是否发生过载频互助，并且如果发生了，则进一步确认原配主BCCH所在TRX（数据库配置的）是否已经恢复正常运行状态。若确定该TRX已恢复，就会将之前用于临时替代它的其他TRX的数据与实际主BCCH TRX数据交换回来并重新初始化。从表面上看，这样的处理逻辑没有明显错误，但为什么会出现无法正常初始化的情况呢？ 我们通过在关键变量上添加调试信息，并重现问题场景后，在打印出来的日志中发现了一个重要的线索：即载频互助发生后的TRX号与实际数据库配置的主BCCH所在TRX号相同。这显然是不符合逻辑的，因为载频互助的意义在于当原配主BCCH TRX不能正常工作时启用其他备用TRX作为临时替代。 在进一步检查所有BTSM相关程序未找到问题后，我们转向了最近合并进来的版本中可能涉及的相关模块代码，并最终找到了导致该异常行为的原因所在。原来，在载频互助功能的处理过程中使用了一个全局变量ptrBTS_CONFIG_MAP[BtsNo].TRX_no_BCCH_in来表示当前实际运行中的主BCCH TRX号，这个值会随着系统状态的变化而变化；同时还有一个固定的指针CoTRXGroupForBts[BtsNo].MainTRX用于保存数据库中配置的原配主BCCH所在的固定TRX号。这两者在初始化过程中被赋予相同的初始值：函数FetchOneSiteConfig（）中的第409行有相应的赋值语句，即 CoTRXGroupForBts[BTS_no_temp].MainTRX = ptrBTS_CONFIG_MAP[BTS_no_temp].TRX_no_BCCH_in。 然而，在DBMI模块的同步开发中进行了一些改动：在每次数据动态设定之后，会检查该站点是否发生过载频互助。如果确实发生了，则尝试将当前被借用作为主BCCH使用的TRX的数据与实际配置为主BCCH TRX的数据交换，并随后执行站点初始化过程。问题就出在这里，在DBMI模块中认为数据库中的原配主BCCH的TRX是ptrBTS_CONFIG_MAP[BTS_no_temp].TRX_no_BCCH_in，而每次进行站点初始化时都会调用FetchOneSiteConfig（）函数，这导致了CoTRXGroupForBts[BTS_no_temp].MainTRX在系统运行过程中被频繁修改。正是这种不恰当的数据更新机制造成了上述异常现象的发生。 通过以上分析和定位工作，我们找到了问题的根本原因，并针对此进行了相应的代码修正以确保载频互助功能的正确实现与稳定运行。