(相关资料图)
作者 | 胡 健
来源 | 心声社区、蓝血研究（lanxueyanjiu)
“我怎样才能成为一名总裁？”2020年在与产品线总裁的一次座谈会上，我鬼使神差地问了这么一个问题，引得大家哄堂大笑。
“做好每一件小事，在平凡的岗位上创造不平凡”，总裁的回答至今让我印象深刻，也一直激励我前行，让我在后续的三年里受益良多，走上快车道。
01
七点半的班车——初为追光者
刚成为追光者那会儿，我们住在武汉光谷软件园旁的清江山水，窗外有一条长长的火车轨道，轰隆隆的火车穿越声震耳欲聋，脚下的大地都在有节奏地颤动，但是我似乎已经适应了这种生活，每个夜晚都伴着哐当哐当的声音进入梦乡。睡前查看第二天的天气成了我的习惯，从小区到最近的班车点，步行大概一刻钟的路程，遇上雨天，就需要再早起十分钟。
班车每天早上8点到武汉研究所后，我都会带上一份早餐，选一本“枯燥又有趣”的技术书籍，独享这份静谧的时光。有一天，我正在专心致志地看《Clean Code》，突然一阵阴影掠过我的视线，抬头一看，发现我的师父不知道何时站在我的身边。他带着一副金丝边眼睛，一脸欣慰地看着我。
“小伙子来得挺早啊，挺努力的呀！”
“没办法啊师父，早上七点半的班车，我也希望快速补齐一些业务知识，早日跟上大家的节奏。” 师父面带微笑地地点了点头。
后来，经过他的推荐，我很荣幸通过软件特战队的选拔，成为第一批特战队员，进一步开拓了我的视野，让我对高质量的产品开发有更深入的理解；同时，也培养了我日复一日坚守的阅读习惯，从经典书籍中汲取优秀的原则、模式、方法，从优秀的开源代码中学习前辈践行这些原则的方式，为我迅速解决一个个技术难题提供了充分的理论基础和弹药。
不久，我就接到了入职以来的第一个挑战任务：重构一段专线时延测量代码，为配合业务架构的云化转型，将代码从C++重构为Java。这个任务的难点倒不是C++和Java编程语言的转换，毕竟只要会看C++，就会写Java。难的是重构前后的运行模式不一样，重构前是主备运行模式，重构目标是多实例运行模式。我们需要考虑很多复杂的因素，比如如何协调多个实例的数据，如何避免实例之间的冲突等，我思考了很久，但是仍然感觉毫无头绪。
我坐在屏幕前，手指用力地敲打键盘，脸上满是焦虑和疲惫，桌上凌乱地摆放着多实例的书籍和一堆笔记本。
无奈之下，我沮丧地找到师父，“师父，这个时延测量多实例场景下怎么协调啊？”
师父淡定地微微一笑，“你试着从多实例里选一个老大出来，由它统一协调，我们之前用的分布式定时任务框架能实现这个功能，你先去研究下”。
我迫不及待地拿到定时任务框架代码，利用清晨的时间去研究、琢磨，原来选老大的专业术语是“选主”，从而实现分布式场景下的协同调度。通过学习分布式的调度机制和反复试调试，我终于在半个月以后写出了多实例运行代码初稿，那一刻，强烈的成就感瞬间涌上心头。
此时的我以为已经完成了80%的工作，胜利在望了。但进一步调试才发现性能有10%的劣化，代码运行速度明显变慢了。
依稀记得最开始领任务的时候师父提过“性能不劣化”，于是我怀着忐忑的心情询问师父，“重构以后性能劣化有很大的影响吗？”
“小伙子你要有点追求呀，重构以后起码要性能倍增吧。”师父的话让我有些沮丧，一开始我就没考虑性能，没想到写个代码要考虑的事情这么多，哎，软件编码真不是简单的事。
我反复对比重构前后的代码，研究了几天都没新思路，该怎么解决性能劣化的问题呢？
回家的班车上，我微闭双眼靠在座椅上休息，突然间一个想法迸了出来，“异步编程在大量等待的场景下可以提升性能”，那把这个等待换成异步的行不行，性能问题是不是就迎刃而解了？回去的路上我一直在构思怎么异步编程，怎么优化性能。
通过不断地调试，我发现异步改造带来的性能提升远超我的预期，整体提升了20倍。后来我才知道性能劣化的原因是重构后配置的并发线程太小了，但异步带来的提升比增加线程要大得多。直到今天，NCE-T的网络管理规模提升了好几倍，当初重构的那段代码却一直坚挺地运行在世界的各个角落。
买车之后，我已经很久没坐过班车了，晨读也变成了挑灯夜读，但我在通勤路上思考和总结的习惯一直保留着。一年的晨读教会了我坚持学习和思考，就像班车一样，不论刮风下雨，它都在那。
02
新的机遇，质的蜕变——初露光芒
人生总是充满了奇奇怪怪的际遇，我的师兄就是我难得的际遇。
师兄是社招的软件高手，比我早入职两个月，胖胖的，因为我俩是同一个导师，便一直以师兄弟相称。他之前在某互联网大厂待过，因为看了我在朋友圈分享的Github上的个人项目，总觉得我是个大佬，还老觉得我在谦虚，怎么解释都没用。自从师父“奔向新生活”后，便是师兄在带着我一路摸爬滚打。
“这个SQL性能优化的问题你来处理一下，师弟。”
“我不会啊，没搞过SQL优化。”
“先试下，搞不定再找我。”
师兄因为“软件高手”这个头衔，经常有奇奇怪怪的疑难杂症需要他帮忙处理，他就像一把筛子，那些对他来说小儿科的问题，就会从筛子缝里漏到我这里，但对我来说却是一个个的“技术难题”，比如SQL性能优化对我来说完全是一个全新的领域。
在零基础的情况下，我只能采取最笨的办法，穷尽不同的SQL写法，然后分别测试记录执行耗时，哪个耗时短用哪个。尝试了几次后，我觉得这个过程还挺有意思的，对背后的原理也越来越感兴趣。“性能最优了吗，再快点，能不能再快点？” 在不断探索优化的过程中，追求极致，达成最优解。
当然探索过程中也有屡次试错但都得不到结果的情况，师兄会像天神一样及时降临，为我指明前进的方向。最长的一次，我们花了整整一天的时间研究SQL，其间不断查阅SQL执行的过程、索引机制，紧锣密鼓地探讨、实践，最后攻克了难题。最后我发了一篇 “萌系的SQL优化之路”的博客，算是入了门吧。
我总是能从师兄那领到让我束手无策的任务，“师弟，这个内存溢出你看下吧”“这个服务启动失败，你定位下原因”。一次次的尝试让我从对未知的恐惧，慢慢到适应，再到对未知的渴望，觉得软件世界还有大片的领域等着我去探索。经验的积累，让我后来也算得上是个疑难杂症定位的小专家了，但师兄对我最大的影响却不仅仅在此，而是在对我代码的严格要求上。
“这个需求我写完了，师兄，有空帮我检视下呗！”师兄当时是我们团队的Committer（代码准入官），代码上库必须要过他这一关。
“好，晚上看下。”
“那我撤了，今天的班就上到这里吧！”我起身伸了个懒腰。这个需求代码终于做完了，闷头编码一个月，感觉写得也还不错，严格符合“编程规范”，接下来合入就行了，我也是松了口气。
“代码还算整洁，但设计上还是要好好打磨打磨啊，比如这里就重复了……”
第二天一到公司，师兄就指出代码里不合理的地方，本以为可以一次性过关，结果被提了十几条检视建议。听完师兄的详细讲解，我脑子里反复思考的是为什么我之前考虑不到这些点，代码能够调通不代表是最优的代码。在师兄的指导下，我尝试使用设计模式去解决代码重复和可扩展的问题，反复修改了一周代码才合入，修改后的代码确实更整洁。
除了学会了用设计模式解决问题，我当时更是暗自做了个小决定——绝不直接交付自己写的第一稿代码，要换位到读者的角度再调整一遍。好在我写代码很快，之前在软件特战队实训中学到的小步快跑、快速迭代的方法开始发挥作用了，配上单元测试，反复优化也没有影响我的交付进度，日复一日倒是养成了“代码洁癖”。一年之后我也成为了一名Committer，接近苛刻的要求，让我也成了不少同事的“噩梦”。
那年，我获得了光产品线的金码奖，作为新人中的黑马，也老被师兄念叨“师弟不得了了啊，这是要超越师兄啊”， 每次我都是真心地说“都是师兄教得好，一直帮助我成长”。在一次公司直播活动中，有同事问我作为入职一年的金码奖得主，有什么秘诀可以分享给大家的，我答道：“我很感谢七点半的班车，让我一年读了八本编码相关的专业书籍；我很感谢我师兄，让我从书本走进了现实代码世界。我很感谢软件学院与软件特战队，通过集训、专家面对面交流，让我对软件工程有了整体的认知。”
03
团结一心共成长——熠熠生光
我本来以为，会以编程高手的身份过完我的职业生涯。但是领导似乎并没有这样认为，如今我明白了这叫做 “逃出舒适区”。
2021年5月中旬，我刚刚火急火燎地完成了上一个版本的交付，忙里偷闲时在研究陪产假可以休几天，突然闪现了一条来自主管的消息。
“这是要约谈吗？”我的小脑袋瓜开始脑补了，“现在还不是升职加薪的节点，最近我好像也没犯什么错误吧，这是要找我聊什么呢？”我没琢磨透，喝了一口水，清了清喉咙，有些惴惴不安地走进了主管办公室。
一顿寒暄之后，主管开口说：“架构融合重构项目里，组建了很多个微战队，有个团队缺少PL（项目组长），你感不感兴趣？你代码写得好，技术强，很适合搞重构。”我犹豫了会儿，回答：“我可以，但等我休完陪产假吧。”其实我内心是想拒绝的，自己不擅长干PL，而且还是一个完全陌生的团队，真的可以说是背井离乡了。不过我想领导是看中我的能力，才让我担此重任，就答应下来了，也算被提拔了一把吧。
架构融合重构项目的目标是通过架构和代码重构，完成业务模型和业务发放流程的统一性，为后续网络层架构打下基础。这个团队中，除了软件教练、Committer和SE（系统工程师），其余都是刚入职不到一年的新人，当大家喊我“健哥”时，听着挺舒服的，毕竟以前组里都叫我“小健健”。
刚加入团队的时候，存在最直接的问题是交付进度滞后和加班强度过高，这也是PM（项目经理）所关注的重点。为了弄清背后原由，我学着当时部长刚来时的做法，轮番请兄弟们吃饭，结果第一顿饭就吃得我满头冒汗。
“健哥，你一个金码奖得主，怎么想着来我们这儿？我已经一个月没有好好休息过了，每天的事情都做不完，时间完全不够用。”
“真的假的？”我第一反应就是吃惊，来之前主管也没跟我讲过这个茬，一下子我就感觉自己被“卖”了。
经过一周的摸盘，我差不多摸清楚了团队的情况，进度滞后仅仅是表象，大致的原因有三点：首先是分配任务时，能力强的人比较喜欢和能力强的结对，互相配合开发效率高，新员工只能相互配对，总体能力自然就差了一截；其次是每个人处理的业务场景类似，同一代码往往重复开发；最后，尽管新员工能够快速完成编码，但代码质量往往无法达到软件教练和Committer的要求，代码上库时需要耗费很多精力进行修改甚至是返工。
如何合理地划分阵型，达到以老带新的目的，在不断提升小组成员软件能力的同时，还能通过一定的技术手段来提升开发效率，成为了当前团队最大的难题。
我正在为如何打造好自已的团队而烦恼的时候，在一次研究所组织的绩效教练培训中，有关愿景共创的一段内容触动到了我，我好像从来没有问过兄弟们想要什么？项目做成后想成为什么样的人？后面我还听了《教练之道》的课程，这才知道原来带领一个队伍有这么多的学问，PL难干，好像是正常的，并不是我一个人会面临的问题，当时心里就轻松了几分。
部门也组织了一些沙龙，我开始积极参与，经常会跟大家一起交流学习。回去后，我问了自已一个问题：时间都去哪里了呢？我上午检视代码，下午帮兄弟们改代码，晚上写代码。当我问兄弟们你们的时间都花哪里去了？为什么每天加班那么晚？他们回答我说：“健哥，尽管我们的代码是写得挺快的，但是每次代码上库时，教练就会给我们提很多检视意见，写代码也许只用了2天，但是改代码可能要改3天。”
通过学习和交流，我们首先要打破强强联合的问题，实现以老带新，均衡工作难度和压力。但我考虑到贸然打破原本的合作关系，大家内心可能会抗拒，所以在调整阵型之前，我举办了一次民主生活会，会上进行了愿景共创，输出了团队导向（团结协作、技术为王、高质交付）、画像和愿景（团结一心共成长，技术为王我最强），并在此之后调整了作战阵型。
当时我还在想，自己在PL的位置上能做什么，发挥什么作用？我面临的问题是兄弟们不知道怎么写代码，不知道怎么做重构，我就想着我们每天花一点时间，让教练给我们讲，我们的代码上库到底应该写成什么样子？让教练给我们讲透彻，我们再讨论怎么改。
后来就有了我们代码检视的会议，在一次会议中，一位同学提出了建议，就是每周组织一场代码集中检视的例会，在会上大家一起讨论共性问题，集体学习，达成一致，大家都去遵循，尽最大可能避免低效的PK，以及代码上库前的返工。
我觉得是个非常好的主意，但改变总是痛苦的，执行起来就没那么简单了。第一个阻力是明明约好时间一起讨论，有些同学因为交付压力比较大，不愿意参加。所以软件教练定了一个规则，为了提升大家的参与度，请假不参加的同学需要请全组喝一杯暖心的奶茶，一来二去参与度就100%了。
会议开始之前，大家有一周的时间去主动登记需要讨论的问题，问题可以是自己不确定的方案、之前设计可能存在的隐患等，在集中讨论时，能在很大程度上拉齐大家的想法，最终达成一致之后就按这个执行。代码共性问题与坏味道识别，这个环节是把本周代码检视中的共性问题拿出来学习一下，避免相同的问题反复出现。
这个会议逐渐变成了交流分享会议，最开始主要是我和教练讲代码怎么写，单向去传授。后来大家发现这个会议能真正解决他的问题，也不会再请假了，提的问题也越来越多了，我和教练都解决不了了。接着我们又制定了一个规则，就是在会议上解决不了的问题，指定一个人去研究学习，在下一次例会上给大家分享，形成了一个学习分享的氛围。
有一次跟武研张继超所长交流时，他问：“你带队伍可以把自已的优势发挥出来，你的优势是什么？”
“我平时喜欢看书，所以我的技术比较好。”
“那你能不能让你的团队像你一样，多去看看文章看看书？”
于是我把这个想法带回去了，跟大家讲，大家说“可以试一下”。最开始我们是每周找2个人去看两篇文章，写一下自已的收获和推荐理由，后面作为固定议题每周例行分享，形成了我们自已学习分享的方法。被我们总结为ARTS学习法。ARTS是针对能力提升提出的学习计划，A是每周要做一道算法题，R是每周要读一篇文章，T是每周学习一个技术点，S是分享。S是最后的点睛之笔，不管是算法题、文章还是技术点，都是要分享出来的。后来，这个方法推广到了整个部门。
最后，我还希望能把公共的能力建设出来，避免工作重复。为了提高代码的复用度，发挥自已的代码优势，我先帮助大家提取了一些高频率使用的代码，封装成框架或者工具，提高效率。当我在晨会上提出这个想法时，组里一个成员很惊讶地说：“天啊，PL还需要写代码吗？”
“难道不写吗？”我也被整蒙了。
“我以为不用写的，如果健哥能教我们写代码那是多好的事啊！”
于是我当时暗暗下了决心，作为PL其他事情能不能做好我不知道，但教会这帮新人写代码是必须要做到的。我凭借自己较强的编码能力，将封装框架CBB代码很快提取出来，在小组中推广应用，让大家的编码效率都大大提高了。
很长一段时间里，我不停地在各个工位间轮转，帮助大家解决问题，分享这几年来我的积累，乐此不疲。
为此，在软件技术上，我们使用AOP（面向切面编程）的编程方式，将业务逻辑和控制逻辑做了分离，控制逻辑基本都是相似的，在此之上我们推出了自己的公共二方库。在业务知识上，实现资产固化，及时总结，打造业务知识库，放入NCE-T知识社区统一管理。
半年的时间，重构项目如期达成，完成了TR5验收，完成了20万行代码的底层架构重构，打造了NCE光网络层业务的样板间。这个重构项目获得了产品线最佳重构项目奖。我们在过程中提炼的软件框架成了Rainbow开发平台的核心底座，也让我站上了金牌奖的领奖台。我曾认为只要我的代码写得够快、够好，就能解决一个又一个的问题，但面对百万、千万行代码的软件系统时，使众人行，才是王者之路。
好的团队永远离不开一个好的氛围，不论是学习氛围、娱乐氛围，还是战斗氛围，在一个好的氛围下，队伍才能健康地去迭代，去成长。在年前的最后一次聚餐上，软件教练给我们团队点赞，兄弟们一洗旧时疲态，举杯相庆，每一句掏心窝子的真心话，都让我觉得无数个日日夜夜是值得的：“健哥，你天生就是当领导的料！”“健哥，我们愿意一直跟着你干！”“健哥，在你带领下，我们是最棒的！”……
PL转身，我做到了！
04
平凡而光明之路
我一直认为“码农”的工作过于平凡，不能像摄影师那样领略大山大海，不能像运动员一样汗洒国际赛场，也不能像宇航员那样挣脱地球引力。
但回头望去，我已经走了很远的路。从编程菜鸟到软件高手，获评十佳Committer；从单兵作战到组建微战队，专门解决技术难题；从听众到站上ICT软件大会的舞台，分享领域驱动应用架构模式……
“做好每一件小事”，这是当年总裁给我的答复，这也成了我在华为做事的原则，刻在了我金牌奖的奖章上。我仍旧是个平凡的工程师，但那一行行不平凡的代码，却运行在世界的每一个角落，打造了无处不在的光联接，带着这个万物互联的智能世界向前走。
这条“光明而平凡之路”，就这样走，一直地向前走。
▼
蓝血研究院近期公开课
免责声明：以上内容为本网站转自其它媒体，相关信息仅为传递更多信息之目的，不代表本网观点，亦不代表本网站赞同其观点或证实其内容的真实性。如稿件版权单位或个人不想在本网发布，可与本网联系，本网视情况可立即将其撤除。
营业执照公示信息