当我“啃”下近百个功能点后，我切实地体会到自己在命令行功能领域有了“质”的飞跃，我也成为了一名更有“资本”的责任田主。

我心里暗暗下定决心：要继续努力，有朝一日要成为项目组里的多栖责任田“地主”！

“各位旅客，列车前方到站南京南站……”

列车到站的播报声响起，一双带着校园余温的双脚即将踏上金陵这片陌生的土地。下车时，雨刚好停了，七月的夕阳散落在月台上，蒸腾的水汽让我的眼镜蒙上了一层薄雾。眼前闷热潮湿的城市正在展示着它的喧嚣，以聒噪的蝉鸣欢迎着我。我用衣角擦了擦模糊的镜片，伴着身旁人群的喧闹，抬头寻着出站的标志牌……

五年，时间过得太快。此时，我在松山湖欧洲小镇里散步，抬头望着远处的月色，手里握着一杯汲取着宇宙能量的咖啡，不禁想起五年前的那个夏天。

缘分始于五年前

2018年7月4日，我跟另一位同事准时到数据通信产品线报到。

“两个小鲜肉，你要认领哪一个？”未来的DE（设计工程师）帆哥问杰哥。

“那就这个好了！”杰哥看向我，冲我笑了笑。就这样，杰哥成了我的师父。

杰哥是一位技术特别扎实的专家，每次都能揪出我代码中的“八阿哥（Bug）”。可能是为了面子，不想总被师父挑出错，有一次我也不知道自己当时是怎么想的，把一个简单的三元运算符写得非常复杂。

代码视检的时候，杰哥指着这块代码，开玩笑地对我讲：“这块为啥这样写，是不是水平低的代码不屑于下手？”我仔细再一看这组代码，马上就发现哪里出了问题，我俩被这“丑陋但正确的代码”笑得前俯后仰。

师父善于授人以渔，经常给我点明大方向后，鼓励我自己独立探索，思考问题的前因后果，让我真正知其所以然。几年后，我也当上了新人的师父，每当徒弟问我问题时，我都会想起杰哥对我的教导，尽力将这份优秀传统传承下去。

公司高度重视软件质量，从软件能力提升角度提供多维度的各类培训和以考促训。而我，作为入职不久的新员工，非常享受这份“福利”，积极参与到部门策划的软件代码答题悬赏。当时，师父带着我一路刷题打怪、钻研难题、共同竞赛。除了每天完成代码整改的计划和目标，参加产品线的各类培训，挤出来的时间就用在代码题的练习中，我感觉每天都过得很快，也无比充实。

我清楚记得，我跟师父当时都没能攻下的一道难题。网站系统上只有一个很粗糙的题解，没有推理过程，代码还写得较为晦涩，我俩看了半天也没弄清楚。我一直想着这件事。一有空余时间，我就会找一些同类题目，学习他们的推理思路，想结合着那个晦涩的题解代码继续寻找解题的思路。几天后，我突然发现有一个划分树的数据结构恰好能应用到题目中。我尝试着简单推演了一下，果然成功了！我兴奋地再次验证了解题思路，顺利用划分树的方法“攻下”难题，然后高兴地去和师父“邀功”。此后，再面临一些复杂题目时，我都会主动整理一份题解，也希望能给别人带去启发，涌现出更多的思路。

此时，复杂软件的挑战并没有向我露出獠牙，初出茅庐的我也没有意识到前路艰险。“工作还挺简单纯粹的”，我不止一次在下班路上发出过这样的感叹。

“闭关”六个月

2019年3月，初春的风并没有带来丝毫暖意，南京似乎还沉浸在冬日的氛围中。

“有一个重要项目即将启动，需要长期出差支撑项目的首次交付，你要不要考虑一下？”会议室里，模块主管晓华哥问我。

“好啊，哪里需要我，我就去哪里顶上！”我没怎么犹豫，应声答道。

出差支撑的项目叫做云杉平台。云杉平台是一个开放式的软件平台，承担了实现软件定义产品等历史使命。几天后，项目启动动员会议正式召开，我如期踏进了华为杭州研究所会议室的“小黑屋”，开启了为期6个月的闭关修炼。

项目正式启动后，我才发现自己的知识竟是如此的匮乏。由于之前一直在云化项目组，我基本没接触过传统嵌入式设备的操作系统，再加上安全可信整改专项与业务流程关系并不大，我对业务的诸多细节也是“云里雾里”。晨会听前辈们讨论计划方案，有好些名词是啥意思我甚至都不知道。幸好，我抱上了兄弟部门的“技术大腿”奕哥。因为他力气大，大家都叫他“大力”。每次遇到不理解的概念或者功能流程，我就会跑过去拜师求艺。自然而然地，“大力”成了我的另一位师父。那时候，我觉着老员工真是厉害，无论遇到什么问题总能想出合适的方案解决，我自己的代码也在一次次的学习请教中逐渐完善，我也变得越来越自信了。

这次项目中，我要负责设备启动阶段的sys_boot模块和sys_preload模块，这个功能模块从BIOS（基本输入/输出系统）加载直到拉起软件平台组件的过程中，扮演着承上启下的重要角色。打通设备启动流程，成功进入设备命令行界面——这是项目中第一个重要的里程碑目标。时间过得很快，整个项目组都在忙碌中陆续完成前期的准备工作。为了达成设备零调首次登陆即成功的目标，我们把5月15日定为本阶段的时间节点。

“今晚，我们守住目标！达成登陆成功的关键里程碑！“

2019年5月15日的凌晨，目标已尽在咫尺，各个模块的自验证准备工作已全部完成，第一个联调大包已经上板。我满怀期待等待大家的欢呼，却听到了意料之外的声音：“启动失败！”

一群人火速投入到问题定位中。经过定位，一个底层模块接口近期的改动点与sys_boot模块没有配合好，导致sys_boot模块获取启动信息失败。找到原因后，大家很快便开始紧张有序的编码调试。时间在键盘的敲击声中渐渐溜走，当完成sys_boot模块的适配调试后，我忐忑地检视着代码，生怕适配工作出现其他纰漏。最后，在架构师的梳理下，我们确认所有模块再次准备就绪，就差最后一个大包来验证我们的成果。编包流水线启动，精确又漫长地执行着每一步。有的同事趴下来稍稍眯一会，有的同事不放心，还在检查着其他可能出现的问题……最紧张的验证环节来了，所有人的期待都灌注在这一次的启动结果上。

“大包已成功传上，设置下次启动大包！“

“启动开始，BIOS自检，磁盘挂载，一切符合预期！“

“sys_boot、sys_preload流程正常，各个服务拉起中！”

“启动成功！“

“Press Enter”这行字终于出现在界面上！大家长舒一口气，会议室里氛围从紧张到喜悦，我也如释重负。我不经意间望向窗外，杭研所的夜晚静谧安静，美得像一幅画。

压在我身上的三个重担

为期6个月的“闭关修炼”落下帷幕，我也回到部门继续投入到云杉版本软件设计的开发任务中。为了提升产业竞争力，快速响应市场按需定制产品的诉求，云杉架构的集成方式由“业务定制上车”逐步过渡到“产品定义集成”，因此软件平台归一的重点项目被规划进路标，迭代计划随即启动。

在云杉平台22.X版本上，我感受到了前所未有的压力。在这个版本中，有两个比较大的关键需求落在了我所在的项目组：一个是平台归一项目，另一个是接入产品的解耦需求。除此之外，我们还需要承接一个临时插入的商业变现新需求的设计工作。时间紧、任务重，我感到担子突然一下子压到了我的肩上。当时，我们的PM（项目经理）看到这三个重点需求都压在了我身上，直接跑到PL（项目组长）明明工位上“吵架”：“你把你们项目组这三个重点需求都压在贾胄一个人身上，这怎么行？不是这么投入人力的！风险这么大，怕是一个都搞不成！”

我坐在一旁，安静听着他们为我吵红了脸。我边听内心边“发毛”，这几个需求与我负责的模块都算强相关，我作为责任田田主，对于这几个模块最熟悉，投入其中肯定能搞得快，这也是较为合理的安排。但是，这几个需求的工作量很大，尤其是平台归一项目，工作量实打实地摆在那里，我自己一个人怕是“吃不消”。本来想再抓一位对这个模块比较熟悉的同事进来“救火”，但他要支撑另一个版本的TR6（验证阶段技术评审点），无法抽身。事情似乎陷入了无法调和的僵局……

怎么办？这么耗下去确实不行，得先对齐应对策略！我拉上PL和DE帆哥，把这三个需求的关键点与里程碑相继罗列出来，并着重统一评估了这三个需求的预期交付时间截点。我们越拆越细，需求和策略也愈发明朗起来：

接入产品解耦的需求最急迫、最重要。关键的特性功能梳理离不开这项需求的落地，因此还是由我上阵最合适。况且，经过我们的梳理，代码量实际上相对没那么“吓人”，我专职投入一星期应该就能搞定。待整理出特型全量功能分析的交付件后，我可以把代码委托给处理告警与SNMP（简单网络管理协议）模块解耦的亭哥处理，后面可以将另外两个特性一并验收交付。

平台归一项目的需求很重要，但不是最紧急的，可以先延缓一周。我认为可以将前期设计内容的串讲设计先搞定，放在产品解耦的需求后再开发，从而有效保障人力的投入。

至于商业变现的需求，我们了解到有兄弟模块正在做同样的设计，我们认为可以先拜托兄弟模块同步设计梳理公共部分的内容，等到解耦需求顺利交付后，我们再投入完成其整体模块下的特定设计工作。

整理完初步的对策后，PM也觉着这是当下最可行、最靠谱的策略，爽快地同意了：“行！就按这个策略搞！加油啊！”

就这样，我们按照前期制定的策略，稳步推进工作，陆续圆满完成了三个需求的交付验收。当然，交付路上并非一帆风顺。还记得在解耦需求的设计中，我们需要分析、梳理出命令行模块所有的功能点，从每一个类、每一个脚本中梳理清楚其功能作用和使用场景，最终输出用于解耦的分析表。这其中最令我们头痛的是，很多功能都是冷门功能，使用场景非常少，还有不少代码是已经没有业务使用的废弃代码，知晓其历史背景的开发人员也寥寥无几。我在梳理过程中可谓使出了浑身解数。为了看全、看尽所有功能点，我们在分析代码的同时，还主动与专家讨论、查询资料文档，甚至通过注释中的问题单来排查代码的应用场景。

最终，当我“啃”下近百个功能点后，我切实地体会到自己在命令行功能领域有了“质”的飞跃，这对之后的设计开发工作也很有帮助。同时，我也成为了一名更有“资本”的责任田主。我心里暗暗下定决心：要继续努力，有朝一日要成为项目组里的“多栖”责任田“地主”！

如何增加自身技术纵向学习的深度？如何拓宽和周边协同能力的广度？我想做项目可能是最好的方法。不同于培训赋能，开发项目需要从功能、安全、性能、可靠性、可测试性、易用性，以及和周边模块配合等方面进行细致的梳理与分析，对每一个细节的考量都能体现出个人技术的沉淀与积累。相应地，复杂软件之所以具有较高的技术壁垒，除了受项目规模与问题难度制约，人的经验也是非常重要的一部分。“聪明就是知道的多”，经验老道的同事的一句话，就可能顶得上新兵蛋子半天的分析。通过做项目提升个人技术能力，再将个人能力传递下去、应用到项目中形成正循环，我想这是每一位技术人的追求和理想。

写在最后

一步一脚印，回首已五年。从技术菜鸟到领域专家，从明日之星到金牌个人，这五年我收获良多。在成长之路上，我要感恩家人无私的支持，让我有坚强的后盾去奋斗；我要感谢朋友真切的关怀，也幸运能够与周围的同事们一起并肩作战，克服困难。

时间回到现在。我像五年前刚刚踏上南京南的月台那样，擦了擦眼镜，抬头仰望。周围没有赶路人的喧嚣，只有夜空中点点闪烁的星星，清晰且明亮。灵光一闪，我打开手机上的记事本，写下了一首打油诗，也算是不辜负这漫天繁星。

华人苦奋斗，

为客献心血。

必克艰困阻，

胜果缀星宿。