邁向架構師的暖身運動 (9):了解並善用工具,但不要盡信工具

最近發生兩個很有趣的案例,可以發現即便是原廠或作者宣稱很好用的工具,也可能會暗藏危機,尤其是對工具 (也可以套用在某些 Framework 或是元件,程式碼模組上) 的原理或架構不夠了解時,那可能被內含的一些機制或限制暗算的機率會變得很高。

最近發生兩個很有趣的案例,可以發現即便是原廠或作者宣稱很好用的工具,也可能會暗藏危機,尤其是對工具 (也可以套用在某些 Framework 或是元件,程式碼模組上) 的原理或架構不夠了解時,那可能被內含的一些機制或限制暗算的機率會變得很高。

第一個案例,是在 MSDN 論壇上的一個提問:PageMethods 與 XMLHttpRequest

ASP.NET AJAX 所附屬的許多 AJAX Framework 和控制項如 UpdatePanel, PageMethods 等功能都是可以有效縮短 ASP.NET Programmer 開發 Web 應用程式的好物,但是當你在用 UpdatePanel 時,你知道它在背後做了什麼事嗎?一個看起來很好用的東西,一定是想了一些方法來技術性規避或包裝原有必須要做的事情,才能達到應有的好用功能。但這不代表原有必須要做的事可以不用做,以 UpdatePanel 來說,AJAX Framework 把一個需要片段更新的功能包裝到控制項內,雖然表面上可以做到真的片段更新的功能,但它卻只是把原本頁面更新的機制包裝到 AJAX Framework 內,並沒有將這個步驟省略掉 (只是 AJAX Framework 把這工作吃掉),因此 ASP.NET 核心用來保存頁面資料的一些狀態資訊,像是 ViewState,都會原封不動的被傳回到 server,再由 ASP.NET 核心進行頁面處理後,才切割這個控制項包裹的使用者介面部份回傳給用戶端,這一大段之間要花多少動作?因此用 UpdatePanel 的 ASP.NET AJAX 應用程式通常效能都會差一點 (時間大多都花在 ASP.NET 核心處理頁面的工作)。

同理,ASP.NET AJAX Framework 提供的 PageMethods 也有相同的問題,PageMethods 可以讓頁面中的方法直接顯露給 Client-side Scripting 取用,有如 Web Service 一般,但為了要讓 PageMethods 發生作用,AJAX Documentation 內說明要開發人員將要作為 Page Method 的方法使用 static 來宣告,我們用公開的秘密:Reflector 來看 System.Web.Extensions.dll 組件 (或者也可以由微軟下載 .NET Framework 的 Reference Source Code 來看),裡面有一個 System.Web.Script.Services 命名空間,在這個命名空間內有一個 RestHandler 的 HTTP Handler,內含了一個 InvokeMethod() 方法,這個方法會偵測靜態的方法,並呼叫這個方法,再回傳它的回傳值。由此可知,PageMethods 會將 ASP.NET 的靜態頁面包裝成類 Web Service 的方式,直接由 XMLHttpRequest 呼叫 .aspx,而內含的 RestHandler 會處理這個呼叫。當然,為了要讓 ASP.NET 將資料導向到 RestHandler,在用戶端指令中也有一些該做的事。這個部份可以參考 http://www.dotblogs.com.tw/ian/archive/2010/09/09/17627.aspx 的說明。

第二個案例,是在 Facebook 上和 Ruddy 老師討論使用 SharePoint 作為開發平台時,PM 或 SA 的指南的問題,討論串可以在這裡看:http://www.facebook.com/#!/jimycao?v=wall&story_fbid=437487537229&ref=notif&notif_t=feed_comment_reply

SharePoint 最早是由 Content Management Server (CMS) 演化而來,作為企業內部入口網站的建置之用,其實它的問題和 SQL Server 有點像,同一個技術會區分為 for IT PRO 和 for Developer,IT PRO 和 Developer 看同一個技術或產品的角度一定不同,IT PRO 重視的是部署的方式,日後的組態,維運以及故障排除 (以架構師來說,算是 Infrastructure Architect);而 Developer 重視的是技術提供的開發功能,擴充能力以及開發方法,如同 Windows Azure 提供的 API/Service 與工具等,但 SharePoint 混合了多種微軟技術,以符合在企業環境中建置的需求,之前微軟將 SharePoint Server 用  "SharePoint Technologies" 來稱呼,可不是浪得虛名的。然而,就是因為 SharePoint 的技術混合性很高,因此想要發揮 SharePoint 的能力也很困難,想要駕馭 SharePoint 進行開發的話,要會的東西可能至少有 Active Directory, SQL Server, HTML, Visual Studio, List Collection, Business Data Connector / Business Connectivity Services, Web Parts, …,如此多的東西,想要在短時間內了解其實難度不低。

同樣的問題也發生在許多的 Framework 上,以 jQuery 來舉例,jQuery 也是一個 Framework,它內部也隱含了很多自動處理掉的東西,最典型的就是 selector,在現行瀏覽器處於戰國時代的時期,jQuery 為了要保持一致的 Coding style,它一定要在所有的瀏覽器 (至少在主流的瀏覽器上) 提供相同的作法,才會吸引多數的 Developer 來使用,所以在 jQuery source code 中會看到到處都是 Regular Expression,以將解析器的能力在所有的瀏覽器中都有作用,使用它的開發人員才可以用極簡的 $("div.myClass") 來取出 class="myClass" 的 div 元素,但像 #myID 這種 selector 就要少用,而改用 $(document.getElementById("myID")) 來取代,用瀏覽器原生的方法,會比 jQuery 來的快。其他像是 Spring Framework,MEF (Managed Extensibility Framework) 或是 Code Contract 等,都會有相同的問題。

現在為了要減輕開發人員的負擔,很多的 Application Framework / Functional Framework 在網路上都找的到,很多的工具 (Visual Studio 也是) 也將許多原本應該做的東西精巧的包裝成很簡單的控制項或元件,讓開發人員可以在數分鐘內將功能做出來,生產力是進步了沒錯,但生產力的背後要拿什麼來換?最明顯的就是效能降低或是可維護性變差,可讀性變差或無法找到適合的人來維護 Framework 等等副作用。我不是說使用工具和 Framework 不好,善用這些工具和 Framework 確實可以增加生產力,但如果都盡信工具的話,可能會在無形中挖洞給自己跳,不可不慎。

能善用工具和 Framework 的唯一路徑,就是徹底了解它,以及它背後的基礎知識。這條路雖然不好走,但一定要走過去,否則亂用 Framework 寫出來的程式,不但可能會不倫不類,甚至寫出來的到最後都要整個丟棄 (我就被暗算過,有切身之痛 … )。所以不能把這件事當兒戲啊。