当从单体运用转向“微”的统统——微做事、微前端，我们会创造还有很多“东西”要研发和掩护。这就引出了一个问题：该由谁来卖力呢？
举个大略的例子，设想一支由 6 名开拓者组成的小型团队。
这支团队已经创建并支持一款移动运用、一项 Alexa 技能、三款独立的网络运用和十五个微做事。
只管他们成功地在全体生态系统中实现了一定的标准化，但鉴于当代软件开拓的实质，它只是很多而已。Python、Django、DynamoDB、S3、React、TypeScript、Tailwind、Swift 等等都一起事情，都是为了实现用户界面、API、数据持久性、集成等等。
但对付任何一位开拓者而言，这都太多了。
其余，每次 Sprint 都会有不同的改进和修复需求，而且事情很少能够在代码库中均匀分配。一次 Sprint 可能哀求对移动运用程序进行大量的改动，而接下来的 Sprint 可能哀求紧张在后端事情。
那么，问题来了：若何才能最好地支配一支团队，以适应一次接一次 Sprint 的业务需求？换言之，我们若何才能更好进行职责分配？
比如说，我们鼓励专业化吗？像指派 Emily 处理所有的移动开拓事情，让 Joe 卖力网络组件这样的。除了技能栈之外，如果我们有十几个微做事，我们会不会在它们周围划分界线，例如 Javier 卖力微做事 A 和 B，Anna 卖力微做事 C 和 D，诸如此类？如果他们特定领域的事情在连续数次 Sprint 都很轻松后会若何呢？能让他们有一点空闲的韶光吗？
还是说，我们该当努力优化利用率，鼓励更多的全栈、跨域文化，每个开拓者都做这统统……这合理吗？
影响成分
正如开拓软件一样，我们在进入一个办理方案之前，该当退一步，试图弄清楚我们要办理的问题。我认为，在考虑开拓者的职责和所有权时，该当考虑以下四个方面：
显而易见的是生产力。当所有条件都一样时，我们要把团队的构造安排得尽可能好，这样才能让他们完成的事情最大化。以是，优化生产力每每是为了让开发者的事情能够与自己的技能和履历保持一定的同等性。比如，Emily 在前一次 Sprint 中从事移动运用的开拓，那么她将会比那些一贯在后端事情的开拓者更早地开拓出新的特性。我们也要重视质量问题。和上面类似，在某个特定的代码库中拥有更多实践履历的开拓者，可能会以更高的质量来实现新的特性，而不是那些只在某次 Sprint 空降到团队，却不理解构造、模式或老例的人。纵然是最精良的开拓者，在不理解代码库的情形下，也会写出蹩脚的代码。组织每每也须要降落开拓者离职的风险，以及随之而去的知识。这才是问题的关键所在，而这每每与上述目标相悖。只管将一个又一个 Sprint 开拓任务指派给一个移动开拓者可以将生产力和质量最大化，但是一旦这名开拓者接到 Meta 招聘者的短信时，那么组织就会处于危险的田地。末了，我们不能忽略开拓者的幸福感这个看不见的成分。不过，这件事也是非常繁芜的。有些人喜好多元化和新鲜感，以是当他们在一次又一次 Sprint 被困于同一个别系时，就可能会降落生产力或者跳槽。另一些人则更乐意看到可预见的未来，并以拥有自己的领地为荣，频繁跳槽会让他们抓狂。换句话说，我们每个人都是不同的，但确保我们能够得到知足、有寻衅的机会，这一点很主要。
假设这些是须要考虑的精确成分，那么关键在于，每一家组织都要根据这些要素的“权重”来确定策略。优化最主要的是什么？可能有些是韶光紧迫带来了压力（如末了期限），因此生产力必须得到优化。又或者，开拓者市场是如此火爆，最主要的便是让开发者感到愉快，而不是什么提高生产力。也便是说，它在很大程度上取决于环境。
本文将在此磋商“如何”做，并假定组织已经理解自己将进行优化的内容，并为团队建立职责而选择一些模式。但是有哪些模式可选呢？下面是我碰着过的一些常见模式。
所有权模式
我们常常会在代码所有权的策略上做文章。有时候很默契：每个人都尊重这样的安排：Joe 卖力网络的事情，Emily 卖力移动开拓，我卖力支付微做事等等。其他时候，这也是正式的安排：管理层聘请 Joe 为网络开拓者，Emily 为移动开拓者等。无论哪种情形，实践中都是类似的：当新的特性或修复问题涌现时，我们会根据“拥有”的东西进行划分。
这让我们（从个体角度来说）最大限度提高了生产力，并且（常日）提高了质量。但是，它也存在一定的毛病。
首先，人们可以储存不同系统的第一手知识，如果有人“中了彩票”或“被公交车撞了”，企业就会面临巨大的风险。此外，如果开拓者想要学习新事物，“所有权”有时就像一种束缚。
末了，必须指出的是，只管个人生产力得到了提升（由于开拓者很熟习他们的代码库），但集体的生产力每每会随着所有权的增加而低落。正如上面所谈论的，由于事情负荷在每次 Sprint 并不能做到完备平衡，因此可能会造成拥有所有权的开拓者涌现“盛宴”和“饥荒”的情形。例如，在一次 Sprint 中，他们代码库中的事情超出了所有者能够处理的范围，这导致了很大的瓶颈（或加班到深夜！
），但到了下个月就没有什么事情可做了，而这个所有者或多或少便是闲着的。
自由竞争模式
当组织感想熏染到所有权带来的各类痛楚时，他们方向于放弃任何策略，只是为所欲为：即自由竞争。这个模式就像它听起来一样的大略。一位经理看到那里有一堆事情，就说：“嘿，你，码农，赶紧干活吧！
” 然后就这样了。
只管这样的策略的确可以担保总体分配均衡（即 Emily 在没有移动事情的时候也不会无所事事，由于她被拉去处理 Python 做事），但这种模式可能既累人，又充满质量问题。如果我们没有与我们所从事的代码库建立长久联系，那么我们的事情就只是权宜之计，并以无知为辅导。我们在短期内采取了一种古怪的修复方法，由于不知道更好的办法，或者我们并不关心——下一次 Sprint 我们就会在不同的代码库里了！
正如他们所说，“谁也不会把租来的汽车洗干净。”
这种自由竞争的模式每每是由管理层推动的，他们空想化地认为我们是可更换的勤杂工（也便是传说中的全栈开拓者），无论什么层级、系统或业务领域，都能够迅速、优雅而轻松地办理任何技能寻衅。当然，这是无稽之谈。除了最微不足道的系统或者最出色的开拓者，其他的都太繁芜了，如果没有足够的韶光来提高我们的能力，就不可能节制所有的东西。
管理权模式
现在，在所有权和自由竞争这两个极度之间，存在着一种管理模式（或称监护权）。类似于所有权，开拓者会在自己最善于的领域管理特定的代码库，他们可能在这个项目中做了大部分的初始事情，他们的名字在代码中随处可见，但是他们并不是什么都要做。然而，必须在做出变更时，至少要搜聚他们的意见，让他们参与莅临盆问题的分类或者是谈论设计的变更。
比如，Emily 可以在门户网站事情量繁重的时候过去帮 Joe 一把，而在事情平息下来的时候再回到她的移动运用开拓事情。换句话说，这种模式同时平衡了个人和集体的生产力。此外，由于开拓者对自己事情之外的其他领域已经有了一定的理解（即可以学到一些新知识），以是这种模式在风险减轻和开拓者的幸福感之间起到了很好的平衡。
管理权的主要之处在于，只管不像所有权那样正式，但是它还是被清楚地界定和履行。该模式下至少有一些事情要做：应该有一份管理者清单，可以定义每个管理者的管理范围；GitHub（或者其他 SCM 工具）应该被配置成由管理者批准所有的拉取要求，并且管理者应该有充足的韶光对其组件进行必要的“管理”。如果这方面没有特定的形式和纪律，所有的事情都会顺着滑坡滑下去，直至处于自由竞争的坑中。
接管权模式
末了，一种在大型组织中非常盛行的模式可能也很主要，便是“接管权”，有少数当选中的人（常日是宇航员架构师）卖力“拥有”统统。他们拥有丰富的知识、作出重大的技能决策，并设计业务逻辑和构造，但实际的详细事情由每个开拓者来完成，而且每每因此自由竞争的办法进行。
这种模式在理论上非常有效。通过接管者与动手的开拓者分享他们的“聪慧”，为快速、高效的办理方案开辟了一条路子，实现了效率和质量的优化。有了接管者的帮忙，开拓者可以自由出入代码库，并通过接管者来迅速进入状态。
但在实践中从未产生过这种影响。没有任何实践履历的接管者会迅速与技能现实脱节，而且不能真正帮助开拓者实现某些改进或修补某些 Bug。开拓者可能要耗费相同的韶光去改进，同时，由于基本年夜将自己的自主权（和创造力）交给了那些能够指挥他们的接管者，以是他们可能会感到挫败。
作为一个曾经扮演过接管者角色的人，我认为这种模式对任何人都很糟糕，这便是为什么我只管即便避免这种类型的角色。
这些只是我碰着的几种分工模式，我也很想听听你的想法和履历。
作者先容：
Ben Northrop，毕业于卡耐基梅隆大学，自诩“老”程序员，写博客将近 20 年。2017 年，创办了 Highline Solutions，是一家专注软件架构和全栈开拓的咨询公司。
原文链接：
https://bennorthrop.com/Essays/2022/code-ownership-stewardship-or-free-for-all.php
