Google開發(fā)工程師Evan Martin近日在其個(gè)人網(wǎng)站發(fā)表了一篇博文《Complexity is the enemy》，文章中指出復(fù)雜是軟件的死敵，新代碼的引入是否增加了軟件的復(fù)雜度，是否應(yīng)該加入，要依據(jù)是否符合項(xiàng)目特定設(shè)計(jì)目標(biāo)來判定，在文末作者指出應(yīng)該像C語言那樣寫Python代碼。現(xiàn)把此文進(jìn)行了翻譯，全文如下：
這是我在Google工作的第七個(gè)年頭了，在Google我學(xué)到了很多東西，遠(yuǎn)比我可以寫下來的多得多。我想我至少可以和你們分享其中的一些。
復(fù)雜是軟件的死敵，它很難估值，常慢慢地混入到軟件開發(fā)中。它像一個(gè)逐漸變爛的膿包，發(fā)現(xiàn)它時(shí)，為時(shí)已晚。從另一方面來講，增加復(fù)雜度可以幫你解一時(shí)之憂：一個(gè)新的間接層允許增加新的特性X，但同時(shí)你需要增加另外一個(gè)間接層；把運(yùn)行在一個(gè)機(jī)器上的過程分隔成運(yùn)行于兩個(gè)機(jī)器上的過程，可以幫你解決當(dāng)前遇到的擴(kuò)展難題，但你同時(shí)也必須實(shí)現(xiàn)一個(gè)RPC層，來管理這兩個(gè)機(jī)器。
上面所說的現(xiàn)象在開發(fā)者新人中和在老手中一樣突出。通過這幾年的工作，我認(rèn)為我已經(jīng)可以很好地在這方面達(dá)到平衡，什么時(shí)候應(yīng)該增加軟件的復(fù)雜性，什么時(shí)候應(yīng)該拒絕。我常�；叵胍粋�(gè)朋友對(duì)Ken Thompson所開發(fā)的Go語言編譯器的評(píng)價(jià)：它很快，因?yàn)樗蛔龊苌俚墓ぷ�，它的代碼十分簡(jiǎn)單易懂。
寫一篇長(zhǎng)長(zhǎng)的博客容易，而用簡(jiǎn)短的話來概括相同的觀點(diǎn)卻很難，同樣的道理，開發(fā)一款簡(jiǎn)小而優(yōu)秀的軟件是很困難的。在程序語言設(shè)計(jì)中，此種現(xiàn)像很普遍。新手所開發(fā)的新語言包含過多的屬性，很少具有C語言的簡(jiǎn)明和清晰。在今天的程序開發(fā)中，程序的優(yōu)劣與其包含多少個(gè)對(duì)象有關(guān)，在分布式系統(tǒng)中，則與有多少個(gè)可移動(dòng)的部分有關(guān)。
針對(duì)此問題的另一個(gè)詞語是“精巧”：再引用這位C語言大牛的一句話，“調(diào)試代碼比寫代碼困難兩倍之多，所以，你如果寫的代碼盡可能的精巧，理論來講，你很難對(duì)它進(jìn)行完美地調(diào)試�！�
什么可以幫助解決這個(gè)問題呢？是否只能依靠經(jīng)驗(yàn)?zāi)�？我發(fā)現(xiàn)，通過特定的設(shè)計(jì)目標(biāo)來評(píng)估新代碼可能會(huì)有幫助。如果你說“這并不能幫助解決項(xiàng)目的最初目標(biāo)”，那么可以很容易地把新代碼否定掉。在Google，每個(gè)新項(xiàng)目的設(shè)計(jì)模版文檔的開頭都有一個(gè)“ non-goals”列表：你應(yīng)該拒絕的合理的項(xiàng)目擴(kuò)展。
很諷刺的是，我發(fā)現(xiàn)了一個(gè)很“差勁”的工具，它可以幫助減低軟件的復(fù)雜度。用C語言寫一段很復(fù)雜的程序很難，因?yàn)樗軐?shí)現(xiàn)的功能有限。C語言通常會(huì)使用大量的數(shù)組，而且你只能使用這些數(shù)組，但是這些數(shù)組功能很強(qiáng)大——可以壓縮存儲(chǔ)器表達(dá)式，如O(1) ，可以很好的定位數(shù)據(jù)位置。我從未有意地提倡使用這個(gè)“差勁”工具，然而我所得到的應(yīng)驗(yàn)是：像C語言那樣寫Python代碼。
