今天在公司開會的時候，一位作者好友透過MSN通知我Scott的BLOG上果然開始出現了Silverlight 3的消息，我一聽不得了，第一時間看了Scott的BLOG，大意是說，Silverlight 2在今年推出正式版之後，在一個月內，已經有超過100 million(哇哇，超過一億? 會不會太誇張??? 應該是很多機器overlap的重新計算了吧，像是我，至少裝了30次)機器安裝了Silverlight 2(不過，聽起來微軟好像對這個數字很爽的感覺^_^)。

而且，還有很多Sivlerlight 2使用在產品中的真實案例(嘿嘿，當然，內舉不避親，其中我覺得最重要的，就是K2的blackpoint，如果有人對這個產品有興趣，可以跟我聯絡)，足以證明Silverlight 2是一個可以真實應用的開發工具。

接著Scott趁勝追擊的說，將在next year推出下一個版本的Silverlight 3，令人興奮的部分是，在大家開罵了很久之後，終於，終於，可以在Visual Studio和Visual Web Developer Express當中以所視即所得的方式設計Silverlight了，Data Binding的部分也有工具(Wizard)可以設定，而不需要手動去下Code(剛好這件事情就是那天去參加好友的seminar後，在路上和他討論的問題，嘿嘿，沒想到他還真有先見之明)，另外加上對3D的支援，以及對H.264 video格式的support...總括一句話，就是功能越來越強就對了(老實說，就是Silverlight的WPF化)，然後Scott暗示大家趕快投入開發的行列，因為早晚有一天，Silverlight會把Fl?x幹掉(後面這句話是我自己加的...^_^)

看了這一篇BLOG之後，我挺有感概，技術變化得太快了，對於寫書的作者來說，會不會是一個很大的打擊呢?Silverlight 1.0的書才剛出，Silverlight 2.0就馬上Beta 1，現在Sivlerlight 2的書還沒出，馬上就有Silverlight 3的消息，是怎樣?拼進度嗎?

回頭想想，到底是哪個環節出問題? 是外國人太快，還是我們太慢? 老實說，我相信大家都沒什麼內幕消息，而且現在到處都是BLOG，訊息非常透明，要有秘密也不容易,也就是說，這些Roadmap是大家早已知道的，而且三五不時釋出一些消息早已是常態，所以開發人員應該要習慣這樣的狀況。

ASP.NET不也是這樣? ASP.NET 2.0出沒多久，又多了一個ASP.NET AJAX 1.0(而且回想一下，AJAX 1.0出之前，Altas炒了多久?)，又沒多久ASP.NET Futures出現了，然後接著是ASP.NET MVC Preview…、然後是ASP.NET 3.5，出了不到半年，馬上來個ASP.NET 3.5 SP1，然後PDC剛過，ASP.NET 4.0的Roadmap就丟了出來…搞什麼???

無言，改版更新已經是常態，從過去的一年、一個月、變成一季、每個月、加上BLOG推波助瀾，你會覺得幾乎每周都有新的東西，資訊是自由流通了，開發人員其實是很幸福的，隨手就能掌握最新資訊，有點蓋茲當年說『資訊隨手可得』的味道…

技術變更的那麼快，是不是真的會讓開發人員很辛苦呢? 仔細想想，其實不盡然，因為變與不變之間，是有那麼一條線存在的。

如果你追的是技術，我要說確實，你可能真的會追得很辛苦，開發技術是一直在變的，學會特定的技術不見得會幫助你成長，頂多只能幫助你『解決問題』。是的，這些技術都是在解決特定的問題，有問題、有解決方案、有新問題、有新的解決方案，如此而已。

技術會過時，毫無疑問，會的，但是累積的經驗不會，過去的COM過時了，過去的DAO、RDO、ADO過時了，甚至Web Services可能也要過時了，但是當面對新東西、面對ADO.NET、面對LINQ、面對WCF、REST…，我要說，如果過去你學的扎實，你會知道為什麼這些新技術會誕生，每一個技術的誕生都是為了解決過去的問題，彌補不理想的部分、如果過去的底子厚，新技術難不倒你，你會觸類旁通，久而久之，你會從技術的follower變成forerunner，最後成為技術的Leader。

但是如果一開始學習時，只是速成式的囫圇吞棗，如果你只知道怎麼用一們技術，卻不明白為何需要這個技術，例如：很多人知道『物件導向』，卻不知道為何需要『物件導向』或是『物件導向』技術的目標與優點，那問題就很大了，同樣的，你上面把這句話中的『物件導向』四個字，換成LINQ、WCF、WF、Silverlight…，換成哪一個term都行，因為放諸四海皆準)

知其然而不知其所以然，會有蠻大的問題，在學習的過程當中，這些技術沒有『內化』成你的一部分，這會是一個很大的問題，在ASP.NET技術中，很多部分也是這樣，有很多工具我們都會用，但是不盡然知道為什麼，當然我能理解，因為現在專案的特性，需求變動大、結案時間短，架構、規畫這些東西根本不在很多開發人員的考量當中，許多開發人員只是希望能夠盡快用自己熟悉的技術做完專案，然後結案領錢，說實在的，因為規模不夠大，所以也不見得有辦法用足夠的預算談規格，如果是價格標就更有可能是這樣。

所以我們手上有很多速成式的開發工具，很快速的幫助你完成一個系統，它的取向是速成，但是卻拋棄了架構和延展性，ASP.NET中的幾個XXXXview控件就是典型的例子(不過我要強調，它不見得是這些控件不支援，只是很多開發人員選擇走捷徑，把SqlDataSource和xxxxView拉一拉了事，完全不管這樣的結果會如何)。

這讓我想到『尼可拉斯凱吉』演的『氣象人』，其中有一段話，因為主角常被路人拿速食(例如熱狗、漢堡、可樂…)ㄎㄟ，他不明白為什麼，後來靜下心來，他發現自己就像速食，每天在電視台上報氣象，短短五分鐘，沒什麼營養，但是卻能夠馬上吃飽，看起來有模有樣，年薪很高，但是骨子裡卻很空洞。

我發現這個對速食的描述真是太好了：『很快能吃飽，但是卻沒什麼營養』。在我們這個時代，實在有太多東西是這樣的了，我們很快的兜出一個解決方案，迅速滿足客戶的需求，客戶在煞那間似乎覺得飽了，但是老實說這樣的解決方案沒啥營養，不能長久的徹底的解決問題，但是似乎大家也接受了。我們的學習也是這樣，速食導向，在學校裡學了很多的技術，把大家餵的飽飽的，但是是不是很有營養，真的很難說，有多少技術出了學校就在也沒用過了，或許我們要學的是觀念，而不只是技巧…

我自己也檢討了一下，是不是我們寫書時也會掉到這樣的陷阱中，塞了很多東西把讀者餵飽，頁數厚厚的，感覺很超值，但是營養卻不夠，很快的，大家就餓了。

過去這一年，我花在寫書的時間上很少，因為我對技術書有蠻強烈的消耗品的感覺，一張好聽的CD，我可能可以保留很多年，但是隨著資訊技術演變的速度，現在一本書放在架上可能不到一年半就要say goodbye了，讀者買了佔書架，搬家的時候也累，讓我覺得有點罪惡感，當然，我不是說寫書不好、或是大家不應該看書，反而我覺得大家應該多買書、多看書、不然很多全職的作者很辛苦的，而且如果好的書沒有被鼓勵，那有心的作者會越來越少…

而對我來說，我希望能慢慢調整，能夠寫一些可以長久的書，不會隨著技術的演變和改版而凋零的書，當然，新技術我們還是會介紹，但是BLOG不是比書來的迅速多了嗎?

以前我記得老師在指導我們如何蒐集資料時，提到一個觀念，如果大家希望找到最新的第一手資訊，那期刊或許可以滿足你的需求，但是如果你需要觀念，需要完整的引導、需要奠定基礎，那書本永遠是最好的選擇，一本書是作者『經年累月的經驗累積』。

『一本書是作者經年累月的經驗累積』，我對這句話很有感覺，我希望自己寫作，能夠在書本當中呈現的是經驗的累積，而非只是技術的介紹，畢竟現在以BLOG介紹新技術是最好的選擇，想到隨手就寫，沒有時間空間的限制。

而出一本書，我真的不想再被版本趕著跑，對讀者來說，我可能要Say Sorry(對出版社我也得說聲Sorry)，我很想寫的快，但是我更希望寫得好，畢竟一本可以對讀者長久有幫助的書，總比曇花一現的排行榜冠軍對我來說意義大的多。

面對新的技術，面對快速變動的技術，我真的覺得開發人員不需要擔心，因為經驗依舊是會累積的，開發人員的價值必須彰顯在你的經驗上，對於開發架構、對於規畫、對於專案運作的熟悉，比起對於特定技術的了解，更會是你與別人不同的競爭力和利基。

對於初學者，我想特別說句話：了解怎麼使用一種技術很重要，但是了解背後的原理、架構、和『為什麼』，一樣的重要…千萬別只是學會用一種技術，而不知道為何要用這種技術…
转载自.NET Walker (studyhost.blogspot.com) 。 博主- 董大伟 - 台湾微软MVP-最有价值专家。