所有权与问责制：从概念到生产，您拥有自己的代码
Source: Dev.to
所有权的表现
所有权不仅仅是编写代码。它是从你产生想法的那一刻起一直拥有这段代码，直至它在生产环境中退役。
这意味着你要：
- 理解你要解决的问题
- 设计解决方案
- 编写代码
- 测试代码
- 部署代码
- 监控代码
- 当出现故障时进行修复
- 随着时间的推移进行改进
如果你只写代码然后把它扔给别人处理，你并没有承担任何所有权——你只是单纯地写代码。
两小时规则
我经常看到的模式
开发者遇到一个 bug，盯着它看了六个小时，最后在下午 5 点求助：
“嘿，这个不工作，你能看看吗？”
六小时卡住，零沟通。
更好的做法： 如果你被阻塞超过 2 小时，就提出。
但不要只说“它坏了，帮我”。展示你已经尝试的内容：
“我在这个 auth bug 上卡住了。我已经尝试了：
- 检查 JWT 令牌过期时间——令牌是有效的
- 验证签名算法——与我们的配置匹配
- 使用 Claude 审查中间件——未发现问题
- 这里是我的日志：
[paste]
我认为问题出在 token‑refresh 流程，但我需要另一双眼睛。”
你已经完成了工作，耗尽了选项，记录了尝试的过程，并形成了假设。现在同事可以真正帮助，而不是花一个小时去复现你本该已经完成的工作。
在请求帮助之前
先使用你手头的一切资源：
- 阅读文档
- 使用 AI 工具（Claude、ChatGPT、Gemini、Cursor）
- 编写能够准确展示问题的失败测试
- 检查代码库中的类似问题
- 在 Google 上搜索错误信息
如果你已经完成了上述所有操作，但仍然卡住超过 2 小时——那就可以了。请求帮助 并且 展示你已经尝试过的内容。
“你能帮忙吗？” — 没有上下文并未承担责任。这是在让别人为你的问题负责。
当生产环境出现故障时
这正是所有权真正体现的地方。
糟糕的所有权
“部署失败了。应该有人去看看。”
良好的所有权
“部署失败了。我负责。根本原因：数据库迁移超时，因为我没有考虑到表的大小。我现在正在回滚。
解决方案：将迁移拆分为更小的批次。
我将在 30 分钟内准备好重新部署。
下面是我们下次如何防止此类问题的措施……”
注意区别：
- 立即承担责任
- 解释出了什么问题
- 提供解决方案计划
- 说明如何防止再次发生
- 给出时间表
这就是所有权。
成功的准备
当你发布一个功能时，你应该具备：
监控
- 监控关键指标（延迟、错误、吞吐量）
- 仪表盘一目了然地展示健康状态
- 日志能够真正帮助你调试
警报
- 在发布 之前 配置
- 包含上下文——不仅仅是“出了问题”
- 路由到合适的人员
文档
- 这是什么原理？
- 可能出现哪些问题？
- 如何解决常见问题？
- 谁构建了它，如何联系他们？
如果你的功能在凌晨 3 点宕机，且其他人值班，他们应该能够：
- 从警报中了解故障原因
- 找到你的运行手册（runbook）
- 修复它 或 知道如何联系你
如果他们做不到，说明你并未完成发布。
部署失败的案例
一名开发者曾经部署了一个支付重构。它经过了彻底的测试，在预发布环境中运行正常，随后在周五下午推送到生产环境。
Saturday morning: 警报频发，支付处理速度降至爬行，用户无法完成交易。
“老开发”可能会说：“在预发布环境里运行得很好”，然后等别人去调查。
相反的做法：
- 立即介入
- 找到问题：没有使用生产级别的数据量进行测试
- 在 10 分钟内回滚
- 撰写事后报告
- 修复实际问题
- 将负载测试加入我们的 CI/CD 流水线
- 周一自信地重新部署
这才是担当。不是“在我的机器上可以运行”，也不是“周末不是我的问题”。而是：我负责，我会解决，这里是我们防止再次发生的措施。
拥有所有权让你更出色
令我惊讶的是：全面承担所有权让我更快成为更优秀的工程师。
为什么？因为当你知道自己对生产环境中的某件事负责时，你会：
- 深入思考边缘情况
- 编写更完善的测试
- 建立适当的监控
- 记录你的决策
- 关注性能
- 为故障做好计划
你不能只写代码后就算了。你必须考虑整个生命周期。这会让你在工程的每个环节都变得更好。
领悟的初级开发者
我团队里有一位初级开发者，正在负责他的第一个重要功能。他对部署感到紧张，但他把每件事都做对了：
- 编写了完整的测试
- 设置了监控和告警
- 编写了运行手册（runbook）
- 通过功能标记（feature flag）进行部署
- 在首小时内监控指标
- 在 Slack 上发布更新
该功能运行得非常完美。更重要的是，他对它全程负责。两周后出现问题时，他准确地知道它是如何工作的，以及我们为何要这样构建它。
这就是思维方式：不是“我写了一段代码”，而是“我拥有这个功能”。
小步起步
选取你当前正在做的一件事。在发布之前：
- 建立基础监控
- 为最关键的故障模式添加一个告警
- 编写简易运行手册：“如果 X 出现故障，按以下步骤处理……”
通过这些小步骤，培养所有权的习惯，这种习惯可以扩展到更大的项目。
如何修复
- 记录你的思考过程：“我们为何这样构建”
- 告诉团队：“我正在发布 X，请注意以下事项”
这就是所有权。
持之以恒，你会发现：人们更信任你的工作，你成长更快，代码质量也提升。并不是因为你完美，而是因为你对整体负责——不仅仅是代码本身。
真正的考验
下次你构建的东西出现问题时，注意你的第一反应。
- 是：“嗯，它在我的环境里能跑”？
- 还是：“我现在就去看看”？
- 是：“可能得让别人来修复它”？
- 还是：“我来处理，下面是我的计划”？
这些反应之间的差别，就是 代码编写者 与 交付产品的工程师 之间的差别。
每次都选择第二种。
这就是所有权。
这是一套 14 部分《核心领导力原则》系列的第 2 部分。下周：每日交付——为什么每天都有进展比偶尔的英雄式冲刺更有效。
你是如何在工作中实践所有权的？有什么方法帮助你对生产环境中的代码承担全部责任？
关注我的 Twitter。
如果你想支持我的工作，请 查看我的 Patreon。
更多内容请访问我的 Linktree。
图片来源：@Miguel A. Amutio 于 Unsplash。