最隐晦的程式設計指引(轉)

一、百家争鳴

    俗話說，程式員半年不學新東西，就變奧特曼（out man，過時之人）了。IT行業可以說是變化最快的行業，每年都有大量的新概念、新術語、新技術被創造出來，在多數人還在一頭霧水時，“更好的”替代品又被創造出來。别的不說了，單說設計方法。

    想當年靜态類型系統是王道，誰要是搞點運作時動态綁定、用點VB什麼的，經常會被鄙視。而今動态類型語言大熱，常有人高呼Python萬歲，JavaScript身價百倍，C#也加入了動态類型支援。當年面向對象與過程式程式設計争吵不休，如今大家都在盯着函數式模式，C#和C++0x都加入了函數式語言特性。當我們學面向對象時，Gang of Four（據證明，這個書名确實是四人幫的英文翻譯，故意調侃四位作者為壞家夥之意。）的設計模式流行起來了，當我們學Gang of Four時，其中一些模式被批為重複、過時、不宜的，一批表達新觀點的書籍出版了（如Agile Modeling with Patterns)。當我們開始嘗試靈活方法時，模型驅動開發（Model Driven Development）遍布書刊封面和新聞頭條，而當我們學用Rose、Visio畫UML時，測試驅動開發（Test Driven Development）被提出來了。

    當然，曆史的發展也常常會出人意料。人們曾經認為，動态的web必定需要Flash這樣的新解決方案，而今HTML5+JavaScript不但可以取代Flash，還可以做3D應用。人們曾經認為，WebService需要一套新的行業标準，于是指定了SOAP等一系列協定，并曆時數年時間開發了大量WebService平台和相關工具，而如今大家更喜歡基于基本的HTTP協定的REST方式和JavaScript本身的JSON資料協定，而且要簡單高效得多。

    但究竟什麼才是好的設計呢？如果靜态類型系統才算好，那麼大量優秀的動态類型語言程式算什麼？如果面向對象才算好，那麼大量優秀個過程式、函數式程式算什麼？當年不知道匈牙利表示法的程式員就不是好coder，如今微軟的态度是，别再提了。曾經OLE的程式員可以拿到高一倍的薪水，如今誰還會提OLE。Java陣營前些年喜歡嘲笑微軟不懂Pattern，以緻微軟這些年有事沒事地把Pattern挂在嘴邊，但是如今被批評得一無是處的COM（1993）卻是在Java誕生（1995）前就完美地實作了大多數的Java常用Pattern。既然COM被評價得這麼爛，業界卻搞出了一個和DCOM/COM+非常類似的CORBA。

    代碼品質管理也是近些年的新熱點，除了FxCop等傳統檢查分析工具外，計算複雜度的Cyclomatic Complexity方法和Test Coverage等量化分析得到了非常多的關注。這些工具對源碼宏觀分析提供了有效的手段。但分數高就代表代碼品質一定高嗎？尤其是對不懂技術的管理層，這些統計結果很容易成為财務報表一樣的存在。

二、事有本末

    退一步想，當我們學自己的母語時，我們是先會說話還是先學文法呢？當我們學外語時，是先學說話還是先學文法呢？當我們讀一首詩時，我們是先感覺到好還是先用各種規則去衡量它呢？當被要求說明哪裡好時，是直接就說得出來還是要去借用各種規則來描述它的好？你是否隐約感覺到，有某種先于規則、方法存在的東西，但又難以言表，而必須用各種規則來間接地去描述它？

    有個春秋時期的故事，說齊桓公在堂上讀書，工匠輪扁在堂下幹活。輪扁問桓公說，敢問公讀的什麼書？桓公答，聖人之言。輪扁問，聖人還在嗎？桓公答，已經死了。輪扁于是說，那麼您讀的就是古人的糟粕了。桓公大怒，說，寡人讀書，輪得到你個車輪匠議論嗎！說得出道理則罷，說不出就去死！輪扁答，用臣砍造車輪來說，慢了會甘滑而不牢固，快了會苦澀而難以敲入。唯有不快不慢，得于手而應于心。其中門道我也表達不出來，也無法傳授給我兒子，是以如今七十歲了還在造輪子。聖人和他不可傳的東西都已經消失了，那麼您所讀的，不就是剩下來的糟粕了嗎？

    但是，因為這個精髓的東西難以說明，我們要麼得在不斷實踐中慢慢領悟，要麼學習别人總結出的方法來接近它。但是，人們經常糾結于方法本身。

    心都子講過一個故事，說兄弟三人在齊魯學儒術，學成回家，父親問他們，仁義之道是什麼？老大答，仁義使我愛身而後名。老二答，仁義使我殺身以成名。老三答，仁義使我身名并全。三個回答相反，卻又同出于儒，誰是誰非？你糾結了嗎？

    有句經常被引用的話：Any software problem can be solved by adding another layer of indirection. ——Steven M. Bellovin 其實原文後面還有半句：But that usually creates another problem.

    有個Java程式員寫過一篇很有趣的blog。大意說，有個人要釘個釘子挂畫框，于是去工具店買個錘子。店主說，No，我們已經不賣錘子了。錘子有很多種，大錘、拔釘錘、圓頭錘等等，如果你買了一個，之後又發現你還需要另一個怎麼辦？多數人隻想要一把錘子，是以我們推出了萬能錘，可以當各種錘子使用。買者想想也是，那就買一把萬能錘吧。店主說，No，萬能錘已經被淘汰了。你想，萬能錘雖然可以當各種錘子用，但它做什麼活都沒有專門用途的錘子好使。是以，我們開始賣錘子工廠，這樣你可以随時制造最合适的錘子。買者說，但我并不想買個工廠……店主說，沒錯，是以它已經被淘汰了。我們研究發現，不是所有的使用者都需要生産所有類型的錘子，是以我們開始賣錘子工廠設計圖，這樣使用者可以根據自己的需要定制工廠。買者說，我猜這個也淘汰了吧？店主說，沒錯，我們研究發現，使用者并不想自己建造一個工廠。于是我們推出了建造錘子工廠的工廠，來幫助使用者建造錘子工廠……

三、殊途同歸

    我們可以回想，在我們知道設計模式之前，難道我們就沒有在用這些方法嗎？之是以叫Pattern，就是因為它至少已經被重複運用三次以上，是以我們把它單獨拿出來，賦予一個名字。所謂“新Pattern”就是一個悖論。Pattern的最大作用不是教人怎麼做，因為面臨同樣問題時，大家多少會想出類似的解決方案；Pattern最大的作用，在于提供了一種共識、一套共通的術語，使開發人員間可以友善的交流一些複雜的系統概念。當然，有的人學了設計模式後會有眼前一亮的感覺，這是因為切身體驗諸多問題的苦惱，突然得到解決之道，于是豁然開朗。而對有的人，沒有體驗過痛苦，隻是聽說Pattern是好的，于是就開始在代碼裡羅列Pattern。

    同理的，雲計算是什麼全新的東西嗎？WebService是什麼全新的東西嗎？之前就沒有類似的問題需要解決，就沒有類似的解決方案嗎？如果讓你穿越到它們誕生前，從頭解決這些分布式計算的問題，你會不會做出一個類似的解決方案？那麼，又是什麼使你能夠發明這些新東西呢？是不是基本技能在特定問題下的一次應用呢？

    不管用哪種途徑，用這套方法也好，那套方法也好，隻靠自己琢磨也好，走對的話，都是通往同一條大道。不要把自己圈在一個小圈子裡，圈子越小，越容易偏執。站得越高，看得越遠，眼前的景色越壯麗，所謂的是非對錯，不過是遠處的一點而已。

    但是但是，現實中，不是所有的問題都是能由開發人員解決的，也不是所有的人都想要解決問題。流程、方法、思想、工具等，不管看起來再好，在不想解決問題的人面前，連個屁都不算。一個項目決定時的天時地利人和，已經八九成決定了項目的結局。當然，怨天尤人也沒用，上天總是會給人幾次機會的，機會到來時能不能抓得住，就看個人修為了。

本文轉自 你聽海是不是在笑 部落格園部落格，原文連結：http://www.cnblogs.com/nuaalfm/archive/2011/07/27/2118399.html  ，如需轉載請自行聯系原作者