高中的时候，我觉得当黑客很帅气，心生向往，结果选择了看起来能成为黑客、事实上只可能被黑客攻击的计算机专业。2020年大学毕业时，看到华为面对制裁很“刚”、很酷，于是不假思索地选择了华为，来到成研，成为了一名真正的程序猿，体会到了什么是“休闲向左，成研向右”。

经过1年半的努力，我成了数据管理产品部OM（操作维护）开发部的MDE（模块设计师）和Committer，开始了和代码过招的日常。

“菜鸟”的不知所措：一天问800遍“是这样吗”

时间拨回2020年的夏天，当我还沉浸在晨练、红白文化衫以及“物质激励重要还是精神激励重要”的辩论中时，突然发现自己成了数据存储OM开发部最年轻的开发人员，摆在我面前的是一个完全陌生且复杂的业务领域。到现在我都能清晰地回想起来，自己面对数以十万计的代码以及复杂的服务之间的关系时，那种不知所措、无从下手的茫然感。

我接手的第一个需求是操作系统切换的需求，涉及到新操作系统的适配以及python2、python3的兼容。现在看来只是不到500行的小需求，但是对一个对linux的了解只局限在cp、cd、mkdir命令的萌新、一个对所有需要改动的python脚本功能都不了解的新员工来说，我的压力是难以言说的。

那段时间，我每天晚上都难以入眠，总觉得自己能力不足，难以梳理如此复杂的业务，没办法按时高质量地交付，无时无刻不在思考如何才能完成业务。每天走在上班的路上，我就忍不住胡思乱想：昨天的代码在联调中有没有发现问题？今天的工作能不能按时完成？那段时间，我每天问自己、问别人最多的就是：这个地方是这样的吗？那个地方我理解得有问题吗？

组内的同事给了我无限的包容。每次遇到一个问题，不论再忙，总有人帮我出主意，给出解决方案。随着“为什么”一个一个地减少，需求也进入了联调阶段。我所焦虑的问题也从“怎么实现”变成了“怎么定位解决当前遇到的问题”。

由于这个需求是系统层面的适配，很多问题要在联调阶段实际测试中发现，加之我们模块又是整个分布式存储的入口，某种程度上我们的角色就是个“守门员”，需要了解每个问题。因此，遇到问题，我会先查找相关代码，然后再跟组内的“老人”确认，是否跟我理解得一致，确认测试同事提出的问题是不是真的问题，或者将问题转给对应模块的人确认，最后记录到笔记本中。

随着时间的推移，需求越来越多，我定位的问题也越来越多，尽管还是会碰到各种各样不知道的技术，偶尔也会掉进没有踩过的坑里，但是看着笔记中越来越多的常见命令、常见问题，我已经不再焦虑，反而觉得这些问题越发可爱起来，逼着我不断成长。

随着积累越来越多，我发现自己可以解答不少问题了，也能够为需求的高质量交付贡献一份我的力量了。

终于有底气说“这个问题我知道”

经过半年多的“打怪升级”，我在日常问题的处理上已经得心应手。但我觉得，这样还远远不够，我经常打开问题列表，查看组内的常见问题，思考每个问题为什么会发生，怎样做才能避免发生这样的问题。看的问题越来越多，了解的业务越来越多，我开始有底气说出“这个问题我知道”。

一天，我正准备修改一个不太复杂的安全单，突然发现，这个发送LLDP（链路层发现协议）报文的小模块看起来并不简单。这是一个定制化开发的模块，平时不会使用，也没人关注，但却是重点客户采购规范里“指名道姓”的功能。

当我上手这一模块的时候，有一种“不祥”的预感。果不其然，当我轻车熟路地修改完安全问题并进行测试的时候，惊讶地发现，这个从老版本直接同步过来的模块，根本没有适配切换python3之后的操作系统，换言之，这个模块在当前版本软件配套的操作系统上完全不能运行。

本来2个小时的工作量突然就变成为未知。此时我还是很乐观，觉得自己应该可以快速搞定，因为python2和pyhton3之间的差异我并不陌生。但当我根据之前的经验修改完代码，放到新的操作系统上调测时，发现虽然程序已经能够不报错运行，但是表现却跟在旧的操作系统上面不尽相同。显然，已有的经验并没有帮我解决这个问题。

这是一个直接工作在链路层的协议，我平常很少接触。不过不熟悉不代表我会怂，我没有害怕，而是仔细走读代码，搜集相关资料。很快，我就发现，代码中报文生成的部分是直接使用的二进制内容书写的，而python在两个大版本之间，在编码方式上的确有很大的不同。于是，我根据这个思路，重点审视协议报文生成部分的代码。果不其然，重新修改后，我再在python2、3的环境上分别运行这个模块，报文格式、内容完全相同。这意味着问题已经解决了！

但是对于一个完整功能模块来说，需要端到端的验证才能保证功能完全正常。对于LLDP报文发送模块来说，这就需要在交换机上查看对应报文才能保证功能完全正常。提着一口气，我第一次登陆完全没有接触过的交换机，使用刚刚搜索到的命令查看到了这个模块LLDP报文，很快就放下心来——问题解决了！这个“逍遥法外”许久的功能被我成功逮捕，成为了前端测试用例库里的又一个例行执行的用例。

“代码质量好，回家回得早”成了团队的共识

作为一个典型的程序猿，我一直都有着代码洁癖。虽然是大学才接触编程，但是却很享受将想法变成一个个程序的感觉。大学期间，我开始阅读各式技术书籍，从《Java核心技术》到《Thinking in Java》，从《设计模式之禅》到《重构》，每本都如数家珍。入职后，在快速熟悉业务代码之余，我也依旧没有放下阅读技术书籍的习惯，并时常思考如何才能将书中的知识转换为能力，如何才能写好代码。入职6个月后，凭借着对业务的熟悉和对代码的追求，我被任命为OM团队内部最年轻的committer。

当我第一次看到自己的名字出现在正式的任命文件上的时候，难免有些欣喜，但是也觉得压力颇大。原来作为软件工程师的我，只需要管好自己的一亩三分地，做好测试自验证，保证自己的代码clean就可以了。但是作为committer，就要对组内的代码负责，需要看护好每一个经手的MR（合并请求）。再加上，我的组内全是前辈，面对他们的MR，我应该怎么办呢？

一时间，巨大的压力如同一张巨大的网将我包裹起来，让我不知所措。说来也巧，当时正要进行安全送检，我承担了安全排查的工作，一下感觉找了抓手。我梳理出100多个已有脚本，发现了30多个问题，总结出常见提取模式、命令注入等共性的安全问题，在组内开展多次培训。与此同时，在代码检视中，我也提出了很多关键问题，将问题拦截在最前端。

慢慢的，大家从被动的必须让我检视才能合入，变成了验证前先找我检视看看有没有“踩坑”。这时候，我就知道，大家已经认可了我的能力。

接下来，以肉眼可见的速度，大家代码越来越直观漂亮，安全问题显著减少。而且，大家还经常一起讨论，这个地方提到公共类是否更加合适，那个地方多加一个换行是不是结构更加清晰的一些“小事”。

不过，这些“小事”在面对版本交付压力的时候，突然变成了大事。在距离分布式存储产品的最新版本发布不到两周的时候，PL（项目主管）找到我，说在超大集群规模下，版本升级必然失败，需要紧急定位分析，解决问题。

经过分析，我发现问题了所在。模块里面包含一个从Excel文件读取配置信息的功能，代码逻辑极其复杂，以前就是一个黑盒，没有人改动代码，也没有人知道里面的功能实现。从模块诞生之初，这段代码就平稳地在系统中运行。但是随着版本的演进，集群规模愈发扩大，单个单元格需要承载的内容越来越多。在新版本中，单集群需要支持超过5000个节点，而当Excel中单个单元格字符长度超过32767时，读取Excel的三方类就会直接报错。

解决这个问题有两个选择，一是直接修改对应的类，对超长的单元格进行拆分，只需要不到100行，工作量低风险低。二是重构这部分逻辑，配置文件改为Json，并修改对应的解析逻辑。风险高且工作量大。

当时距离版本发布只有不到一个月的时间，PM认为风险较高，建议先使用简化方案处理。但是在我详细走读代码后发现，该模块的代码已经不适合当前的实现，如果继续修改会导致后续维护难度更大。作为开发者，我的代码洁癖不允许我选择“简化方案”，作为committer，我更需要以身作则。

所以，我坚决地选择了方案二，但是针对当前修改风险大的现状，跟PM和前端测试对齐，提前识别场景，做好用例设计并采用测试驱动开发的模式保证质量。最终，将解析代码由3K简化为0.1K，并且在一周内完成了开发测试上主干，高质量零缺陷解决问题。

由于升级业务的特殊性，我们所负责的微服务不能和产品包一起升级，需要在节点上手动调用相关脚本升级。且升级过程中需要输入3个用户名、5个密码，实施时极易因为密码错误等原因失败。针对这一问题，我仔细构思，设计并开发了自升级界面化功能。通过复用其他服务的通道，做到了在界面上一键完成升级，且升级时长较原先缩短50%，得到一致好评。

自升级界面化交付后可以在页面一键式升级

现在，每次不论是遇到问题、做新需求还是设计新特性，我总是喜欢想一想，有没有更好的方法，代码能不能更精简，可用性、可靠性能不能更高。每次看到做完需求代码反而更少了，我觉得比交付了很多“凑工作量”的代码更令人激动。

随着时间的推移，我经手的代码越来越多，被“挑刺”的越来越少。团队的代码质量也越来越高，花费在修改问题单的时间越来越少。大家也逐渐认可了“代码质量好，回家回得早”的这个道理，越来越多的人开始重视代码里的细节。

一点一滴的积累，一个又一个的细节优化，让我们的团队也变得更好。

穿越黑暗与苦痛，才能破茧而出

就像牛顿头上的那个苹果总是会落地一样，软件缺陷也是无法避免的，难免会有现网的紧急问题需要处理，尤其是我所在业务组负责的升级。为了不影响客户使用，升级总是在深夜执行，且有着严格的时间窗。现在，当被深夜的电话会议惊醒的时候，我总是会条件反射般地告诉一线同事“稍等两分钟”，然后迅速起身打开便携，快速处理闭环问题。这时候我才突然意识到，我已经从那个小心翼翼地询问“是这样的吗”的萌新，成长为“我马上上来处理”的团队骨干。

路漫漫而修远兮，吾将上下而求索。作为一个新上岗的MDE和Committer，我还有很多的知识需要学习和积累。就像被困在茧里的毛毛虫一样，只有默默积蓄力量，穿越黑暗与苦痛，才能破茧而出，见到更广阔的世界，遇见更好的自己。和大家共勉。