1. 什么是好的工程文化从一次讨论说起前几天翻看一些老资料又看到了EE Times在2012年那篇关于工程文化的文章里面提到了当时在Quora上很火的一个帖子“什么造就了好的工程文化” 发起人Edmond Lau一位在Google、Ooyala和Quora都待过的软件工程师基于数百次面试中听到的年轻工程师对前公司文化的吐槽和赞美总结出了他心中的“十诫”。这个话题虽然过去了十多年但里面提到的每一点放在今天任何一个涉及复杂产品研发的团队里——无论是搞芯片设计、嵌入式系统、消费电子还是互联网服务——依然像一把精准的尺子能量出你团队的成色。好的工程文化不是墙上贴的标语也不是老板喊的口号它是每天工作中那些让你觉得“顺”还是“堵”的细微体验的总和。是你能快速验证一个想法还是被流程卡上两周是你写的代码有人认真Review并提出建设性意见还是扔进去就石沉大海是你觉得在解决有趣的问题还是在不停地填坑和救火。这篇文章我就结合自己这些年在一线研发和带团队的经历来拆解一下这些原则背后的逻辑以及在实际工作中它们到底长什么样我们又该如何去建设和维护它。无论你是刚刚入行的工程师还是负责技术团队的管理者希望这些来自实战的观察和思考能给你带来一些实实在在的参考。2. 核心原则深度解析从“十诫”到日常实践Edmond Lau总结的十个要点看似分散实则紧密围绕一个核心如何最大化工程师的创造力和产出效率同时维持系统的长期健康与团队的持续成长。我们不能把它当成教条而是要理解每条原则试图解决的根本问题。2.1 迭代速度至上敏捷背后的信任与授权Lau把“优化迭代速度”放在第一位这直接击中了研发效率的命门。他举了Google早期的例子任何对搜索结果的用户可见改动都需要当时副总裁Marissa Mayer亲自批准。Lau认为这“严重阻碍了创新”。这个例子的本质不是批评个人而是揭示了一种文化陷阱当决策链条过长、过于集中时创新的试错成本就会变得极高。在实际工作中“优化迭代速度”远不止是买更快的编译服务器或部署工具。它是一整套思维和机制技术架构的模块化与解耦这是快速迭代的基础。如果系统像一坨密不可分的意大利面动一处而牵全身谁敢快速迭代好的架构允许团队在相对独立的模块内进行实验和部署通过清晰的接口契约来管理依赖。例如在嵌入式开发中采用硬件抽象层HAL和模块化驱动设计能让软件团队在不等待硬件最终版的情况下并行开发和大部测试。工具链的自动化与自助化工程师不应该在等待环境部署、权限申请、测试机排队上浪费时间。成熟的团队会建设自助化的CI/CD持续集成/持续部署流水线、一键式的测试环境搭建、以及完善的开发沙箱。比如芯片设计团队可能拥有自动化的设计流程检查Lint、单元测试回归和功耗/性能分析流水线工程师提交代码后自动化报告能快速指出潜在问题。决策权的下放与清晰的边界“给予工程师和设计师灵活性和自主权让他们无需请示就能做出日常决策。” 这句话的关键在于“日常决策”和“清晰边界”。管理者需要定义好“护栏”什么是可以自主决定的例如选择某个开源库的实现方式、调整非关键的性能参数什么是需要同步或评审的例如变更核心数据库 schema、引入新的长期技术栈有了护栏工程师才能放心踩油门。实操心得我们团队曾推行“两周迭代火车”模式。每两周一个固定发布周期所有功能按优先级上车。关键不在于“两周”这个数字而在于配套机制1产品需求必须在周期开始前完成细化并拆分为可独立开发测试的小任务2建立了自动化的代码合并与准入测试门禁3设立了“值班架构师”角色处理周期内遇到的需要快速决策的技术问题。这大大减少了会议和等待迭代节奏明显加快。2.2 自动化一切可自动化的将工程师从苦力中解放Lau的第二点是“不懈地推动自动化以减轻工程师的操作负担”。他认为自动化解决方案和编写脚本处理重复性任务之所以重要是因为它们“解放工程团队让他们能专注于实际的产品工作”。他还提到确保服务在故障后能自动重启是“大规模管理复杂性的唯一明智之道”。自动化常常被狭义地理解为测试自动化。实际上它的范畴要大得多基础设施即代码IaC无论是云端的虚拟机、容器集群还是实验室里的测试台架其配置和管理都应该通过代码定义。这样能保证环境的一致性、可重现性并且版本可控。新成员入职一键就能拉起一套完整的开发环境。部署与发布自动化手动登录服务器、上传文件、修改配置、重启服务是错误和事故的温床。自动化部署流程包括灰度发布、回滚机制能极大提高发布信心和效率。监控与告警自动化系统不会在上班时间才出问题。建立完善的监控指标Metrics、日志聚合Logging和链路追踪Tracing体系并设置合理的自动告警能让问题在影响用户之前就被发现甚至触发自愈流程如自动扩容、重启异常实例。代码质量守护自动化在代码提交环节通过Git Hooks或CI流水线自动运行代码风格检查如clang-format, pylint、静态分析如SonarQube、安全扫描如Dependency Check和基础单元测试。这相当于在污染进入主干之前就设立了过滤网。为什么工程师有时抗拒自动化常见的误区是认为“写自动化脚本的时间我手动都干完十遍了”。这是典型的短期思维。一个需要每天手动执行10分钟的任务一年下来就是40多小时。如果花2小时将它自动化投资回报率是极高的。更重要的是自动化消除了人为操作失误的风险。2.3 构建正确的软件抽象与保持代码质量Lau将“构建正确的软件抽象”和“专注于高代码质量并进行代码审查”列为三、四点。这两点息息相关都是关于如何管理复杂性让系统长期可维护、可演进。关于软件抽象抽象的目的是隐藏底层复杂性提供简洁、稳定的接口。好的抽象能大幅提升开发效率比如在嵌入式领域使用RTOS实时操作系统提供的任务、队列、信号量抽象比直接裸机调度要清晰得多。Lau提到Memcached、Redis等流行系统的可靠性减少了构建自定义存储的需求这背后的启示是优先采用经过验证的、通用的解决方案而不是盲目追求“自研”。当然这需要判断力。当现有方案无法满足特定性能、功耗或确定性时这在硬件相关开发中很常见设计一个贴合业务的自研抽象就是必要的。关键是要保持抽象的“简单”和“专注”避免过度设计变成一个无人能懂的“黑魔法”。关于代码质量与审查代码是团队的共同资产不是个人作品。高代码质量意味着可读性命名清晰结构明确意图一眼就能看懂。可测试性模块间耦合度低便于编写单元测试和集成测试。可维护性当需求变更或发现问题时能够快速定位并安全修改。代码审查Code Review是保障代码质量的核心实践但它不仅仅是找bug。一次好的Code Review是一次知识传播评审者了解系统的新改动作者可能学到更好的实现模式。一次设计讨论在代码落地前对架构和设计进行最后的校验。一次团队规范对齐确保代码符合团队的共同约定。Lau提到“知道代码会被他人审查会产生积极的同侪压力”这能有效防止“粗糙、难以维护或未经测试的代码”进入工作流。我们团队要求所有合并到主干的代码都必须经过至少一位同事的Review。Review的重点不是语法挑剔而是关注逻辑是否正确是否有足够的测试覆盖是否引入了不必要的复杂性是否符合项目规范注意事项Code Review文化容易掉入两个极端一是流于形式只会说“LGTM”Looks Good To Me二是变成人身攻击或吹毛求疵。必须建立明确的Review准则强调“对事不对人”鼓励提出具体、可操作的改进建议。同时要设定合理的响应时间期望如24小时内避免阻塞开发流程。2.4 共享代码所有权与营造建设性冲突的环境“共享代码所有权”意味着没有哪块代码是某个人的“私人领地”。这带来了多重好处降低“巴士因子”如果唯一了解某个核心模块的人被巴士撞了这是一个残酷但经典的比喻项目是否会瘫痪共享所有权避免了这种单点故障。减轻个人压力工程师不用担心休假时“自己的”模块出问题而没人能处理团队共同承担责任。促进技术交流为了能维护他人的代码工程师需要阅读、理解并可能改进它这自然促进了技术分享和最佳实践的传播。防止知识垄断没有人能通过把持关键代码来获得虚假的“不可或缺”感团队氛围更健康。Lau还提倡“保持尊重的工作环境”但这不等于一团和气。他想要的是一个“人们可以轻松挑战彼此想法”的地方。在技术领域没有建设性冲突的团队往往难以做出最优决策。如果因为害怕冒犯他人而不敢质疑一个可能有缺陷的设计最终代价可能是项目延期或系统故障。如何营造这种环境关键在于将“对观点的质疑”与“对人的尊重”严格分开。在技术讨论中习惯使用基于事实和数据的语言例如“我理解你想用方案A来提升性能但我担心它可能会增加内存碎片。我们是否有相关数据或测试来对比方案B” 而不是“你这个方案根本不行太外行了。” 团队领导者需要主动示范并维护这种沟通规范。3. 工程文化的基石测试、时间与人才如果说前面的原则更多关乎“如何工作”那么接下来的几点则关乎支撑工作的基础系统和文化土壤。3.1 自动化测试信心的安全网与重构的勇气Lau强调对自动化测试的投资因为它“为大规模重构提供了信心和有意义的保护”。这一点我深有体会。没有完备自动化测试覆盖的代码库就像一座没有消防设施的高楼谁都不敢轻易动里面的结构重构因为不知道哪里会冒烟起火。自动化测试应该是一个金字塔单元测试底层最多针对函数、类等最小单元运行极快是开发者的第一道防线。在嵌入式C开发中可以使用Unity、CppUTest等框架。集成测试中间层测试多个模块之间的交互是否正确。例如测试驱动层与HAL的接口或测试某个业务逻辑流程。端到端E2E测试顶层最少模拟用户真实场景验证整个系统功能。例如在消费电子产品上自动化脚本模拟用户按键操作验证从UI到硬件响应的完整链条。这个金字塔要倒过来跑从底向上但投入比例要正过来单元测试占比最大。很多团队只做E2E测试结果就是测试套件运行缓慢、脆弱UI或环境一变就挂且出了问题很难定位。测试驱动开发TDD是一种将测试提升到设计层面的实践先写一个失败的测试再写最简单的代码让它通过然后重构。它强迫你在写代码前就想清楚接口和需求能产出高内聚、低耦合、天然可测试的代码。虽然在实际硬件依赖强的开发中完全践行TDD有挑战但其“测试先行”的思想极具价值。3.2 为创新创造时间20%时间与持续学习Lau提到了谷歌著名的“20%时间”——允许工程师将一部分工作时间用于自己认为有价值的项目。Gmail、Google News等都源于此。其核心是承认并鼓励工程师的内在驱动力和创造力。并非所有公司都能照搬20%政策但其精神可以借鉴为探索和试错留出空间。这可以通过多种形式实现定期的黑客松Hackathon集中几天时间让团队自由组队用任何技术解决他们感兴趣的问题不一定与当前产品直接相关。创新孵化项目设立小额预算和评审机制支持工程师提出的小型创新点子并给予资源验证其可行性。技术债偿还冲刺专门划出时间让团队集中处理那些平时没空解决但长期影响效率的技术债务这本身就是一种对未来创新的投资。与创新时间配套的是“学习和持续改进的文化”。Lau建议通过每周技术分享等活动为工程师提供拓展工作范围的论坛和途径。技术分享的主题可以非常广泛一次事故复盘Post-mortem、一项新技术的调研、一个复杂问题的解决思路、甚至是一次失败实验的教训。关键在于营造安全、分享的氛围让分享者没有“露怯”的压力听众能真正有所收获。3.3 招聘最优秀的人乔布斯“A级玩家”定律的实践Lau引用了乔布斯的话“A级玩家雇佣A级玩家。B级玩家雇佣C级玩家。” 这句话虽然绝对但揭示了一个残酷的真相团队的文化和水平往往是由招聘标准决定的。如果降低标准招进来一个“B级”工程师他未来可能会因为不安全感而招聘能力更弱的人导致团队平均水平螺旋式下降。“招聘最优秀的人”不仅仅是看技术能力算法、系统设计更重要的是考察其是否与团队文化契合成长型思维是否乐于学习新事物如何面对失败和批评协作精神在过去的项目中如何与同事合作是否有代码共享、乐于助人的经历系统思维是只关注眼前任务的“码农”还是能思考技术决策对系统长期影响的工程师内在驱动力是对技术有纯粹热情还是仅仅把编程当作一份谋生的工作招聘是双向选择。优秀的工程师也在评估你的团队文化。在面试中详细地向候选人介绍团队的工作方式、技术挑战、以及你正在努力建设的文化比如快速的迭代、深度的Code Review、对自动化的投入本身就能吸引那些认同这些理念的“A级玩家”。4. 工程文化建设的挑战与常见陷阱纸上谈兵容易落地实践却充满挑战。在实际推动工程文化改进的过程中会遇到各种阻力和陷阱。4.1 技术管理与非技术管理的冲突在Lau的帖子下有工程师评论说改善工程文化最重要的方式是“优先级由工程师设定而非非技术管理层”。这反映了一个普遍矛盾业务压力来自市场、销售、管理层与工程技术合理性之间的冲突。非技术管理者可能更关注功能上线日期、市场热点而工程师则深知没有良好的架构、测试和自动化快速堆砌功能是在积累“技术债”未来会以更高的利息更多的bug、更慢的开发速度、工程师的疲惫和流失偿还。如何应对建立技术影响力让资深工程师或技术负责人参与到产品路线图的早期讨论中从技术可行性、实现成本和长期维护角度提供输入。数据化沟通不要只说“这样代码质量不好”而是用数据说话。“如果我们跳过设计评审这个模块的耦合度可能会增加根据历史数据类似模块的缺陷率是其他模块的3倍预计后期修复bug需要多投入50人天。”管理“技术债”将技术债像财务债务一样可视化。创建一个技术债清单评估每一项的“利息”对开发效率的影响和“本金”修复所需工作量。在规划每个迭代时固定分配一定比例如15-20%的产能来“偿还”高利息的债务。培养懂技术的管理者如果团队管理者有技术背景他/她更能理解工程师的关切并在业务与技术之间充当更好的翻译和缓冲。4.2 微观管理的危害与授权艺术工程师们普遍“憎恶微观管理认为这非常贬低人格”。微观管理的背后往往是管理者对团队能力的不信任或者对失控的恐惧。但正如评论所说“只要让工程师按照他们想要的方式去做工程师并且只要你雇佣了优秀的工程师同时也是优秀的人他们就会为你创造奇迹甚至无需你开口”授权不等于撒手不管。好的授权是明确“做什么”目标、边界、质量标准和“为什么”背景、价值但放开“怎么做”的具体细节。管理者需要提供的是上下文Context而不是指令Control。定期的一对一沟通和项目同步会是用来了解进展、扫清障碍、提供支持的而不是用来事无巨细地检查每一步操作。4.3 平衡“快”与“好”的永恒难题“优化迭代速度”有时会与“高代码质量”、“充分的自动化”产生短期冲突。当业务方催得急压力之下团队很容易选择“先上了再说以后再优化”结果“以后”永远不会来技术债越堆越高。破解之道在于建立正确的“速度”观区分“战术速度”和“战略速度”砍掉设计、跳过测试、硬编码参数可能让这个版本提前一周上线战术速度。但随之而来的不稳定、难修改会导致下三个版本每个都延迟两周战略速度受损。真正的快是系统能够持续、稳定交付价值的快。投资于“加速器”自动化测试、CI/CD流水线、监控告警这些前期需要投入但它们是长期的“加速器”。就像修路虽然暂时让施工变慢但路修好后所有人的通行速度都提升了。建立团队共识通过复盘会、技术分享让整个团队包括产品经理都理解那些“看不见”的工作如重构、写测试、搭建工具的价值认识到它们对长期速度的贡献。4.4 远程/混合办公模式下的文化维系随着工作模式的演变传统的、依赖面对面交流的团队文化构建方式面临挑战。在远程环境下如何保证代码审查的质量、如何促进非正式的技术交流、如何维持团队的归属感和信任一些可行的实践强化书面沟通在文档、代码注释、PR描述、设计文档上投入更多确保信息异步可获取。鼓励在公开频道讨论技术问题而不是私聊。规范化的线上协作流程使用Git等工具严格管理代码流程利用Jira、Confluence等工具透明化任务和文档定期举行有明确议程的线上站会、设计评审会。创造虚拟的“饮水机交谈”机会设立固定的、非强制性的线上社交时间如每周五下午的虚拟咖啡时间话题不限于工作。也可以组织线上的技术分享会或读书俱乐部。重视线上Code Review由于缺少面对面沟通线上Review的评论需要更加清晰、具体、友善。可以约定使用一些标签如nit:小问题、question:疑问、suggestion:建议。5. 评估与改进你的团队工程文化健康度检查最后我们如何评估自己所在团队的工程文化并着手改进呢可以尝试从以下几个维度进行诊断1. 开发流程与效率从一个想法到代码上线平均需要多长时间其中等待和审批的时间占多少代码提交后CI流水线跑完需要多久如果失败定位问题是否方便搭建一套完整的本地开发环境新员工需要多久2. 代码质量与知识共享代码库中是否有大量无人敢动的“祖传代码”Code Review是形式化的“LGTM”还是能产生实质性讨论当某个核心成员休假时他负责的模块是否还能正常推进或修复问题3. 自动化与可靠性发布新版本是紧张的手动操作还是自信的一键部署线上出现问题时是人工登录服务器查日志还是监控系统自动告警并给出初步定位测试覆盖率是多少是否有一套稳定的自动化测试套件能在每次修改后运行4. 创新与学习团队是否有时间和技术空间去尝试新技术、新工具是否有定期的技术分享机制大家参与的热情如何团队的技术栈和开发实践与三年前相比有哪些显著的进步5. 心理安全与协作团队成员是否敢于提出不同意见尤其是对资深成员或领导的方案当出现线上事故时复盘会的重点是追责还是改进流程团队成员是乐于互相帮助还是各自为战改进工程文化没有银弹它是一个持续的过程需要技术领导者的坚持、示范以及整个团队的认同和参与。可以从一个小点开始比如推行认真的Code Review或者花一周时间自动化一个最令人痛苦的部署步骤。让团队尝到“甜头”看到改变带来的实实在在的效率提升或痛苦减少变革的动力才会像雪球一样越滚越大。归根结底好的工程文化就是让一群聪明的工程师能够愉快、高效、持续地建造出令人骄傲的东西。