程序员的成长和代码行数的关系

这篇文章很有价值，看了这个文章后马上针对一个架构问题做了决定，在2种方案里面选了只增加线性复杂度的那个。

在2011年John D. Cook写了一篇博客，其中提到：

我的朋友Clift Norris发现了一个基本常数，我称之为Norris常数，一个未经培训的程序员在他或她遇到瓶颈之前能写出的平均代码量。Clift估计这个值是1500行。超过这个数以后，代码会变得如此混乱，以至于本人都无法轻而易举的进行调试和修改。

我还不了解足够多的初级程序员来验证这一结果，不过我自己认识到，程序员生涯的下一个瓶颈将发生在20,000行。我把Norris常数改成2,000那样正好变成十倍。

在我离开大学之后的第一份工作中，我和我的同事一样（和我差不多年纪）反复遇到了20,000行的瓶颈。在梦工厂我们有950个程序给动画师使用，行数统计显示多的一些基本在20,000 至25,000行。超过这个数的话即再多的努力也无法增加新特性了。

在1996年年中的时候我负责编写梦工厂的照明工具（和另外两个程序员），我知道这将远远超过20,000行代码。我改变了我的编程方法并且这个工具一年后以大约200,000行的代码量成功交付。 （这个工具计划于2013年退役，在16年时间里它被每天使用并用来拍摄了21部电影。）我因为写了好几个行数在10万到20万的程序，我很确定我遇到了下一个瓶颈，我已经能够能感觉到它。

特别难的部分是和一些没有像你一样打破了好几道瓶颈的人讨论技术。打破这些瓶颈意味着做出不同的取舍，特别是一些短期内看起来不合理但以后会有所帮助决定。这很难去争论，短期内的优点是显而易见的，但我无法说服任何人说从现在起一年内可能有人会做出一个看似无害但是会破坏现有代码的改动。

Edsger Dijkstra 在1969年写道：

一个一岁多的孩子会以一定的速度匍匐前进，比如说每小时一英里。但每小时一千英里的速度就是一架超音速喷气机。就物体的移动能力而言这两者是没有可比性的，任何其中一个可以到的但是另一个不能做到，反之亦然。

一个Clift 所指的初级程序员，学会了爬行，接着蹒跚学步，然后行走，然后慢跑，然后再跑步，最后冲刺，他认为，“以这样加速度前进我可以赶上超音速喷气机的速度！“但他跑进了2,000行的极限，因为他的技能不会再按比例增加。他必须改变移动方式，比如开车去获得更快的速度。然后，他就学会了开车，开始很慢，然后越来越快，但有进入到了20000行极限。驾驶汽车的技术不会变成开喷气式飞机。

我的朋友Brad Grantham用新手程序员用“蛮力”解决问题来说明了这一点。我认为这是正确的：当代码是在2,000行以下，你可以写任何混乱肮脏的代码并依靠你的记忆拯救你。深思熟虑的类和包分解会让你的代规模达到20,000行。

突破这个瓶颈的关键是什么？对我而言，就是让事情保持简单。除非现在就非常需要，否则完全拒绝添加任何新特性或者新代码。我已经在Every Line Is a Potential Bug中提高了这一点（在Simple is Good之前还是一知半解）。梦工厂的首席特效架构师是这么理解的：

对我而言，照明工具成功的地方在于他选择了一系列容易使用和维护的小功能并且强大到足够成为一个非常棒的照明工具。

作为一名技术领导我明白我主要的贡献是对那些同事觉得非常重要但不能证明其合理的需求说“不”。但真正的诀窍是知道什么需求增加了线性的复杂度（只和自身相关）和指数级复杂度（和别的需求有关联）。两者都因该去避免，但后者需要更令人信服的理由。

举个例子，在2012年，Linux内核有1500万行代码。其中75％是具有线性复杂度的（驱动，文件系统和处理器结构相关的代码）。你可能有许多视屏驱动，但他们之间没有任何（或很少）的交互。剩下的则有更多的依赖关系。

Dijkstra觉得很难去教授这些先进的方法，因为他们只对那些2万行或者20万行的程序才有意义。任何的类或者规范必须限制其示例在几百行以内，暴力方法在这里也同样适用。你真的需要范例给你显示30,000行代码然后证实因为程序上手并不是非常复杂所以新功能能够很容易的被添加。但这实际上是不可能的。.

我不知道做出什么改变来突破20万行的瓶颈。我最近已经切换到了更纯粹的函数式风格并减少了可变状态，也许这些能让我有所突破。

而且我很想知道到代码量达到2000万行的时候会变成什么样子。

在三百万到四百万行代码左右似乎有一道无形的墙，无论多少人（数以百计）或多少年（数十年）花在上面增长率将会显著降低。－Dan Wexler