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