程序猿职业生涯中的 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万行的时候会变成什么样子。