在2011年JohnD.Cook寫(xiě)了一篇博客，其中提到：

我的朋友CliftNorris發(fā)現(xiàn)了一個(gè)基本常數(shù)，我稱之為Norris常數(shù)，一個(gè)未經(jīng)培訓(xùn)的程序員在他或她遇到瓶頸之前能寫(xiě)出的平均代碼量。Clift估計(jì)這個(gè)值是1500行。超過(guò)這個(gè)數(shù)以后，代碼會(huì)變得如此混亂，以至于本人都無(wú)法輕而易舉的進(jìn)行調(diào)試和修改。

我還不了解足夠多的初級(jí)程序員來(lái)驗(yàn)證這一結(jié)果，不過(guò)我自己認(rèn)識(shí)到，程序員生涯的下一個(gè)瓶頸將發(fā)生在20,000行。我把Norris常數(shù)改成2,000那樣正好變成十倍。

在我離開(kāi)大學(xué)之后的第一份工作中，我和我的同事一樣（和我差不多年紀(jì)）反復(fù)遇到了20,000行的瓶頸。在夢(mèng)工廠我們有950個(gè)程序給動(dòng)畫(huà)師使用，行數(shù)統(tǒng)計(jì)顯示多的一些基本在20,000至25,000行。超過(guò)這個(gè)數(shù)的話即再多的努力也無(wú)法增加新特性了。

在1996年年中的時(shí)候我負(fù)責(zé)編寫(xiě)夢(mèng)工廠的照明工具（和另外兩個(gè)程序員），我知道這將遠(yuǎn)遠(yuǎn)超過(guò)20,000行代碼。我改變了我的編程方法并且這個(gè)工具一年后以大約200,000行的代碼量成功交付。（這個(gè)工具計(jì)劃于2013年退役，在16年時(shí)間里它被每天使用并用來(lái)拍攝了21部電影。）我因?yàn)閷?xiě)了好幾個(gè)行數(shù)在10萬(wàn)到20萬(wàn)的程序，我很確定我遇到了下一個(gè)瓶頸，我已經(jīng)能夠能感覺(jué)到它。

特別難的部分是和一些沒(méi)有像你一樣打破了好幾道瓶頸的人討論技術(shù)。打破這些瓶頸意味著做出不同的取舍，特別是一些短期內(nèi)看起來(lái)不合理但以后會(huì)有所幫助決定。這很難去爭(zhēng)論，短期內(nèi)的優(yōu)點(diǎn)是顯而易見(jiàn)的，但我無(wú)法說(shuō)服任何人說(shuō)從現(xiàn)在起一年內(nèi)可能有人會(huì)做出一個(gè)看似無(wú)害但是會(huì)破壞現(xiàn)有代碼的改動(dòng)。

EdsgerDijkstra在1969年寫(xiě)道：

一個(gè)一歲多的孩子會(huì)以一定的速度匍匐前進(jìn)，比如說(shuō)每小時(shí)一英里。但每小時(shí)一千英里的速度就是一架超音速噴氣機(jī)。就物體的移動(dòng)能力而言這兩者是沒(méi)有可比性的，任何其中一個(gè)可以到的但是另一個(gè)不能做到，反之亦然。

一個(gè)Clift所指的初級(jí)程序員，學(xué)會(huì)了爬行，接著蹣跚學(xué)步，然后行走，然后慢跑，然后再跑步，最后沖刺，他認(rèn)為，“以這樣加速度前進(jìn)我可以趕上超音速噴氣機(jī)的速度０但他跑進(jìn)了2,000行的極限，因?yàn)樗募寄懿粫?huì)再按比例增加。他必須改變移動(dòng)方式，比如開(kāi)車去獲得更快的速度。然后，他就學(xué)會(huì)了開(kāi)車，開(kāi)始很慢，然后越來(lái)越快，但有進(jìn)入到了20000行極限。駕駛汽車的技術(shù)不會(huì)變成開(kāi)噴氣式飛機(jī)。

我的朋友BradGrantham用新手程序員用“蠻力”解決問(wèn)題來(lái)說(shuō)明了這一點(diǎn)。我認(rèn)為這是正確的：當(dāng)代碼是在2,000行以下，你可以寫(xiě)任何混亂骯臟的代碼并依靠你的記憶拯救你。深思熟慮的類和包分解會(huì)讓你的代規(guī)模達(dá)到20,000行。

突破這個(gè)瓶頸的關(guān)鍵是什么？對(duì)我而言，就是讓事情保持簡(jiǎn)單。除非現(xiàn)在就非常需要，否則完全拒絕添加任何新特性或者新代碼。我已經(jīng)在EveryLineIsaPotentialBug中提高了這一點(diǎn)（在SimpleisGood之前還是一知半解）。夢(mèng)工廠的首席特效架構(gòu)師是這么理解的：

對(duì)我而言，照明工具成功的地方在于他選擇了一系列容易使用和維護(hù)的小功能并且強(qiáng)大到足夠成為一個(gè)非常棒的照明工具。

作為一名技術(shù)領(lǐng)導(dǎo)我明白我主要的貢獻(xiàn)是對(duì)那些同事覺(jué)得非常重要但不能證明其合理的需求說(shuō)“不”。但真正的訣竅是知道什么需求增加了線性的復(fù)雜度（只和自身相關(guān)）和指數(shù)級(jí)復(fù)雜度（和別的需求有關(guān)聯(lián)）。兩者都因該去避免，但后者需要更令人信服的理由。

舉個(gè)例子，在2012年，Linux內(nèi)核有1500萬(wàn)行代碼。其中75％是具有線性復(fù)雜度的（驅(qū)動(dòng)，文件系統(tǒng)和處理器結(jié)構(gòu)相關(guān)的代碼）。你可能有許多視屏驅(qū)動(dòng)，但他們之間沒(méi)有任何（或很少）的交互。剩下的則有更多的依賴關(guān)系。

Dijkstra覺(jué)得很難去教授這些先進(jìn)的方法，因?yàn)樗麄冎粚?duì)那些2萬(wàn)行或者20萬(wàn)行的程序才有意義。任何的類或者規(guī)范必須限制其示例在幾百行以內(nèi)，暴力方法在這里也同樣適用。你真的需要范例給你顯示30,000行代碼然后證實(shí)因?yàn)槌绦蛏鲜植⒉皇欠浅?fù)雜所以新功能能夠很容易的被添加。但這實(shí)際上是不可能的。

我不知道做出什么改變來(lái)突破20萬(wàn)行的瓶頸。我最近已經(jīng)切換到了更純粹的函數(shù)式風(fēng)格并減少了可變狀態(tài)，也許這些能讓我有所突破。

而且我很想知道到代碼量達(dá)到2000萬(wàn)行的時(shí)候會(huì)變成什么樣子。

在三百萬(wàn)到四百萬(wàn)行代碼左右似乎有一道無(wú)形的墻，無(wú)論多少人（數(shù)以百計(jì)）或多少年（數(shù)十年）花在上面增長(zhǎng)率將會(huì)顯著降低。－DanWexler

如需學(xué)習(xí)軟件開(kāi)發(fā)相關(guān)課程，請(qǐng)聯(lián)系站客服，一對(duì)一提供培訓(xùn)內(nèi)容講解服務(wù)~