技術的變與不變之間...Silverlight 3.0的驚鴻一撇

今天在公司開會的時候,一位作者好友透過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),我很想寫的快,但是我更希望寫得好,畢竟一本可以對讀者長久有幫助的書,總比曇花一現的排行榜冠軍對我來說意義大的多。

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

對於初學者,我想特別說句話:了解怎麼使用一種技術很重要,但是了解背後的原理、架構、和『為什麼』,一樣的重要…千萬別只是學會用一種技術,而不知道為何要用這種技術…

留言

匿名表示…
蠻同意後面的感慨,寫書可以寫比較精華的解決方式(您的著作都已偏向這樣了),雖然解法上都有其背景,但若把這些都寫出來,初學者可能會因資訊過量而頭痛。

我很喜歡去比較分析,假如程式照抄可行但我邏輯無法領會的,我會重新改寫。雖然對多數人來說這樣太苛求自我,但從中學到的經驗及體會多更多。

我寫的code不快,但都是經過考量設計,並考量到未來及過去可能會遇到的問題作規劃,所以寫出來的東西很少需要再大修。但staff不是這樣,不常看書卻寫code很快,review其code時是膽顫心驚,因此其中隱憂,很多洋人都撰寫說過了。

不看書不比較分析,當然寫code很快,但寫出來的東西能不能登堂入室,甚至讓新人觀摩學習時看得霧剎剎,我覺得這很丟臉且浪費自己的生命意義。
匿名表示…
SL 支持 3D,等於讓 SL 變成 WPF 化,
下載檔案會爆增,考驗網絡頻寬和使用者的耐心,尤其是台灣又貴以慢的獨大頻寬供應商的環境下。

希望不要步上多年前 Java Applet 的後塵,
大幅拖累整個 Web Application 的性能和速度
David寫道…
to tomexou,
現在認真的人不多了,能夠先想過,再動手寫程式的人也不多了,現在很多人是先寫再說,結果當然就@(*^#*$&,我相信,成功是屬於認真的人的^_^
David寫道…
to Wizard,
是的,這也是我一看到當時就有點擔心的問題,從很多角度看到Silverlight有慢慢WPF化的趨勢,但是畢竟WPF是個很臃腫的龐然大物,如果從跨平台的角度來看確實不妥,顯然這是MS要去努力思考和解決的問題。
匿名表示…
看完了老師的文章,讓我心有所感。對於廠商來講,不斷的推出新技術,試圖領導時代潮流,這樣才能掌握"錢"景,本來就是很自然的事。

以遊戲界來說,當年sony ps2 稱霸,微軟試圖以xobx 挑戰敗下陣來,但是不多時,微軟硬是砸下大錢,推出xbox360硬是靠銀彈攻勢把ps2 打敗,逼的sony 不得不加緊推出ps3。當然,如果今天xbox360同樣被ps3打敗,我想微軟還是會繼續砸下大錢,推出xbox720,試圖再一次以金錢創造的技術來重新取得領導市場的地位。遊戲界如此,軟體界亦然。

不斷不斷的推出新技術,舊的技術還沒學會,又再度推出新的技術。為的也是為了要打擊對手,試圖重新取得技術領先的地位,達成賺錢的目的。

但對於使用者來說,一直追著新技術跑,成為廠商希望創造出的結果,對自己絕對不是好事。真正的高手,就是能夠在不斷的變動之中,掌握那長久不變的,進而使用這些核心不變的本質,去適應不斷變化的環境。

對這些人來說,因為他掌握了核心,所以不管技術怎麼變動,他只要花少少的時間就可以適應掌握運用了,不論新技術再怎麼變化,對他來說都是易如反掌。

反之,如果不能掌握核心,只是不斷隨著廠商的腳步起舞,今推推出新技術A就學A,推出新技術B就學B,這樣的話永遠都只能成為環境變動下的犧牲者,而不能成為時代的創造者。

所以,讀者真正想看的,也就是這種可以超越各種變動技術,並將其一貫連結起來的知識。
學一種觀念知識,就可以適用各種變化的技術。也就是掌握了核心與本質。

而這種知識的整理與掌握,對初學者來說是絕對不可能做到的,這必須仰賴有大量經驗與知識的人,將其整理集中,歸納出所有技術都共用的結晶。如果能夠有這樣的品質保證,那麼這樣一本書才比較能夠不斷變動的技術中生存吧。

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...