本文是從 Complexity is the enemy 這篇文章翻譯而來。

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

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

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

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

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

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

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

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

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