开发者应该负责多少代码？

当我在越来越多的组织中工作之后，我编译时候遇到的有趣问题也越来越多。严格来说， 我也有了很多待办事宜。而此处的有趣并不是讽刺。这种有趣就像是你听见一个醉汉夸夸其谈他的政治观点，然后回答说“哦，那……很有趣”。

把这些问题放在哲学层面上真的让我很感兴趣。它们让我想去了解我从来没有想过的事情。今天我从众多问题中选出一个，然后搞清楚。这个问题是一个客户在不久之前问过我的：“开发者应该对多少代码负责呢？”

为什么要问这个呢？ 好吧。是因为他们有一个值得称赞的目标。 他们有一个相当庞大的遗留代码库，并且不想那些在其上工作的人负担过重。 “我们知道我们的代码库有X行代码，所以多少开发人员可以组成一个完美的开发团队？

他们以数据驱动的方式问了一个很好的问题。然而，由于缺乏更仔细的检查，所有理由都不成立。 我今天会说出为什么会如此。下面是一些关于这个想法的问题列表。

首先，此处不谈针对集体代码所有权的异议。历史上，应用程序开发的经理出于特殊的目的往往将软件工作和体力劳动做对比。

有一堆需要挖的洞？ 分配给每个团队成员一些挖洞的任务。有一堆需要编写的代码？ 分配给每个团队成员需要编写的代码段。

当你意识到代码与挖洞是不同的，代码块不是商品的时候，你就要准备好应对麻烦事了。也就是说，你不能拿它们做互换交易。所以当你对代码进行了划分，刚好碰上编写 X 模块的人请了两个星期假，那你只是能把任务搁置，直到那个人回来。

个人代码所有权也会带来其他问题，但往往是对业务影响最大的。有人称之为“公共要素”。但是无论你叫它什么，当你开始谈论团队成员对现有代码的“负责”时，你应该鼓励此类行为。 因团队本应该对代码库负责。 仅此而已。

对于那些年纪比较大的.NET开发者来说, 你可能会把你的编程历史分为"BL"和"AL". 即"Linq前"和"Linq后"。

在 Linq 出现之前, 你写了大量的指令性的代码,，遍历嵌套循环直到找到你想要的对象。而Linq一经问世, 所有这些都变成了声明式的代码。

但它不是通过一对一的智能海量映射做到的。它是将你的冗长的就像快要爆炸了的中子星一样的指令性代码，分割成一系列更小的部分。

通过这些，我们知道了代码量在不同的语言、开发者甚至语言的不同版本之间，都会有巨大的差异。因此，"How Much" 作为一个数值指标变得相当不稳定，以至于有很少的可度量的值。

从商业的观点看, 代码就像库存, 它提供了商业可能性, 但是它放在那儿，就是你的负债。你希望开发者用尽可能少的代码完成一个功能。而比较讽刺的是，有些开发者们更趋向于为每一个功能写尽可能多的代码，他们就应该为"最少代码"负全责。毕竟有时候, 多不一定更好。

我提出的第三个也是最后一个反对意见是关于代码不确定性的。这里，我指的是给定文件或代码段的更改频率。

要理解代码的不确定性会在哪产生分歧，请考虑两个极端。首先，考虑一个稳定的、被充分考虑的模块，它包含了一百万行代码。每隔3-4年，就会出现一些新的政府监管规定，需要对这里或那里进行一些细微的调整，但除此之外，它如产品链上的梦幻一般运行良好。

另一方面，考虑一个10,000行应用程序。但是这个应用程序有各种各样的运行时问题。这里，为了更说明问题，假定持股人在不断改变着他们对软件行为的想法，导致大量粗制滥造。

对于这两个代码库，您完全可能将100万行的代码库交予1个开发人员维护，而你需要一整个团队来为第二个代码库工作也是完全可能的。尽管后者的代码库的大小是前者的1%，这依旧是有理可据的。

我提供这个例子来说明一个重要的观点。光用代码的行数来作为维护的依据是欠妥的。因此，仅仅使用代码行数来评估维护计划会成为悲伤的故事。

那么，你如何根据代码库来划分一个团队大小?如果不可行,那么开发人员应该负责多少代码，或者说“开发人员应该承担多少责任?”

我将给出一个既简单又难以衡量的方案：开发人员应该承担多大的责任？基于这点考虑，可以让代码变得更加规范。

在敏捷(Agile)开发的世界里，这一思路产生了故事地图（story mapping）和计划活动（planning activities）。将软件的目标划分为待办事项列表中的特性，然后让团队对这些特性进行分析处理。如果团队在业务上进展过慢，则表示你的团队需要壮大。如果人们无所事事，说明你的团队人员冗余。

在自顶向下计划/瀑布模型的世界中，会呈现出一种类似的动态现象，而你所能做的就只是算算会在什么时候先于计划完成（哈，就是这样）或是开始落后于计划。先于计划，那就是团队人数太多了，落后于计划，就是人数还不够。

诚然，你得通过计算和观察软件所实现的功能是否能跟上业务需求的演进步伐，才能估量出开发人员所要承担的责任范围。