[{"data":1,"prerenderedAt":247},["ShallowReactive",2],{"\u002Fblog\u002Ftechnical-lead-still-codes":3},{"id":4,"title":5,"author":6,"body":7,"category":232,"date":233,"description":234,"extension":235,"headline":236,"image":6,"meta":240,"minRead":241,"navigation":242,"path":243,"seo":244,"stem":245,"__hash__":246},"blog\u002Fblog\u002Ftechnical-lead-still-codes.md","负责团队之后，我为什么仍然坚持写核心代码",null,{"type":8,"value":9,"toc":222},"minimark",[10,14,17,24,27,31,34,37,40,59,62,66,69,72,105,108,111,114,117,131,134,137,141,144,147,164,167,170,173,176,179,196,199,202,205,208,216,219],[11,12,13],"p",{},"从工程师成为技术负责人之后，一个常见问题是：还要不要继续写代码？",[11,15,16],{},"一种观点认为，负责人应该把时间全部用于架构、排期和人员协作；另一种观点则把“保持编码”理解成继续领取大量需求，甚至成为团队里最忙的开发。",[11,18,19,20],{},"我的经验介于两者之间：",[21,22,23],"strong",{},"技术负责人不必写下最多的代码，但应该持续参与最能暴露系统真实约束的代码。",[11,25,26],{},"我曾从 0 到 1 组建并负责 6–7 人研发团队，也带过更小的交付团队。在这些经历里，持续参与核心开发并不是因为不愿意授权，而是因为它能让很多管理和技术判断建立在事实之上。",[28,29,30],"h2",{"id":30},"编码是理解系统的一种方式",[11,32,33],{},"架构图表达的是我们希望系统如何工作，代码和生产日志呈现的则是它实际上如何工作。",[11,35,36],{},"当负责人完全离开实现一段时间，判断容易建立在过时印象上：以为某个模块边界已经清晰，以为一个接口只是增加字段，以为部署流程足够稳定。真正开始修改时，团队才发现隐藏依赖远比预期多。",[11,38,39],{},"参与核心代码可以持续校准这些认知。但“核心”不等于“最难”或“最炫技”，而是那些能够揭示系统关键约束的地方，例如：",[41,42,43,47,50,53,56],"ul",{},[44,45,46],"li",{},"新业务的第一个完整纵切；",[44,48,49],{},"涉及多个系统的接口契约；",[44,51,52],{},"支付、订单和权限等高风险逻辑；",[44,54,55],{},"一次架构迁移的示范模块；",[44,57,58],{},"难以复现的生产故障。",[11,60,61],{},"写过第一条完整链路之后，负责人更容易把后续任务拆成团队可以并行完成的部分。",[28,63,65],{"id":64},"负责人写代码不应该成为瓶颈","负责人写代码，不应该成为瓶颈",[11,67,68],{},"技术负责人参与实现最大的风险，是所有关键任务都必须等他完成。短期看很高效，长期会让团队失去独立交付能力。",[11,70,71],{},"我会用几个原则避免这个问题：",[73,74,75,81,87,93,99],"ol",{},[44,76,77,80],{},[21,78,79],{},"优先写样板，不长期占有模块。"," 把新模式跑通、记录决策，再让其他成员继续扩展；",[44,82,83,86],{},[21,84,85],{},"选择高信息量任务。"," 参与能帮助理解系统的问题，而不是把大量重复页面留给自己；",[44,88,89,92],{},[21,90,91],{},"代码从一开始就进入正常评审。"," 负责人写的代码也要被团队审阅；",[44,94,95,98],{},[21,96,97],{},"确保至少一位成员理解实现。"," 关键模块不能只有一个人能够维护；",[44,100,101,104],{},[21,102,103],{},"主动退出稳定区域。"," 一旦边界清晰，就把所有权交给团队。",[11,106,107],{},"负责人写代码的目标不是证明自己仍是最强开发，而是降低未知、建立边界、帮助团队更快形成共同理解。",[28,109,110],{"id":110},"任务拆解必须靠近实现",[11,112,113],{},"“开发一个预约功能”不是可执行任务。真正的任务可能包括数据模型、可用时段计算、价格规则、订单接口、支付回调、页面状态和运营后台。",[11,115,116],{},"如果任务拆解离实现太远，常见结果是：",[41,118,119,122,125,128],{},[44,120,121],{},"工作量按页面数量估算，却忽略后端状态变化；",[44,123,124],{},"前后端各自假设接口，联调时才发现不一致；",[44,126,127],{},"正常路径很清楚，异常和恢复路径没人负责；",[44,129,130],{},"任务看似完成，却缺少日志、迁移和发布方案。",[11,132,133],{},"保持编码让我能够更早看到这些缝隙。拆解时，我会要求每个任务尽量包含明确输入、输出和验收方式，同时把跨模块风险单独列出。",[11,135,136],{},"好的任务应该可以被验证，而不只是被“做完”。",[28,138,140],{"id":139},"代码评审是建立共同判断不是找错","代码评审是建立共同判断，不是找错",[11,142,143],{},"如果代码评审只由负责人指出问题，团队会越来越依赖一个人的偏好。更有价值的做法，是把评审变成对设计判断的解释。",[11,145,146],{},"例如，与其只说“这里应该抽象”，不如说明：",[41,148,149,152,155,158,161],{},[44,150,151],{},"当前重复是否真的会一起变化；",[44,153,154],{},"抽象之后，调用方需要理解多少概念；",[44,156,157],{},"错误应该在哪一层被转换；",[44,159,160],{},"这个边界是否方便单独测试；",[44,162,163],{},"下一项需求到来时，哪部分最可能变化。",[11,165,166],{},"同样，负责人自己的代码也应该接受这样的讨论。团队看到技术判断可以被质疑和修正，才会更愿意表达不同意见。",[28,168,169],{"id":169},"生产问题需要负责人保持手感",[11,171,172],{},"线上故障往往同时涉及业务、代码、数据和部署。技术负责人如果熟悉真实运行链路，可以更快做出优先级判断：先恢复服务，还是先保护数据；应该回滚版本，还是补偿任务；哪些操作可逆，哪些需要等待外部平台。",[11,174,175],{},"但这不意味着负责人应该独自处理每次故障。",[11,177,178],{},"更好的方式是共同响应，并在事后沉淀：",[41,180,181,184,187,190,193],{},[44,182,183],{},"一条可复用的排查路径；",[44,185,186],{},"关键链路的监控和关联 ID；",[44,188,189],{},"必要的后台修复工具；",[44,191,192],{},"明确的回滚与补偿方案；",[44,194,195],{},"对系统边界的新理解。",[11,197,198],{},"故障处理的成果不只是修复当下问题，还应该让下一次响应不再依赖同一个人。",[28,200,201],{"id":201},"管理和编码不是两份工作",[11,203,204],{},"当我参与系统架构、任务协作和生产交付时，编码并不是管理工作之外额外增加的一份个人任务。它是获取信息、验证设计和建立团队标准的一种手段。",[11,206,207],{},"真正需要避免的是两种极端：",[41,209,210,213],{},[44,211,212],{},"完全离开实现，只通过会议和文档理解系统；",[44,214,215],{},"承担所有难题，让团队只能等待和执行。",[11,217,218],{},"技术负责人的价值，在于让正确的信息流向正确的人，让复杂问题拥有清晰边界，并让团队逐渐具备不依赖负责人也能稳定交付的能力。",[11,220,221],{},"我仍然写核心代码，但我希望留下的不是“只有我能维护”的模块，而是一套团队可以继续工作的路径。",{"title":223,"searchDepth":224,"depth":224,"links":225},"",2,[226,227,228,229,230,231],{"id":30,"depth":224,"text":30},{"id":64,"depth":224,"text":65},{"id":110,"depth":224,"text":110},{"id":139,"depth":224,"text":140},{"id":169,"depth":224,"text":169},{"id":201,"depth":224,"text":201},"团队与交付","2026-08-02","技术负责人不必写下最多的代码，但需要持续接触真实约束，才能让架构判断、任务拆解和生产决策保持准确。","md",[237,238,239],"负责团队之后，","我为什么仍然坚持","写核心代码",{},7,true,"\u002Fblog\u002Ftechnical-lead-still-codes",{"title":5,"description":234},"blog\u002Ftechnical-lead-still-codes","6XsPJnZBQgy-35bxydpjOrJmBi94RY3FIxUghmbj5q8",1789624776302]