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**。
Google工程師 複雜是軟體的死敵
google開發工程師evan martin近日在其個人 發表了一篇博文 complexity is the enemy 文章中指出複雜是軟體的死敵，新 的引入是否增加了軟體的複雜度，是否應該加入，要依據是否符合專案特定設計目標來判定，在文末作者指出應該像c語言那樣寫python 現把此文進行了翻譯...
Google工程師 複雜是軟體的死敵
google工程師 複雜是軟體的死敵 google開發工程師evan martin近日在其個人 發表了一篇博文 complexity is the enemy 文章中指出複雜是軟體的死敵，新 的引入是否增加了軟體的複雜度，是否應該加入，要依據是否符合專案特定設計目標來判定，在文末作者指出應該像c語言...
如何成為Google軟體工程師？
原文 http www.google.com.hk intl zh cn jobs lifeatgoogle meet 招聘的流程？簡歷篩選 訪談 現場面試 offer發放 面試包括哪些內容？如何對申請人的工程技能進行評估？我們會根據以下四個方面來進行評估 如何準備面試？認識google員工？和他聊...