程序猿职业生涯中的 Norris 常数

　　我的朋友Clift Norris发现了一个基本常数。我称之为Norris常数，一个未经培训的程序猿在他或她遇到瓶颈之前能写出的平均代码量。Clift预计这个值是1500行。

超过这个数以后，代码会变得如此混乱，以至于本人都无法轻而易举的进行调试和改动。

　　我还不了解足够多的0基础程序猿来验证这一结果，只是我自己认识到，程序猿生涯的下一个瓶颈将发生在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 所指的0基础程序猿，学会了爬行，接着蹒跚学步，然后行走，然后慢跑。然后再跑步，最后冲刺。他觉得，“以这样加速度前进我能够赶上超音速喷气机的速度!“但他跑进了2,000行的极限，由于他的技能不会再按比例添加。他必须改变移动方式，比方开车去获得更快的速度。然后，他就学会了开车，開始非常慢。然后越来越快，但有进入到了20000行极限。驾驶汽车的技术不会变成开喷气式飞机。

　　我的朋友Brad Grantham用新手程序猿用“蛮力”解决这个问题来说明了这一点。我觉得这是正确的：当代码是在2,000行下面，你能够写不论什么混乱肮脏的代码并依靠你的记忆解救你。

深思熟虑的类和包分解会让你的代规模达到20,000行。

　　突破这个瓶颈的关键是什么?

对我而言。就是让事情保持简单。除非如今就很须要，否则全然拒绝加入不论什么新特性或者新代码。我已经在Every Line Is a Potential Bug中提高了这一点(在Simple
is Good之前还是一知半解)。梦工厂的首席特效架构师是这么理解的：

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

　　作为一名技术领导我明确我基本的贡献是对那些同事认为很重要但不能证明其合理的需求说“不”。但真正的诀窍是知道什么需求添加了线性的复杂度(仅仅和自身相关)和指数级复杂度(和别的需求有关联)。两者都因该去避免，但后者须要更令人信服的理由。

　　举个样例。在2012年，Linux内核有1500万行代码。当中75%是具有线性复杂度的(驱动。文件系统和处理器结构相关的代码)。你可能有很多视屏驱动。但他们之间没有不论什么(或非常少)的交互。

剩下的则有很多其它的依赖关系。

　　Dijkstra认为非常难去教授这些先进的方法。由于他们仅仅对那些2万行或者20万行的程序才有意义。不论什么的类或者规范必须限制其演示样例在几百行以内，暴力方法在这里也相同适用。你真的须要范例给你显示30,000行代码然后证实由于程序上手并非非常复杂所以新功能可以非常easy的被加入。但这实际上是不可能的。.

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

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