为一个读书阶段从未接触过通信的小白，我有很多的不足，但在这4年里，有幸参与了很多项目，也得到了很多前辈的帮助，软件技能、业务能力以及攻关疑难问题的能力都得到了很大的锻炼，一路走来非常充实。

通信小白的打怪升级路

2016年4月29日，我结束了一周的大队培训，在秘书姐姐的带领下，穿过上研基地长长的走廊，到部门报到。午后的阳光透过大玻璃窗洒落在身上，我心中既期待又忐忑。一边走一边想：网上传言的“圣无线”的各路大神都长什么样？传说中随便哪台电脑都可以登陆办公的“云办公”系统又是什么东西？

走到办公区，一个朴实、带着亲切笑容的人走向我，热情地介绍说：“我是你的导师。”后来我才知道，他是个技术大牛，也是我的PL。

“刷”手机刷出的意外收获

入职后，导师给我安排了一系列的学习以及工作计划。作为通信小白，听到诸如IFFT、调制、解调等通信概念，我又懵又着急。几天学习下来成效很有限，我有点抓狂：这基站系统也太复杂了吧？我得学到啥时候才能搞清楚这些东西？

我把自己的顾虑向导师和盘托出。导师想了一会儿，交给了我一个任务—— 刷手机。顾名思义，就是把用作测试终端的手机，从正式版本刷新成测试版本，安装一些测试软件并且配置参数。

What？刷手机？这也属于开发的工作吗？我惊讶到不行，既不能提高编码能力，也不能提高业务能力，完全是个体力活，给我派这个活对我有帮助吗？我当时有点不解，但是又想，再简单的活总得有人做，说不定做着做着能有别的收获。

到了实验室我才知道，整个任务其实是搭建一个语音的大话务环境，刷手机版本只是其中一部分工作。我立马就开动，一天马不停蹄地刷下来，只刷完了20多台手机。看着桌上高高垒起的400多台手机，我陷入了沉思：这怎么也得一个月时间才能弄完，效率太低了！

怎么能够提升效率，把环境测试任务的进度提前呢？我想，刷机的几个步骤主要分成版本刷新和脚本配置两方面。既然刷新脚本受限于电脑个数，我可以找各方协调，增加几台机器用于刷机。在脚本配置方面，我求助了之前搭建环境的同事，还在3ms上搜索了不少经验分享，花半天时间突击了一下自动化脚本的环境以及配置。

这样一来，我们就可以采用自动化脚本发送命令的方式，代替原先需要手动输入的50条命令，时间上有了几何级缩小。最终5天时间，便刷新完成了所有的手机。

不仅如此，刷手机还真给我带来了意外收获。在升级手机的过程中，我对LTE的环境组网和环境操作有了深入了解，将一堆毫无关联的硬件器材连接起来，在进行繁琐配置后成功建立“小区”，最终将400多个用户成功接入语音业务，不仅成就满满，更重要的是，在后续的工作中，这次的环境经验也对我有很大的帮助。特别是在进行话务量优化工作的时候，当别人还在研究如何使用话务量环境、如何解决话务量环境的各种奇葩问题的时候，我已经早早整理好环境，测数据，为优化工作节省了大量时间和精力。

由于高效地完成任务，PL对我的学习态度和做事方法很满意，在后续的工作中，不断给我越来越难的任务，自己的能力也在这些挑战中一步步升级。

回头来看，假如我对简单的任务不够重视，完成不好，必然无法接触到更有挑战性的任务，也不可能有后来更快的成长和更大的价值发挥。

是解决眼前问题，还是一劳永逸？

经过一些简单的特性开发后，我赶上了新版本上第一个局点。经过两个版本的开发，特性基本算告一段落，但是一个非常关键的客户界面指标——可用带宽存在异常。

这个问题主要是由于LTE与UMTS、GSM频谱共享的特性糅杂在一起。为了解决这个问题，只能在老的流程里面，增加很多差异化处理分支以及冗余流程。这就好比一条马路上只能跑一种车型，新增一种车型就得新修一条马路，性价比以及利用率都很低。

经过了一番突击“修补”后，客户界面的指标终于在各个场景下都可以正确计算了，理论上这时候特性开发也就差不多可以结束了。

但我盯着充斥着“坏味道”的代码，想着当前频谱共享这么热，如果再来一个类似的特性，是不是又得再次经历这样一番痛苦的过程？而且代码将愈加复杂而无法进一步扩展，新同学也很难看得懂当前的逻辑。再则，当前充斥着冗余和重复的代码模块，已经没人能彻底搞清楚它了，它就像一个隐藏的炸弹，说不定什么时候就有可能爆炸。

基于这些考虑，我“无知无畏”地跟PL提出了重构的想法，想用一劳永逸的办法解决，而不是缝缝补补。

整个重构过程相当于新修道路，只不过这条道路所有的车型都可以跑，同时我们得保证在新道路上从同样的起点出发，可以到达跟老道路一样的终点。但是重构最大的风险也在于，如何在重构的过程中不破坏老功能，不引入新问题？

针对这个风险，我们使用小步快跑的策略，摒弃大而全的处理，对差异性很小的处理进行优先合并，并通过充分的验证，保证新的修改没有问题。最终呈现出一个主干道加多个小的支线的结果。

策略定了，具体如何实现呢？对于C语言这种面向过程的语言，虽说上学的时候，我学过一些软件方面的知识，但缺乏实战经验。只得重新拿起《设计模式》、《重构》等书籍来获取重构的方法，并与组里面的软件高手进行讨论，将书本上的知识与实际代码结合起来。我们最终敲定了使用建造者模式和模板方法，同时结合C语言比较容易实现的表驱动的方式进行代码开发。

经过一个版本的开发以及验证后，整个模块整整降低了一半的代码量。看着新写的逻辑清晰、结构紧凑的代码，别提有多舒心了！

后续的多个版本也验证了我们重构后的代码可靠性、兼容性都很好。随着5G的推出、新的LTE与5G频谱共享诉求的到来，我们的模块可以很好的兼容此场景，为LTE与5G的频谱共享节省了很多代码开发与问题处理时间。

这次主动重构的体验，也让我养成了一个受益匪浅的思维习惯：不论是代码开发、方案分析、功能验证，在开发全流程中，我都尽可能多想一轮，多走一步，提前考虑可能发生的情况，提前做好应对，这样就能掌握主动权，从容面对一切需求和变动。

一场刻骨铭心的攻关

2019年下半年，又一个难度升级的特性开发落到我们肩上：新版本要实现一个轻量级的跨制式共享模块，4G/5G乃至将来的6G都可以共同使用。

如果这个模块按常规做成一个组件，就要带上厚重的平台底座部分，性价比很低。于是，我们想到将此模块做成一个类似“插头”的功能，在不同的制式使用不同的“插头”。这个“插头”相比整个庞大的“供电系统”就轻巧很多。

2个月紧张工作之后，我们终于开发解决了关键矛盾，完成了主体流程。本以为可以松一口气了，没想到遇到了更大的麻烦。

在一系列测试验证中，我们发现前期分析遗漏了规格管控功能（类似于每个“供电系统”最多给多少个插座供电的功能）。为了弥补此功能，我们就在当前架构基础上进行了适配处理。

万万没想到，这个功能一上线，部分场景就出现了小区无法建立的问题，导致每日版本无法使用，阻塞每日测试。

情急之下，我们立马回退功能，并新推一个版本先解决燃眉之急，但此时问题单已经如雪花一样飘来，手机espace铃声不断，各种连环夺命call让人头皮发麻。整整一天时间，我都在招架问题单和确认问题中度过，完全没有空隙整理和讨论有效的解决方案。

等到晚上新推的版本上线，测试基本业务可以正常进行后，我、PL和同事A立马集结在一起，首先对工作进行了分工：PL在前面抵挡“炮火”，帮忙初步确认功能问题，处理问题单；我则全身心投入到此部分功能梳理，以及详细设计分析中；另一个同事协助DT环境以及真实环境的准备与调试。

经过半天的梳理，我们得出一个很令人崩溃的结论——当前的架构没办法实现100%控制规格同时又不影响基础功能。

怎么办？这意味着要想彻底解决问题，必须将当前的架构推倒重来，而此时离版本TR5不到两周时间了，太赶了，而且还存在破坏老功能的风险。第二个选择，就是在当前架构基础上硬着头皮叠加，但存在某些极端场景无法预知的问题风险。

PL看到初步分析结果，没有纠结太多，拍着我的肩膀说：“我们不能明知有问题还不彻底解决，这是这个特性的第一个版本，那就尽力做到完美，况且LTE这么多年，还没有解决不了的问题，不要担心，我们放手去做就好了。”有了PL的鼓励，我坚定地选择了方案一。

确认方向后，我们三人再加上松研所的同事，紧锣密鼓地投入到新方案的制定中。白天，大家根据大方向提出自己的思路并给出模块设计，晚上，对各自的方案进行阐述并去糟存精，并对已确认的方案进行同步开发自验证。

持续攻关了一周左右，我们在当前支持的最复杂的组网场景下，换上软件包，带着激动和颤抖的心情，敲出“激活小区”的命令，小区全部激活成功！大家握紧的拳头，终于可以放松下来了。

鉴于之前的经验教训，PL又组织大家再次梳理流程细节，没有发现任何问题。我悬在心中的石头总算落了下来，可以回家睡个安稳觉了。

第二天，新方案正式上线，上线后规格管控部分的功能正常生效，从后期版本的结果来看，模块的性能以及质量都达到了较高水准。

这次刻骨铭心的攻关也让我认识到：在我们的开发过程中，不论多么周全的计划和准备，难免出现预想不到的状况。因此，在规划之初，一定要为“意外情况”预留时间；此外，亲历这次攻关，我也更加坚信PL所说的那句话：“LTE这么多年，没有解决不了的问题”，要做的，唯有从容冷静地去分析和解决它。

一晃我入职已经4年 ，这4年经历过通宵定位问题的辛苦，也体会过最终能成功解决问题的激动，经历过迭代过点的紧张，也品尝到特性交付上网之后增益明显的喜悦。

作为一个读书阶段从未接触过通信的小白，我有很多的不足，但在这4年里，有幸参与了很多项目，也得到了很多前辈的帮助，软件技能、业务能力以及攻关疑难问题的能力都得到了很大的锻炼，一路走来非常充实。希望在后续的工作中可以迎接更多的挑战，不断地发挥自己的能力，实现个人价值。