避免个人代码所有权的 12 个理由

9 – 个人代码所有权是工程师的牢笼。

本文最初发表于CoderHood，标题为《避免个人代码所有权的 12 个理由》。CoderHood 是一个专注于软件工程中人文因素的博客。

编程是一种艺术形式，而艺术家对自己的作品往往倾注了大量心血。这种发自内心的情感正是程序员充满热情和投入的原因。这固然是好事，但也可能导致一些问题。

除非整个开发团队只有一两个开发人员，否则个人代码所有权是一种危险的做法。出于诸多原因，我既不推荐也不鼓励这种做法。

#1 – 对代码的情感依恋会损害集体智慧。

程序员如果对自己的代码产生认同感，就会对代码产生依恋。这种情感会导致代码变得不容他人触碰，并滋生教条，最终演变成争夺地盘的争端。当情感介入时，代码审查就会变得异常困难。除非代码所有者批准修改，否则改进几乎不可能实现。

我认为由三人或以上组成的软件工程团队就像参加团队运动的队伍。这种团队意识应该延伸到对所生成成果、目标、流程、成功衡量和庆祝方式以及工作其他所有方面的共同所有权。运动队中的每个队员并不拥有胜利，胜利属于整个团队。每个成员都是一个整体不可或缺的一部分，共同完成任务。赢得比赛的是团队，而不是某个队员。同样，开发人员不应该觉得自己拥有代码，而应该觉得自己是代码构建过程中不可或缺的一部分，他们是为了组织而战，而不是为了自己。

如同工程文化的其他方面一样，这种对待代码的态度需要自上而下地鼓励，理想情况下，最好是在工程组织成立之初就加以倡导。如果这种鼓励奏效，这种文化就会在基层逐渐形成并最终成为现实。想了解更多关于如何影响文化形成的思考，请查看我关于公司文化的文章。

#2 – 个人代码所有权是单点故障。

开发人员会生病、离职、升职、调到其他部门、搬到外州、甚至去世……等等。将公司重要的知识产权绑定在一个人身上，无异于自取灭亡。代码所有权将公司的健康状况与代码所有者的健康状况，或者说与该所有者与公司之间关系的健康状况紧密相连。

如果代码由一名开发人员负责，那么该开发人员就是单点故障。一旦他/她发生任何意外，整个组织都将承担后果。代码越复杂，公司需要承受的损失就越大，恢复正常所需的时间也就越长。

#3 – 团队的力量大于其成员力量的总和。

一位才华横溢的开发者可以创造巨大的价值，但一个由 N 位开发者组成的团队可以创造 N 倍以上的价值。集思广益、协作和反馈能够提升任何开发者的质量和产出，无论其天赋如何。当代码由一人独占时，集思广益和协作的重要性就会降低，最终影响产品的质量。

认为几个开发者单打独斗比一个小团队协作更好是一种谬论。单个开发者单打独斗或许能更快地做出一些实际成果，这对于原型开发来说固然很好，但成果的质量和持久性都会受到限制，这对于商业应用而言并不理想。

第四点——代码是一种产品。组织拥有它。

没有人会纠结于房子究竟属于建造它的木匠，还是属于购买它的房主。这是因为房子是实物，具有我们认为属于买家的物理属性。你在商店买的食物，就是你的食物。如果你买了一辆车，那就是你的车。这显而易见！

当产品还处于概念阶段时，情况就不那么明朗了。例如，小说作者拥有故事的所有权，而书籍的购买者只拥有印刷小说的纸张。软件更接近于概念而非实物，因此开发者，尤其是在小型公司中的开发者，会觉得自己拥有软件的所有权。他们之所以会有这种感觉，是因为只有他们自己才真正理解软件的细节。这是一种自然倾向，但也是一种谬误，企业和开发者都应该避免。

软件的所有权归公司所有，而非编写它的开发者。从法律角度讲，大多数软件开发者与其雇主之间的雇佣合同都明确规定了这一点，但人们的日常感受可能大相径庭。工程团队应该对自己的工作负有责任，而开发者则不应该抱有个人所有权的观念。

#5 – 创新需要集体的力量。

如果代码完全由一位开发者独立完成，那么所有的创新工作就都得由这位开发者来完成。听起来很荒谬？确实如此！作为一名单打独斗的工程师，你的确可以快速地进行创新，但很快就会遇到收益递减的瓶颈。而团队则不同，他们能够通过集体智慧、头脑风暴、从多个角度审视问题以及汇集个人无法企及的丰富经验，持续不断地进行创新。

随着时间的推移，团队会不断变化，不同经验的新成员会加入进来，创新的质量就会提高，新概念的产生也会重新焕发活力。辩论和良性摩擦能够激发创新；而秘密和严加保密的知识领域则不会。

#6 – 个人代码所有权导致停滞不前。

缺乏创新会导致停滞不前。长时间独自工作的程序员容易陷入确认偏误，固守成见。他们会拒绝接受任何改变，因为某些概念对他们而言已经形成了根深蒂固的观念。任何来自外部的想法或影响，如果与之前的决策不符，最终都会被过滤掉。

这种工作方式在一段时间内，尤其是在创业初期，可能是件好事。然而，最终这种软件开发方式会面临规模化瓶颈，创新也会迅速消亡。停滞不前是独立开发者的最大敌人，必须与之抗争到底。

#7 – 个人代码所有权阻碍个人学习。

长时间独自一人埋头于同一套代码库的开发者容易陷入思维定势。这意味着他们在非专业领域会变得生疏，技能也会停滞不前。

我见过一些来自大型企业的开发人员，他们多年来一直专注于同一个应用程序的同一个对话框（微软某些部门过去就以这种做法而臭名昭著）。这种专业化是过度依赖个人代码所有权的结果，会导致个人成长受阻。

#8 – 个人代码所有权阻碍职业发展。

如果一个开发人员对自己的代码产生了依恋，那么他不仅会像上面看到的那样成为单点故障；而且，由于没有简单的方法可以替代他负责的工作，因此他也很难晋升到更高的职位。

我之前在一篇题为“如何让自己失业”的文章中讨论过这个问题。想要升职，你必须放弃自己最珍视的东西，努力让自己离开现在的工作，这样才能找到一份职位更高的新工作。个人代码所有权限制了这种可能性。开发者想要升职，首先要做的就是确保自己不拥有代码库的任何部分。

个人对代码的所有权往往是自己强加的，但也很容易撤销。要做到这一点，开发者需要接纳并鼓励其他工程师接触自己编写的代码，并帮助他们熟悉这些代码。一开始，放弃这种所有权会让人感到冒险，感觉就像是在逼自己离开现在的工作岗位，但这恰恰是迈向其他更好发展方向的正确之举。

#9 – 个人代码所有权是工程师的牢笼。

因为“拥有部分代码”而觉得自己不可或缺，可能会给人一种错觉，仿佛拥有了所谓的“工作保障”。然而，这种所谓的“工作保障”更像是牢笼，而非舒适的栖身之所。如果软件工程师不学习新技能，不寻求职业发展，他们就如同被困在自己建造的牢笼里，而这个牢笼只会越来越小。

几年前，我读过一篇题为《把你的乐高积木送出去，以及其他创业公司规模化发展的准则》的精彩文章。文章探讨了创业公司的可扩展性；同样的理念也适用于个人发展和职业成长。一个开发者如果把乐高积木珍藏在身边，小心翼翼地守护着它们，就如同用一块块乐高积木搭建一座牢房。把你的乐高积木送出去，重塑自我，才能不断前进。

#10 – 固守代码的开发者与领导层发生冲突。

在科技领域，市场环境瞬息万变，产品亦是如此。有时，产品变革必须彻底，开发人员需要能够适应并支持领导层提出的变革要求。然而，当开发人员对代码的个人所有权意识过强时，他们往往会与领导层对抗，抵制变革。这种行为可能导致冲突，最终要么拖慢项目进度，要么导致开发人员被解雇。

在一些大型组织中，项目取消会导致整个团队被解雇。请仔细想想，为什么公司会仅仅因为一个项目取消就解雇一整个才华横溢的工程师团队？如果这些工程师能够顺利地转到新项目，你认为公司还会解雇他们吗？现实情况是，有时团队的组建就是围绕着项目展开的。团队成员全身心投入到项目中，对项目尽心尽力，小心翼翼地守护着它，从而失去了适应新事物的能力。拒绝改变和放手不仅是一种束缚，有时甚至会成为职业生涯的棺材。

#11 – 个人代码所有权导致不信任。

一个开发者如果觉得有必要拥有并捍卫自己的代码库，就会传递出一种不健康的信息：

禁止入内！只有我才能看懂或修改这段代码。

这种信息或许并不明确，但它却能在整个工程组织中传播，并被有意或无意地视为不信任的标志。当同一团队的成员彼此缺乏信任，并且这种不信任表现得如此明显时，团队就会受到影响，失去快速行动的能力。不信任会导致有害的摩擦，白白消耗宝贵的精力，却没有任何积极的回报。

当开发者开始习惯于在同一代码库上协作，并放下个人所有权意识时，一切都会改变。信任成为工作方式的一部分，团队合作成为驱动力。在以信任为基础的环境中运作的团队能够取得更好的成果，并变得更具韧性。

#12 – 拒绝接受有组织的开发流程无法规模化。

那些觉得自己对代码拥有完全自主权的开发者，往往觉得不需要任何流程来指导工作。敏捷方法论（例如 Scrum）或其他任何形式的组织结构对他们来说都显得陌生且不必要。这与拒绝在任何压力、结构或约束下工作的艺术家并无二致。

这种软件开发观点源于早期黑客时代，那是年轻开发者生活中典型的阶段。在那些单打独斗的日子里，学习是自然而然发生的。长时间的工作占据了程序员生活的大部分，而流程在单人团队中毫无意义。这种工作方式无法扩展。当一个项目涉及超过一两个人时，那些在辉煌的黑客时代中使用的方法就不再适用了。

在开发人员以团队形式工作的组织中，流程就成为一项重要的工具。它对于协调工作、确保高效、可预测且有条不紊地交付成果至关重要。黑客行为和软件开发之间存在着巨大的差异。前者或许很有趣，但后者才是工程组织实现规模化发展的关键。

如果您喜欢这篇文章，请保持联系！

• 欢迎访问我的 CoderHood 博客。我每周一、周二、周三和周五都会发布新文章。
• 加入我的LinkedIn职业人脉网络。
• 请在推特上关注我。
• 请关注我的Facebook主页。
• 最后，欢迎在 dev.to 上关注我！