程序猿職業生涯中的 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萬行的時候會變成什麼樣子。