【早阅】工程团队代码所有权挑战

作者：@Haimeng Zhou
原文：https://hackernoon.com/how-should-engineering-leaders-handle-code-ownership-challenges

背景

在软件开发过程中，代码所有权的问题随着团队规模的扩大变得越来越复杂。当一个小型团队（约 10 名开发者）共同开发一个系统时，代码所有权可能不是一个紧迫的问题。然而，当团队规模扩大到 500 人，并且数百名开发者共同维护同一个系统时，代码所有权的问题变得尤为突出。本文通过一位工程领导者的亲身经历，探讨了代码所有权不明确对软件工程团队带来的负面影响，并提出了相应的解决方案。

要点

代码所有权不明确会导致系统不稳定、开发效率低下、技术债务积累等问题。为了解决这些问题，需要明确代码所有权，推动团队协作，并采用适当的架构设计（如微服务）来隔离代码责任。

分析

1、代码所有权不明确的影响 

• 构建者不拥有代码：通常情况下，代码的构建者和所有者是不同的人。这导致构建者可能不了解代码的历史，在修改代码时容易引入错误。

• 系统容易出错且不稳定：由于缺乏对代码的深入理解，小的代码更改可能会无意中破坏系统的其他部分。

• 重复造轮子：不同的构建者可能会重复开发相同的功能，浪费时间和资源。

• 软件开发生命周期 (SDLC) 变得冗长缓慢：即使是微小的更改也需要运行完整的端到端测试，这可能需要超过 20 个小时。

2、原因分析

共享代码所有权但缺乏协作等于没有所有权

当呼叫团队试图联系领域负责人解决生产环境问题时，在与三个不同的团队交谈后，最终发现没有人真正理解代码。

责任混乱

最近修改过代码的开发人员接到支持电话，但他们意识到最近还有另外两个团队也修改过相同的代码。那么，谁应该修复这个错误呢？

共享模块中充斥着大量的业务规则

业务层和基础设施层之间没有明确的界限。如果开发人员不了解其他开发人员添加的业务规则，那么修改任何文件中的任何一行代码都是有风险的。

每个人都在修改相同的代码，但彼此之间没有沟通

在截止日期的压力下，开发人员往往倾向于快速完成项目，而不会 “浪费” 时间进行沟通。作为开发人员，花时间与领域负责人开会并不是一件受欢迎的事情。

没有人对技术债务负责

随着时间的推移，不同开发人员的代码设计不再一致。我们开始看到一些非常奇怪的实现，每个人都知道系统的稳定性是一个问题，但是谁应该对技术债务负责呢？

团队不愿承担代码所有权

拥有代码意味着承担更多的责任。团队往往倾向于推卸所有权。一个典型的说法是：“我的团队对这个功能没有全面的了解，如果您有任何问题，请联系其他人。

3、解决方案

理想情况下

• 为每一行代码指定所有者，并在所有者离开时自动将其转交给继任者。

• 追求良好的代码隔离，构建解耦系统。

• 采用微服务架构，将所有权与每个微服务绑定。

现实情况下

• 在单体应用中，定义域模块并为每个模块指定所有者。

• 采用共同所有权模式：一个团队负责构建基础元素，其他团队协作构建其功能。

• 加强团队协作：构建者应积极与所有者沟通，所有者应为构建者提供支持。

• 将代码视为资产：每个构建者都应以拥有和维护高质量、可持续的代码为荣。

影响

1、对行业的影响

• 提高开发效率：明确的代码所有权和团队协作可以显著提高开发效率，减少重复劳动和技术债务。

• 增强系统稳定性：通过明确的代码责任和架构设计，系统将更加稳定，减少生产环境问题的发生。

2、未来趋势

• 微服务架构的普及：随着团队规模的扩大，越来越多的公司将采用微服务架构，以更好地管理代码所有权和系统复杂性。

• 自动化工具的发展：未来可能会出现更多的自动化工具，帮助团队更好地管理代码所有权和技术债务。

结论

代码所有权不明确是大型软件开发团队面临的一个重要挑战。通过明确代码所有权、推动团队协作和采用适当的架构设计，可以有效解决这一问题，提高开发效率和系统稳定性。未来，随着微服务架构的普及和自动化工具的发展，代码所有权管理将变得更加高效和透明。

😀 每天只需花五分钟即可阅读到的技术资讯，加入【早阅】共学，可联系 vx：zhgb_f2er

5 分钟新知：了解技术资讯的一种方式。

🚀可直接通过阅读原文了解详细内容。