高考毕业那年，计算机专业非常火，我没怎么犹豫就入了程序员的“坑”。大学兼职时，我给一个高一男孩做家教。还记得第一天给他演示编程，他就惊呼起来：“哇，米哥，你也忒牛了吧，以前在电视里感觉挺神的，真看到代码运行出来的结果，崇拜、佩服！”

看着他崇拜的眼神，我虽然表面平静，但心里还是忍不住小开心了一下，那是我第一次感受到编程带来的成就感。从那时开始，我就有了程序员的极致“洁癖”，以及不安分的好奇心。

第一次给代码动手术

进入职场，和所有的年轻人一样，我浑身有一股使不完的冲劲儿。有些人说我急性子，对于代码，眼里容不得一粒沙子。而随着对业务及代码的理解更加深入，我的代码“洁癖”也愈发凸显，看着“将就”的代码，就觉得难受。

那时，我们一直在做A产品的特性交付，B模块历来是我们的老大难，经过长年累月不同开发人员的堆叠，架构早已令大家诟病不已，看起来很烧脑，要看懂得费半天劲儿，改起来就更别提了。

我思量着：“这么费劲儿，不如一把改掉，以后看起来也干净利落，如果改好了，新员工进来都能秒懂，性能也能提升不少……”我决定对B模块来一次大开刀！

起初，代码咔咔地很快就写出来了，正在我觉得即将大功告成、内心窃喜的时候，却迎来当头一棒：验证阶段一开始就出现了严重的性能问题。那天，我正在验证C特性，按照以往的经验，应该秒速获得结果，可这回运行时间却翻了N倍。我这急性子哪受得了，抓着头，苦恼不已：这和预期差别也太大了！

幸运的是，当时算法部的兄弟小赵出差西安，收到我满怀期待的求助，很快就成了我的盟友。

他仔细看了我的代码：“这里的算法还可以提升性能的……”讲得特别细，让我茅塞顿开。“天啊，不愧是研究算法的”我心里暗想，“嗯，确实，有些细节还可以再优化。”

那些日子，我拉着他天天一起研究，他从算法维度提升性能，我再基于代码本身提升性能。有时，为了一行代码、一个函数，我和他会PK很久，谁都不让谁，也会为突然闪现的一瞬间心有灵犀而嘿嘿一笑。我已经不记得改了多少次代码、编了多少次版本。经过“地狱式”的磨练后，代码性能相对之前提升了十倍，也因为这份全新的B模块代码，我获得了那年的“网络十大金码奖”。

我还记得小赵离开西安前说的一句话：“米哥，我终于感受到什么叫一线研发兄弟的炮火了，真的就像打仗啊！”可不是，不想将就，不就得大干一场！

从修改300行代码，到修改30行代码

多年来，针对不同客户的定制化需求，产品E已经衍生出多个版本。2017年，我成为PL，正值开发客户定制的产品EF，由于老代码的架构限制，每定制一个版本就需要修改300行代码，而且修改点非常零散，需要投入很多人去开发、检视、测试代码，时常出现问题。

于是，我决定要改变这种长年累月的“困境”。我和彪哥连同小常、小曾重新梳理架构。然而，很快我就发现，这次重构与版本人力产生了一定冲突，随之而来的质疑也让我感受到了身心的双重巨大压力。

“米哥，重构能不能以后再搞？感觉对特性交付冲击有点大。”有兄弟抱怨。

“咱们上一个定制版本遭的罪还历历在目啊，这个产品再这样下去，一直做大量重复工作，我们的时间就是这样被浪费的，效率低，质量也难以保证。”有兄弟提出不同意见。

“大家都知道这个情况，不过这么多年了，一直没人敢尝试把它拎起来重新搞一遍。”还有人说。

我明白大家的难处，但是咬咬牙，这次挺过去，以后所有E产品就不用再耗那么多时间和精力了。因此我和大家说：“版本交付节奏方面，我和项目组再商量下，适当给大家多留一些时间。但我们不能放弃！”

于是，我们针对零散的特性开关，整合了所有的能力集合、属性集合，将不同定制版本的公共点提取出来，针对差异点集中适配。我还搭建起了“白盒测试框架”，开发阶段就能够深入到代码的具体流程，可视化地看到每一步执行后的数据变化，进一步保障代码交付质量。

这一次的代码重构对整个项目组的收益是巨大的，曾经需要修改300行代码被减少为30行。后来开发客户定制的产品EG时，入职不到一年的新员工也能轻松交付，研发成本大幅度降低，质量也更好了。那一年，我们获得了公司级架构优化的优秀实践，我也因此获得了公司“金牌个人”奖。

打造一支可信的团队

我们时常会去思考：可信这个工作，团队到底要做些什么？但在我看来，有一个问题更为重要，那就是：为了带动团队落地可信，基层主管要先做些什么？如果基层主管能够在意识和行动上做出表率，那么很多事情就变得简单。

2019年，我成为了CGM（Component Group Manager），团队从8个人变成了30个人，挑战不小。我想，公司一直在倡导写好代码，可大家写了那么多年代码，基本都有了自己的习惯，其实挺难改变的，得真切地让大家感受到写好代码的好处、写坏代码的弊端。

为了给大家带好头，我整理了公司可信学院的所有资料，初步梳理了一些可以优化的模块，套用设计模式修改。不久，我迎来了第一次“代码坏味道Kill时刻”分享会。

“我们以前没少被代码坏味道坑，咱们自己一直在填坑。”我说。

“其实，咱也没少挖坑。”大家都哈哈大笑了起来。是的，小李说出了大家的心声。

“大家是不是每个人都知道设计模式有哪些？是不是都有一些编程思路和技巧的‘藏货’？”我问大家。

“知道一些，但感觉不用那些设计模式，似乎也能搞定交付。”有人回答道。

会上，我以之前的G模块为例，从思路到代码框架，再到其中的编程技巧，向大家对比了修改前后的代码差异，无论是代码量、效率还是可读性，都比之前要明显好很多。

“要写出这样的好代码，得先有这样的硬能力。”有兄弟一针见血地说。

“没错，公司可信学院现在有一些资料，我们也可以买一些技术书籍，我和总工带头先看，后面把读书收获也纳入我们的分享。”我说。

“最重要的还是实践，不如以后我们就‘轮值’来分享自己的新尝试、新发现？”有人提议。

大家你一言，我一语，讨论得很火热，提出了很多问题，也想出了很多妙招。为了将这样的学习和讨论渗入整个团队，后来我们从每个小组抽取一人担任“种子选手”，大家在一起研究试点模块该如何重构、好的学习资源和思路，再让“种子选手”们给各个小组带回去，激发每个小组的学习意愿，小组内互相分享、交流思想，大家写好代码的意识更足了，技术氛围也比以前更浓了，交付的代码比以前“漂亮”了，出的问题也比以前更少了。

永不停歇的编码打怪之路

有人问我：“小米，你为什么那么痴迷于写代码？而且团队还带得那么好？”

在我看来，知道自己喜欢干什么并去坚持下来，这是一件非常难能可贵的事情，在我的职场生涯中，唯一没有落下的就是代码，因为兴趣，因为成就感，也为了避免自己的职场焦虑。

作为基层主管，如果在技术上不是团队领先，那么兄弟们就很难打心里去信服你。技术强了，技术决策会更加高效、正确，才会有团队威信力，每个人的劲儿也才能更好地使出来，团队也才能拧成一股绳。

技术一直在变，我们要学的总是很多，可信之路很漫长，如果不去努力奔跑，就很难跟上前进的步伐。这个世界从来没有免费的午餐，程序员的领地也总是充满未知，与其焦虑，不如开启“学霸式”编码打怪之路，主动出击。

可信不易，信者无疆；暗夜至深，自现光芒。