本文是從 Complexity is the enemy 這篇文章翻譯而來(lái)。

　　差不多在Google工作有7個(gè)年頭了(!)。我在這學(xué)到了很多東西，寫(xiě)都寫(xiě)不完。然而不管怎樣，我至少要向你們分享一條只有在我有了更多經(jīng)驗(yàn)后才得到的東西。

　　復(fù)雜是軟件的死神。你無(wú)法用數(shù)字評(píng)估它所造成的代價(jià)，它會(huì)悄悄慢慢的出現(xiàn)，就像是用小火在煮你，讓軟件變得越來(lái)越糟，你很難察覺(jué)到，而當(dāng)你察覺(jué)到時(shí)，那已經(jīng)太晚了。在另一方面，你經(jīng)常的會(huì)很容易的看到增加復(fù)雜度帶來(lái)的好處：增加一個(gè)新的擴(kuò)展層，你可以實(shí)現(xiàn)新功能X，或把本來(lái)運(yùn)行在一個(gè)機(jī)器上的進(jìn)程分成兩個(gè)，用來(lái)解決當(dāng)前系統(tǒng)的擴(kuò)展瓶頸。但現(xiàn)在你的大腦里必須想著這個(gè)新增加的層，或這還要實(shí)現(xiàn)一個(gè)遠(yuǎn)程調(diào)用層來(lái)管理這兩臺(tái)機(jī)器。

　　基本上，程序員老手和新手一樣都很容易出現(xiàn)上面的情況。我認(rèn)為這些年我在這個(gè)行業(yè)里學(xué)到的只是更擅長(zhǎng)在兩者之前取得平衡；何時(shí)復(fù)雜一點(diǎn)是合理的，何時(shí)必須要拒絕。我經(jīng)常回想起一個(gè)朋友在Ken Thompson寫(xiě)的Go語(yǔ)言編譯器上的一句評(píng)論：它很快，因?yàn)樗鼪](méi)有做多少事，代碼直接明了。

　　事實(shí)表明，就像你能很容易的寫(xiě)出一篇很長(zhǎng)的博客但把相同的觀點(diǎn)敘述的簡(jiǎn)明扼要卻很難，你很難把軟件寫(xiě)的簡(jiǎn)單明了。在編程語(yǔ)言的設(shè)計(jì)上你最容易看出這一點(diǎn)；新手設(shè)計(jì)出的語(yǔ)言總是包含大量的功能特征，而很少像C語(yǔ)言那樣清爽明晰。如今的程序，動(dòng)不動(dòng)就牽涉多少個(gè)對(duì)象；這在分布式系統(tǒng)里就意味這你要移動(dòng)多少的東西。

　　另外一個(gè)用來(lái)描述這個(gè)問(wèn)題的詞是“才智”：引用另外一個(gè)C程序員的話，“調(diào)試糾錯(cuò)程序比第一次編寫(xiě)出這程序要困難兩倍，如果你是用盡了你所有的聰明才智寫(xiě)出這程序，那根據(jù)這定義，你就沒(méi)有最夠的才智去調(diào)試debug它了。”

　　建議嗎？我懷疑只有通過(guò)經(jīng)驗(yàn)才能理解這個(gè)道理——有一個(gè)事很刺激我，太多的項(xiàng)目里都有人認(rèn)為元數(shù)據(jù)編程很酷。我發(fā)現(xiàn)制定一個(gè)詳細(xì)的設(shè)計(jì)目標(biāo)來(lái)評(píng)估新代碼是否有必要，這很有幫助。如果你可以說(shuō)“這些代碼不能幫助項(xiàng)目的最初設(shè)計(jì)目標(biāo)上解決任何問(wèn)題”，你就能很容易的拒絕這些代碼。在Google，用來(lái)描述一個(gè)新項(xiàng)目的設(shè)計(jì)方案的文檔模板上，在其右上角有個(gè)區(qū)域?qū)ｉT列著目標(biāo)外內(nèi)容：對(duì)項(xiàng)目的合理擴(kuò)展將會(huì)被拒絕。

　　很諷刺的是，我發(fā)現(xiàn)使用弱智的工具或語(yǔ)言能幫助我們抵制復(fù)雜。你很難寫(xiě)出一個(gè)很復(fù)雜的C程序，因?yàn)樗锩鏇](méi)有太多的東西。C程序大多用大量的數(shù)組，因?yàn)槟阒荒苡盟Y(jié)果卻證明，數(shù)組是非常好的東西——緊湊的內(nèi)存使用，O(1)次的數(shù)據(jù)訪問(wèn)，很好的數(shù)據(jù)存儲(chǔ)。但我從來(lái)沒(méi)有倡導(dǎo)過(guò)特意的使用一種弱智的工具。相反，我的心得是：像C一樣編寫(xiě)Python程序。

it知識(shí)庫(kù)：復(fù)雜是大敵，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。