Why we need an architect?

最近微軟發佈了很多的新技術架構，很多朋友紛紛的問我相關的問題；加上自己最近看到的一些事，與跟百敬閒聊，讓我有了一些想法。

很多人喜歡將軟體工程與建築相比擬，事實上，兩者之間有許多相似之處。建構一個系統，其實就跟蓋房子很類似。一般鄉下人家，使用磚頭就可以堆出平房來，但是你沒辦法用磚頭堆出樓房出來，因此蓋樓房我們需要使用鋼筋混凝土的結構。但若是要建立的是摩天大樓的話，用一般鋼筋混凝土的技術會需要消耗太多的時間，因此你會採用鋼骨加上預鑄的工法，才可以快速建立摩天大樓。但你不會使用鋼骨去建平房--成本太高，而且蓋起來的房子應該也很奇怪。

軟體工程也是一樣。在建立系統的時候，你有許多的技術與架構可以去選擇，但若是你選擇了錯誤的架構，就好像用磚頭去蓋摩天樓，或是用鋼骨結構去蓋平房一樣--最後不是樓塌了，就是30萬的房子用300萬蓋了一個四不像的東西出來，結果都是不能用。

前一陣子朋友的公司要建置一個內部使用的系統，因為發生了一些問題所以請我幫忙看一下。我稍微看了一下，一個2、30人用的內部系統，使用ASP.NET加上AJAX的技術開發，並且將資料存取的動作都使用ADO.NET技術製作成資料物件，然後使用在網頁當中--看起來好像是相當合理的做法。

但是仔細一看，問題紛紛產生：

1. 每個網頁中都有自己的資料存取物件，但是因為邏輯都不同，無法重複使用。

    建立資料存取物件的用途，主要應該是著眼於可維護性以及可重複使用性。以這個系統來說，在不需要重覆使用的前提之下，若是要使用程式碼建立資料的存取邏輯，直接寫在網頁的程式中一定會比較容易維護；而使用TableAdapter建立資料存取物件又會比使用程式碼容易維護。

2. 20多人使用的內部系統，使用ASP.NET技術開發。

    另外一個程式設計師容易陷入的迷思，就是"Web Application容易部署與維護"，因此甚麼阿里不達的系統，全都要做成Web Application。在大部分的情況之下，若是你的使用者散居各地，無法有效控管，而且必須要透過網際網路存取公司的資源時，我必須要承認這觀念是正確的。但是Web Application畢竟是屬於集中於Server端執行程式的架構，因此把所有的程式都使用ASP.NET設計之後，再加上Session技術的濫用，造成的結果就是一堆效能很差、不穩定、再加上不容易控管的系統。

    你以為使用AJAX或是Flash、Silverlight這些前端技術會分散Loading嗎? 如果你Server端程式執行就慢，前端的這些技術也分散不了太多的Loading，只會讓你的程式執行更複雜，更不容易除錯，甚至於發生更多莫名其妙、無法解決的錯誤。在加上不穩定的Browser，這樣上線的話，我看MIS的年終獎金應該是拿不到了。

    既然是"內部系統"，因為User端的環境是在掌控之中，其實大部分的系統可以考慮使用Windows Form或是WPF 的技術開發，再透過Click Once更新就可以了。若是有可以共用的邏輯，再考慮製作成單獨的WCF服務，這樣可以縮短開發時間，架構上又兼具有延展性。

這只是一個小個案，看得出來我們有很多蓋房子的師父，但很多企業中卻沒有很好的系統架構規劃，所以常常會做出一些匪夷所思的東西出來。但是有了架構師也並不能解決一切，因為還有很多技術以外的因素(預算、政治.....)，對系統的開發過程影響更嚴重。但是至少有了一個正確的架構之後，將來就算發生了一些五四三的事，那頂多就像房子蓋到一半建商跑掉，換個建商還是可以繼續完成--也不至於等到房子蓋好才發現不能住人........