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