我最近一直在思考很多让高级开发人员与众不同的原因。
我最近收到一封读者邮件。它帮助我确定了所有高级工程师的一个重要共性：
您提到了所有权以及关于代码中谁拥有什么的讨论。我对您对所有权的定义很感兴趣（无论是任务还是更大的事情）。
完全掌握任务的所有权是什么意思？我可以做些什么来增加我对任务和项目的所有权？
这是一个很好的问题！高级工程师对所有权有很多思考，你也应该如此。
我所说的“所有权”是什么意思
所有权的概念意味着两件事（除其他外）：
我的团队将负责什么？我的团队不会做什么？在设计新软件时，我们如何使契约尽可能具体？
我要负责什么？我可以设计一项从构思到完成的计划吗？在我们的软件中是否存在我可以主动解决的问题？
基于团队的所有权与个人所有权。两者都是重要的主题，对于成为一名优秀的开发人员来说至关重要。
基于团队的所有权
当您处理任何复杂的软件时，范围都是一个主要挑战。
定义您的团队将构建（以及您不会构建）的边界是至关重要的。对于要扩展的工程项目，您需要这些类型的系统范围和专业化定义。
团队范围和所有权适用于几种不同的方式：
首先，您需要明确定义业务战略。公司将构建哪些功能？公司决定什么是您的软件的限制？
接下来，各个工程团队如何协同工作以交付业务战略？每个团队将拥有什么以及它如何为整体计划做出贡献？
在团队之间的边界，我们能否阐明数据在系统之间传递的方式？每个团队将负责什么？我们能否为团队之间的交互设计尽可能清晰、文档化的 API？
为所有权添加清晰的界限对于工程组织来说至关重要。
当边界不明确时，作为开发人员很糟糕。你总是处于灰色地带。想知道，“这是我的工作吗？”
您最终不得不接触很多不同的代码片段。所有系统都以不可预知的方式相互作用并导致副作用。您永远无法在系统的特定部分专门化和发展深厚的专业知识。
通过团队之间明确的所有权界限，您可以积累专业知识。一旦您在团队之间定义了明确的专业知识和合同，解决问题也会变得更加容易。
个人所有权
当您作为软件工程师承担一项新任务时，您不必知道所有事情！就您的方法寻求帮助或从团队那里获得意见是完全正常的。
但是你应该自己完成任务。
当你迷路时，不要让高级工程师开发该功能。相反，问问题。坚定地说，“我想自己解决这个问题。你能给我指明正确的方向吗？”
此外，当您注意到代码或团队流程中的问题时，请拥有解决方案！创建票证来解决它。深入研究问题并帮助团队发现解决方案。
您不必为团队解决所有问题！但是你应该帮助团队识别问题并检查它们是否得到解决。
另一个例子：当你的代码在生产中导致错误时，不要让 on-call 工程师处理它。这是您的代码 - 拥有所有权！生产问题不是任何人的“错”，但您的代码是您的责任，因此请自行负责。
更多关于所有权
我每天都为软件开发人员写一些新东西。进入每日列表以接收更新。
如果你喜欢我的文章，点赞，关注，转发！
