腾讯程序员：从做管理转回写代码，我所理解的工程师文化

如何实践工程师文化带领出一群靠谱的程序员，并在不确定性的条件下争取成功，是过去几年我在持续思考的事情。团队的工程师文化能不能提升成功的确定性，一定要有吗，它来自哪里，又能带来什么？本文尝试解答这些问题，并期望通过更系统和全面的解剖，可以减少有极致追求的程序员们的纠结和内耗。

关注腾讯云开发者，一手技术干货提前解锁👇

01、契机

高价值的成功具有高度不确定性，相比靠谱的个人和团队，时代的趋势以及产品顶层战略的设计是更大的决定性因素，但这两通常不是个体和小团队所能控制的。在这个前提下，我期望在我们能控制的范围内做到极致，以尽量提升成功概率。一年前写的《如何成为一名靠谱的程序员：职业素养入门指南》、《代码写得好，绩效却不高？程序员的沟通和思考有多重要？》引起不少程序员的共鸣，我一直还期望能从团队视角阐述我们能做的最大努力，将程序员们的确定性事项拼图完整。

最近一年因产品萎缩，我经历两次较大的组织调整，最终在半年前解散小团队并离开了基层管理岗位，在新组织半年左右的时间里，对项目成功也有更深刻的思考，有更高层次的认知。本文一些基干视角的内容，主要来自之前负责《中台已死，平台长青》和 QQ 浏览器搜索基础架构时的积累，但更多的内容还是来自一名热爱编程、追求极致的程序员的日常思考。

02、我们遇到的挑战

让自己成为一名靠谱的程序员是一件简单的事情，它有明确的路线图，而让一个团队都成为一群靠谱的程序员，则稍显复杂，大家的认知有高有低，经验有深有浅。我们先来看一些案例。

2.1 失去写代码的乐趣

小 A 是一名热爱编程的年轻程序员，但最近从代码中获得的乐趣越来越少，他感到一丝倦怠。几个月的冲刺，他做了很多需求，写了很多代码，每天过着朝 9 晚 11 的充实生活，但项目的成功也没有冲淡写代码时的紧张和迷茫，这是之前他不曾遇到的。写代码是确定性 100% 的事情，但最近总是出现意想不到的效果，他写出了几次线上小事故，在周围的同事看来，出现一些小事故是很常见的事情，他的领导也很宽容，但他感到很自责，更重要的是他失去了写代码的乐趣。

2.2 沉浸在事务性工作的舒适区中

小 B 是一名勤奋的程序员，他对工作充满热情，每一天都过得很充实，今天他又接入了几个团队的业务数据，这里有很多细致的工作：配置业务数据的格式映射，申请设备资源，部署后台服务等等，需要各个平台的人沟通协调，他极限发挥自己的多线程并行工作能力，一天下来疲惫而充实。坐在安静的深夜班车上，他不禁思考：每天这样的工作当然是有价值的，但对我来说是有挑战的吗？

2.3 我们一直是这样做的

小 C 接手一套祖传系统，这套系统还用着二十年前编译环境，做起需求来缓慢和低效，他问之前维护这套系统的同事 X 为什么不升级？小 C 和 X 来回聊了很久，各种各样的原因，最后一句是：“又不是不能跑”。小 C 很纠结，接手过这套系统的每一个人都没有去改造它，我应该改吗？

2.4 稳定的协作关系和不会骑马的骑兵队长

小 D 是一名经验丰富的后台开发工程师，在接到某个新产品需求时，他发现之前的协作分工模式不高效，客户端无论是当前还是未来，都只需要后台提供简单的数据存取能力，但后台按照之前约定的协作分工，却要拆分为两个服务由两个团队负责，X 团队负责开发 nodejs 服务提供 API 接入，Y 团队负责开发 C++ 服务提供 DB 的存取，他提出这类简单的需求应该在 nodejs 服务里搞定，效率更高，但这个建议却陷入了争执，部分团队不想改变协作模式，最后大家一致认为需要更专业的人来裁决，于是由共同的领导来做决策，但这位领导却没做过后台业务系统，并且已脱离一线架构和编码多年，本着团队稳定的原则，他维持原来的协作模式。

2.5 我们是创业团队

小 E 是一名技术实力很强的工程师，最近被抽调到了新团队继续做业务系统开发，他熟悉业务的过程漫长而痛苦，很多定制的业务信息没有文档，代码混乱且到处都是看不懂的补丁策略，问周围的同事，他也忘记了。这已经是发展了多年的大团队了，怎么大家都不写文档，代码质量也挺低下呢？周围的老同事告诉他，我们是永远在创业的团队，没有时间写高质量的代码和文档。小 E 很困惑，创业精神和代码质量是一对矛盾吗？

以上种种案例，我们总会遇到一些，我们会疲惫、困惑和不满，这是不良的情绪，但却是挺好的事情，意味着我们看到了问题，我们不甘沉沦，如果你正好也有解决的办法，那可以享受解决问题的快乐。如果你没有，那也要恭喜你，下面我的思考和实践可能对你有帮助。

03、我们的终极目标

我们的终极目标不是建设一支有工程师文化的团队，它只是过程，只是成功的加速器，我们的终极目标是持续成功。一个高效务实的团队，更能实现我们的终极目标，而工程师文化是高效务实团队所展示出来的特质，所以我们才追求工程师文化。

文化是一种朦胧的感觉，它只有在我们做事的时候，才能感受到它的存在和力量，下面的章节，我会从团队共识、代码文化、效率意识、自我成长等方面讲解我对建立团队工程师文化的思考和实践。

04、建立团队共识

2019 年我们刚开始做搜索中台的时候，CodeReview 执行得很辛苦，部分同事 CR 流于形式，或者没有能力 CR，又或者不给 CR 安排时间。后面我们设立一系列的规范和配套工具，在团队建立“写好代码”的共识，并由我和模块负责人带头严格执行 CR。我几乎 review 过核心项目的每一行代码，之前在内网回答其他人提出的 CR 推广困难问题时，曾记录到我 2021 年发出 1800+ 条 CR 评论。建立共识，CR 的情况才慢慢好了起来。如果没有写好代码的共识，我们不会投入时间，有追求的程序员也会忙于说服他人而筋疲力尽。不仅仅是 CR，在团队的方方面面都需要有共识，这些共识就是团队的工程师文化和凝聚力所在。这下面我从导向和细节两个层面来介绍我是怎么建立团队共识的。

4.1 团队导向

在我们做事之前，需要先了解团队做事的行为准则，它是对错的标准，是指南针，它不一定是每个人认可的做事方式，但它是集体的标准，需要无条件执行。通常越大的组织，导向会越抽象和泛化。譬如：我们公司的“用户为本-科技向善”，BG 层面如 WXG 14 年发布的 7 条价值观。到一个小团队内部，通常会更细致，譬如，2020年左右我给小团队设定的导向：

• 执行和创造
  • 按部就班执行得好是底线要求。
  • 做事有思考，不做“提线木偶”。
• 协作
  • 积极，要有沟通协作意识，及时反馈，积极推动。
  • 高效，沟通方式高效、逻辑清晰。
• 分享精神
  • 鼓励积极编写高质量技术文档。
  • 鼓励多种方式的分享知识。
• 持续进步
  • 个人、团队、产品、代码和架构，都是可持续改进的。
  • 不固步自封、不得过且过，对一切高标准高要求。

前面提到，我们的终极目标是持续成功，而成功只有 YES 或者 NO，看不见过程就无法评判路径是否高效，也无法优化，因此我们需要去看更细致的过程，并让过程持续改进，成功才有持续的保障。为什么会设立这四个导向：

• “执行和创造”，你完成了一个需求，这是一种成功，剖开完成过程，发现导师给你设计了方案，而你只是做执行，或者是说你最终完成了需求，但和你协作的同事给你做了很多的辅助，那这个成功的含金量就较低了。很多同事执行能力很强，但创造力稍弱，这条规则，期望让大家看到执行好只是底线，能创造才是优秀。
• “协作”，有些程序员眼里只有自己的核心项目，和他人配合工作的事情，就推三阻四，或者是有些人理解能力偏差，一个简单的需求要花很大的精力让他理解，这些人即便能把需求做出来，也是需要大幅度提升心态和能力的。
• “分享精神”，利他是很难得的精神，如果做成了一件事，又有利他的分享输出，是我们要鼓励的。同时分享精神，也有利于建设个人和团队的品牌，这对他个人成长和团队品牌建设都有好处。
• “持续进步”，个人、团队、产品、代码都是可以成长的，这是一种开放心态，拥有这种心态的人，会持续的改进，更有机会获得持续的成功。

4.2 细则共识

团队导向是抽象和泛化的，到具体执行层面，需要可执行的步骤，否则容易沦为喊口号，它可以是强制流程，也可以是一种提效方法。譬如我就整理过很多这类流程制度：

• 《需求开发标准流程》，以公司内的 tapd 为信息同步载体，串联从需求提出到发布上线全流程。
• 《XSearch 代码评审手册》，设计代码合入主干之前的评审制度，让 CodeReview 变成固定的环节，确保代码质量和系统稳定。
• 《XSearch 新手开发环境配置》，建议采用的统一研发工具和代码格式。
• 还有很多，不一一列举。

导向指引和执行细则是我们程序员团队的“法律条文”，让我们减少非必要的讨论和内耗。在落地执行时，最好是大家都能理解和执行，但大家的工程师素养参差不齐的，写好代码超出一些人的能力范围，因此有时候需要团队一把手的强力支持，并有节奏的推进。没有一把手的支持容易沦为表面功夫，而操之过急则容易给团队日常需求迭代带来太大压力，导致主次颠倒。

05、找回写代码的乐趣

解决问题是件快乐的事情，用代码解决问题也是。如果你感到不快乐，大概你遇到了一些不正常的现象。譬如上述 2.1 例子中的小 A，如果每次改代码、发版本都要精神高度紧张，时刻提防八竿子打不着的地方出故障，内心是不可能对写代码产生乐趣的，只会有畏惧，最后变成了厌恶。

以前我们的团队接手过多套老系统，多数时候也会碰到和小 A 类似的情形，甚至更严重。譬如 22 年底接手搜索内容架构，每天收到成千上万的告警消息，大家忙得焦头烂额，无法根治系统稳定性缺陷的同时，还需要继续承接新业务需求，而新业务又继续暴露系统缺陷，陷入不断恶化的负反馈，没有人有信心去承诺系统稳定性和需求交付时间，团队的口碑和开发者的信心都处于崩溃边缘。但我们还是度过了这个阶段，并输出两篇分享《如何避免旧代码成包袱？5步教你接手别人的系统》、《微服务回归单体，代码行数减少75%，性能提升1300%》，详细介绍我们是怎么接手并改进复杂老系统的，在做事方法层面，最核心是建设一套可持续运转的研效流程。

这种做事方法我们在多套老系统上做过验证，即便在团队最后的一两年里多次被动拆散重组，我们也能保持攻坚能力，设计清晰的系统，写出简单的代码，从代码中找到乐趣。下面介绍这套方法论的核心：流程、工具、人。

5.1 建立流程制度

流程制度也是团队共识，前面第四章我笼统描述了我们要建立团队共识，本章节聚焦在代码层面做更细致的介绍。每个产品都有研发流程，不同时期有不同要求，产品时期和研发流程不适配会带来各种乱象。譬如，在做 MVP 产品的“小黑屋”团队，去做细致的 CR、限制上线时间、严格执行 case review 等等，最终收获的可能是高质量的废弃代码和高稳定的 0 流量服务，这失去了做事的意义；而在稳定时期，没有严格的代码审查，可能导致线上事故频发，进而影响产品效果。举两个我之前建立流程制度的例子：

• 做搜索基础架构时，我们日常的研发流程：

技术方案评审、单元测试、CodeReview、文档建设，确保代码和系统是可持续发展的。

• 接手老系统，我们也有一套流程：

这套流程让我们能先稳住系统，然后逐步改进。

• 在做探索产品时，我们也有一套研发流程：

需求 --> 开发 --> 合入 master --> 发版。不需要单元测试，不需要 CodeReview，更没有文档，需求也是口头沟通的，这是“小黑屋”的 MVP 时期，产品的时间周期很短，不需要考虑长期主义，此时极短时间内的“快”更重要。

研发流程应该跟随产品发展而演进，避免教条主义和经验主义。当产品有多人参与，要持续迭代数个月以上时，就不能和 Demo 产品使用同样的研发模式，否则产品会有体验不佳的风险，开发者也会失去写代码的乐趣。

5.2 搭配自动化工具

工具保障流程能顺畅落地，只有流程没有配套工具，流程就会非常依赖人的自觉，这是不可靠的，流程只会沦为弄虚作假的口号。我们使用和建设了这些工具：

1. 统一的开发环境
   • 统一开发镜像，避免人员在切换开发服务时，切换镜像和开发语法带来效率损耗。
   • 统一开发 IDE，方便好用的开发插件的分享传播，对新人友好。
2. 统一的工蜂仓库配置
   • 保护 master 分支，代码经过评审才可合入。
   • 规范分支和 tag 命名，便于查 case 追溯。
   • 规范化 commit 信息，确保信息可读，有条理。
3. 多种类型的蓝盾流水线
   • MR 流水线，提交 MR 时执行的流水线，涵盖代码静态检查、单元测试、接口测试。
   • 发布流水线：发布上线的流水线，执行固化的逐步灰度，减少人工误操作。
4. 大模型工具
   • 使用工蜂的 AI 代码评审和 Copilot，减少人工代码评审时的工作量。

5.3 选择合适的执行人

有理想化的流程设计和良好的适配工具，是实现研效进步的必要不充分条件，必须还有“人”。我们团队成员是使用工具执行流程的主体，如果我们“人”的因素跟不上，是没办法做好的，可能陷入“自欺欺人”的乱象，譬如前几年所看到的：

• 低质的文档：难以读懂，也没有组织，散乱在各处。
• 流于形式的 CR：永远只有一句评论——LGTM。
• 和业务脱节的“高效率”：技术研效指标很高，业务 case 层出不穷。

在我们看来，“人” 包括三个方面：能力、意愿、授权。

• 能力，他需要有能力去执行这套流程，譬如 CR，他必须是一直在做系统设计和代码编写的程序员，而不是那些具有高阶头衔的人。能力不是天生的，来自培训和实践，譬如 PCG 的技术战略中心做了很多培训的课程和鼓励宣导，这给我们带来很大的帮助。
• 意愿，他需要有愿意帮助他人提升编程技能、帮助项目代码更优雅的的利他心态。
• 授权，他需要得到足够的授权，可以给 CR 预留时间，可以只看代码不看职级的提评论。

团队一把手是最合适的执行人，在我们团队研发流程落地过程中，我带头执行了全流程，特别是那些需要做出改变的事情，由我先去尝试，我能感受到这里的缺陷，才能更好的改进流程，去创造一个舒适有安全感的写代码氛围，让团队的产出更靠近终极目标。

06、释放提升效率的天性

人类从使用石器到使用金属，再到各种高阶的工具，每一次变革都是在提升效率，而作为个体，我们从爬行到走路奔跑，再到各种交通工具的使用，也都体现出效率的提升。因此我认为提升效率是人的天性，但在一些不合适的文化氛围下，我们抑制了天性。譬如，前文例子中的小 B，他重复的点鼠标、填配置、拼 SQL，日常繁忙的工作和过去的经验习惯，让他很少能去思考怎么用“智力劳动”替代“体力劳动”。再有前文例子中的小 C，他意识到有更高效的编译环境，但“又不是不能用”的周围环境也阻碍了他的发挥。我认为务实的团队，应该营造一种提升效率的文化，去释放人的天性，我们天生就是爱偷懒（提效）的。下面介绍我们是怎么做的。

6.1 开放和平等

前文中例子里的小 D，他提出来一种更高效的做事方法，但协作的人却因为地盘意识而不愿意做出改变，上级领导也不懂技术无法判断，最终采用了“稳定”的决策，这个需求对于整个产品来说是一件小事，但这对突破传统、鼓励创造的文化是一种打击，如果好的想法得不到认可，那以后也不会有更好的创意出现。这个例子从协作者角度，我们看到的是封闭的做事态度，这种态度除了来自地盘意识，还有很多其他类型的，譬如，停留在过去的成功经验，无法与时俱进的成长；对新的人员、新的技术、新的方法论持排斥态度等。这个例子也反应出来不平等，尽管决策者的职级更高，但他不应该在他不擅长的领域做决策，本来是一个技术问题，他按照管理问题来做决策，技术面前应该平权，由懂得更多、思考得更深的人来做决策。

6.2 保持在线和思考全局

“保持在线”对大多数程序员来说是很简单的事情，只要他愿意，任何头衔的人都可以做一些简单的、基础的工作，但我们也经常见到不愿意“弄脏自己的手”的高阶程序员，更愿意在高层思考，而不愿意做一些基础事项，确实更高层次的思考是高阶程序员最能发挥价值的地方，但如果不能深入一线，可能错过很多高价值的创造。很多年前我经常听到产品经理的领导说，“产品经理需要体验产品，如果你连自己做的产品都不体验，是不可能做好的”。对产品设计者提这样的要求我们都觉得很合理，而对程序员群体，我们很少听到这样的要求，我觉得我们也应该有同样的要求：体验自己写的代码、体验自己设计的架构、体验自己做的平台、体验自己的文档...总之，保持在线。

“思考全局”则不是那么简单，但也不是难以做到，给项目设计留更多的时间、导师给予更多的指导，都是能提升全局思考的因子，除了这些常规因子之外，我觉得最重要的一点是“透明”，组织各种决策信息需要透明，方便大家阅读和学习，团队成员可以了解到更广泛的信息，才能站在更高的位置考虑全局。

当我们在谈某个系统可以怎么优化以提升效率的时候，最好是你真的用过这个系统，否则很可能陷入空谈，或者以过去的经验来优化现在的系统。当我们在做某个局部优化时，又应该看到全局，否则得到的可能只是局部最优。那些脱离一线又很有全局观的人，可以称为“不会骑马的骑兵队长”，那些深入一线又不会全局思考的人，可以称为“不想成为元帅的士兵”，这都不是务实的工程师团队所鼓励的，我们需要鼓励那些保持在线又能思考全局的程序员，去释放他们做出更大贡献的热情。

6.3 利他思维

我们在提要求或者评价他人时，经常讲到团队协作，我觉得更高层次的东西是“利他”。今天小 A 和我合作一个项目，我们沟通接口、联调项目都很顺利，最后项目顺利完成，我们感觉小 A 很高效，这时候我们会评价小 A 是“善协作”的，但我们不会说小 A 是“利他”的，还没有到那个层面，他只是完成自己的本职工作。如果小 A 设计的接口既给本项目使用，也可以给未来的项目使用，并且他还写了高质量的设计文档、接口文档，我会觉得他符合“利他”标准的，他做事情不仅仅着眼当前和他利益相关的项目和人，还考虑了本项目之外的事和人，这时候我们对小 A 的评价会更高，他长期做下去，就会形成自己的个人品牌。

利他既可以提升个人品牌，也可以提升团队的效率。譬如，我们写新人入门文档，团队的新人上手会更快，提升团队整体的效率，而且好处也不仅仅是新人入门效率，它可以帮忙我们较少的去考虑某些事务性的工作要怎么做，我们可以把思考的精力更多放在有创造性的事情上，这对营造团队的创造氛围是有利的。

从利己的角度讲，我们的工作是无限次囚徒困境，而这种困境又驱使我们变成利他的，我们想要建立自己的品牌、想要获得更多可持续的收益，因此利他团队的氛围也是可建设的，利他的团队可以进入利他的正循环，好的架构、好的文档、好的体验都能成长出来，这也是我们提升团队效率的天性。

07、自我成长

团队管理的教材通常会建议管理者或者导师要定期和下属交流，要当教练引导下属成长，这些显然是有价值的，我也这么干。经过很长一段时间的实践之后，我发现成长更重要的还是程序员的自驱，不是上级或者导师的指导和推动，指导只能是在现阶段让他能做一些对项目、对自己有利的事情，过了这个阶段，很多人还是回到他本来的自己。譬如，我期望小 A 能写高质量的代码，在高频辅导和相关课程的支持下，他确实能写挺好的代码了，但是他也就仅停留在写好代码这个环节，其他与时俱进的知识还是需要其他人去指导，被指导和自我成长不是矛盾，但我们会更期待有自我成长意识的人，这样的人才更有创造力。

务实的程序员团队是追求自我成长的，我们不希望遇到那种需要持续手把手教才能做好事情的人，这样的人缺少创造力，而创造力才是程序员能产生最大的价值的点。什么样的人才算是能自我成长呢？可能是聪明的、能坚持的，有很多特点，我觉得最重要的点是“热爱”，愿意花更多的时间去锻炼自己的技能，可能是去做代码练习，或者是去了解行业趋势，甚至就是在工作中投入更多的业余时间。当团队里有越多自我成长意识很强的同事时，大家互相分享新的技艺，在学习和分享中获得成长的快乐，团队也更容易产出新的想法。

08、顺势而为

以上便是我对建设务实的工程师文化团队的思考和实践，是过去我们团队建设技术产品、做基础设施的经验总结，经过多次项目验证，我认为是比较高效的团队做事方法，但当一个团队做到了这些时，它仍然可能是失败的。因为这些方法论只是高度不确定性的成功里很小的一个因子，如果用一个三位数来为成功的可行性打分，时代的趋势是百位、产品的战略是十位，而做事方法只是个位数。我们程序员团队尽全力去营造的工程师文化，也仅仅影响到个位数上的打分，因此，“它其实没那么重要”，如果它不能成为自然而然的事情，那么也不一定要去勉强，你可以减少日常工作中的内耗，你可以把精力放在最重要的事情上，有时候它是产品的创意思考，有时候它是一套简单的系统和清晰的文档，甚至有时候它是什么事也别干。

-End-

原创作者｜吴银光