Let's talk about code ownership.
In a small project by a single team,
there isn't too much to speak of
(or is there?). The team wrote it; the
team owns it and is responsible for it.
However, what if we are talking
about large project?
Perception of code
ownership in large projects
In a small project, a team may split the responsibility
for the code further internally, but it doesn't change
the external perception – the team owns the code.
The reality might be slightly different, but it will boil
down to this variation. If the team doesn't own the
code, it will deteriorate quickly.
In the case of the CA24 Mobile app, at the highest
point, 30 mobile devs were working on the project
split into 12 business teams (also known as squads).
We might say that this is just a simple extrapolation –
each team owns the code they create. That would
be true. Mostly.
The problem arises when we realize
that the teams work on a single app and
single codebase. A. Single. Codebase.
So, by another extension, if every team
creates the code in the same codebase,
then is every team responsible for
everything? If that’s the case, then
no one will be responsible for anything.
There might be places where some people will feel
responsible for their piece, but that will be an
exception. If you nd a bug, nobody will be willing to
x it because that will always be someone else's
problem. If you need another feature, you will need
to write it yourself because no one cares.
We need to follow the limit and set boundaries exactly
where they should be. In a project of this size, these will
not come out naturally. We need to put them down and
abide by the rules explicitly. If we do this right from the
beginning, it will not feel articial and won't be
questioned.
After all, the rule is natural.
E
veryone feels responsible
for their work, but we cannot allow a situation where too
many people claim ownership of the same piece. That is
the problem, and we need to overcome it by introducing
explicit code ownership.
Let's put some ground rules on how we de
ne code
ownership at LeanCode in a
F
lutter project of this size.
F
irst and foremost, every line of code is owned by
a team, not by a single person.
E
ven if the team consists
of a single developer, it is still the whole team's
responsibility to maintain the code.
D
evelopers are rarely
working autonomously, and someone else
(usually
"
business people
"
) always prioritizes the work.
That's why a single person should never be
responsible for a piece of code. If that happens,
introducing any code changes will require getting
approvals from the developer
’
s supervisors that have
much different priorities than we have. Teams are part
of a structure at a level that gives them enough power
to correctly prioritize the work around the code and pay
for it by investing hours. A single person cannot do that.
FLU
TT
ER
AT
S
CA
LE
剩余41页未读，继续阅读
百态老人
- 粉丝: 5099
- 资源: 2万+
下载权益
电子书特权
VIP文章
课程特权
VIP享7折，此内容立减5.97元 开通VIP
我的内容管理
展开
最新资源
- 多模态联合稀疏表示在视频目标跟踪中的应用
- Kubernetes资源管控与Gardener开源软件实践解析
- MPI集群监控与负载平衡策略
- 自动化PHP安全漏洞检测：静态代码分析与数据流方法
- 青苔数据CEO程永：技术生态与阿里云开放创新
- 制造业转型： HyperX引领企业上云策略
- 赵维五分享：航空工业电子采购上云实战与运维策略
- 单片机控制的LED点阵显示屏设计及其实现
- 驻云科技李俊涛：AI驱动的云上服务新趋势与挑战
- 6LoWPAN物联网边界路由器：设计与实现
- 猩便利工程师仲小玉：Terraform云资源管理最佳实践与团队协作
- 类差分度改进的互信息特征选择提升文本分类性能
- VERITAS与阿里云合作的混合云转型与数据保护方案
- 云制造中的生产线仿真模型设计与虚拟化研究
- 汪洋在PostgresChina2018分享：高可用 PostgreSQL 工具与架构设计
- 2018 PostgresChina大会：阿里云时空引擎Ganos在PostgreSQL中的创新应用与多模型存储
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
