|
|
本文是從 Complexity is the enemy 這篇文章翻譯而來。
差不多在Google工作有7個年頭了(!)。我在這學到了很多東西，寫都寫不完。然而不管怎樣，我至少要向你們分享一條只有在我有了更多經驗后才得到的東西。
復雜是軟件的死神。你無法用數字評估它所造成的代價，它會悄悄慢慢的出現，就像是用小火在煮你，讓軟件變得越來越糟，你很難察覺到，而當你察覺到時，那已經太晚了。在另一方面，你經常的會很容易的看到增加復雜度帶來的好處：增加一個新的擴展層，你可以實現新功能X，或把本來運行在一個機器上的進程分成兩個，用來解決當前系統的擴展瓶頸。但現在你的大腦里必須想著這個新增加的層，或這還要實現一個遠程調用層來管理這兩臺機器。
基本上，程序員老手和新手一樣都很容易出現上面的情況。我認為這些年我在這個行業里學到的只是更擅長在兩者之前取得平衡；何時復雜一點是合理的，何時必須要拒絕。我經?；叵肫鹨粋€朋友在Ken Thompson寫的Go語言編譯器上的一句評論：它很快，因為它沒有做多少事，代碼直接明了。
事實表明，就像你能很容易的寫出一篇很長的博客但把相同的觀點敘述的簡明扼要卻很難，你很難把軟件寫的簡單明了。在編程語言的設計上你最容易看出這一點；新手設計出的語言總是包含大量的功能特征，而很少像C語言那樣清爽明晰。如今的程序，動不動就牽涉多少個對象；這在分布式系統里就意味這你要移動多少的東西。
另外一個用來描述這個問題的詞是“才智”：引用另外一個C程序員的話，“調試糾錯程序比第一次編寫出這程序要困難兩倍，如果你是用盡了你所有的聰明才智寫出這程序，那根據這定義，你就沒有最夠的才智去調試debug它了。”
建議嗎？我懷疑只有通過經驗才能理解這個道理——有一個事很刺激我，太多的項目里都有人認為元數據編程很酷。我發現制定一個詳細的設計目標來評估新代碼是否有必要，這很有幫助。如果你可以說“這些代碼不能幫助項目的最初設計目標上解決任何問題”，你就能很容易的拒絕這些代碼。在Google，用來描述一個新項目的設計方案的文檔模板上，在其右上角有個區域專門列著目標外內容：對項目的合理擴展將會被拒絕。
很諷刺的是，我發現使用弱智的工具或語言能幫助我們抵制復雜。你很難寫出一個很復雜的C程序，因為它里面沒有太多的東西。C程序大多用大量的數組，因為你只能用它，但結果卻證明，數組是非常好的東西——緊湊的內存使用，O(1)次的數據訪問，很好的數據存儲。但我從來沒有倡導過特意的使用一種弱智的工具。相反，我的心得是：像C一樣編寫Python程序。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
