資料來源：http://www.ithome.com.tw/itadm/article.php?c=48605
資料來源：http://www.ithome.com.tw/itadm/article.php?c=48605
| 其實不需要用到牛刀才能殺雞。技術方案的採用，你需要根據團隊本身的條件與專案需求，而非只看技術強弱。技術方案一旦選錯，後續發展將受限。 |
| 我們曾經談過程式設計員對於追求新技術的焦慮。許多程式人總是深陷在追求新技術的焦慮之中，唯恐自己所用的，不是最尖端的科技，沒有走在時代浪潮的最前頭。所以，總是努力地隨時做好技術升級的心理準備，只要用到的程式庫或應用程式框架一有風吹草動，就趕緊下載、更新，並且馬上嘗試應用。 除了對於新技術的焦慮之外，程式人在選用技術時，除了可能有極力追求「新」的心理趨向之外，其實，還有另一種趨向；極力追求「強」。 技術方案一旦選錯，後續發展將受限 當我們在準備啟動一個開發專案時，通常在選用技術方案的條件訂定上，先依據專案本身的背景、團隊成員的擅長的技術能力、以及專案的需求，以及限制條件（硬體、平臺、時間、資源等等）。 技術方案的選用這一環，許多人往往忽略。事實上，你所選用的技術方案，往往影響到整個專案進行的模式。而這項因素最後就會呈現在專案進行的時程、以及專案本身的品質。選擇一組合適的技術方案，可以讓時程順利進行，品質也能維持。但選擇不適合的技術方案，便有可能造成時程的延遲，也有可能造成所開發的軟體品質不佳。 舉例來說，有時候我們可以看到一些完全以JSP開發的網站系統，尤其愈早期的網站，愈常看到。這類的網站，直接在JSP中處理完所有的工作，包括直接用JDBC連接資料庫、沒有畫分出MVC三種角色，工作全部混雜在JSP之中……等等。可以想見︰當系統範圍超過某個門檻之後，這樣的開發方法，很容易引發許多問題，例如不容易除錯、難以提升資料庫存取的效率等。尤其是遇上了需求變更時，程式的修改成本，更會變得相對高昂。 從上述例子來看，所衍生出來的問題，乃是源自選擇了錯誤的技術方案。當這個專案決定採取全JSP的技術方案時，就構成了一個限制專案發展的圍牆，參與專案的人，無論再怎麼努力，都被限制在這個圍牆之中。 除非決定更動技術方案，否則一旦局限在一個不好的大框架下，即使參與的成員能力都很好，也會影響到他們的表現。因為採用容易造成程式撰寫錯誤的技術方案，程式人再怎麼優秀，還是容易出錯。一個天生效能不佳的技術方案，要徹底利用程式技巧及應用程式架構，改變它的效能表現，改善的空間同樣有限。 由此可見，技術方案的選用，對整個專案的影響十分深遠，它構成了開發時的既定大框架，任何的活動，都會受它而局限範圍。 採用太原始或過強的技術，都有很大弊病 依據我的觀察，許多團隊在選擇技術方案時，大致上有幾種模式。第一種模式，多半選用了很原始的技術方案。就好比，我們可以看到全用JSP手工「刻」出整個網站的專案。開發團隊對於技術不熟悉，只懂得入門的技術，或許參考著幾本書籍中的範例，就這麼開發起系統來了。雖然這麼做，不代表無法完成系統，但是，進階的技術之所以發展出來，總是有原因與能夠帶來的效益。例如，許多基於MVC的應用程式框架，就是希望能夠經由將資料模型、資料呈現方式、以及資料控制方式拆解開來，來降低三者之間的耦合程度，不論是開發人員的分工或程式的變更，都能藉此得到好處。假如選用「原始」的技術，就喪失了可能獲得的利益。 還有一種模式也很普遍，就是總是選用坊間認為最強大的技術。當EJB還是一門顯學的時候，有很多團隊想都不想地，在他們的每個專案中選擇使用EJB。這中間似乎沒有什麼思考的過程，他們只是因為EJB是被公認最強大的方案（況且，好像還很流行），使用這樣的技術方案，一來在客戶面前也不致於失去顏面，畢竟EJB是既進階且強大的一門技術呀！而且做這樣的選擇，也不會被客戶質疑。所以，當專案要選擇技術方案時，基本上，也是直接套用目前公認威力最強大的技術方案套餐。 好比現在，Hibernate + Struts + Spring的組合套餐，似乎就成了採用Java開發網站系統的主流選擇。可是，對於是否該選擇這樣的方案？是否能從這樣的方案中獲得好處？開發團隊很少真正思考這些事情。事實上，還是應該要回歸專案本身的背景、目的，以及諸般的資源限制來做判斷。 在制定技術方案選用的決策時，並不是一味朝著威力強大的方向去選。許多人常有的迷思，便是陷在其實要殺的是雞，卻選了一把牛刀的情境。 舉例來說，許多威力強大的程式庫或應用程式框架，在設計時必然考慮到較高層次的通用性，因為它們多半希望擴大適用的範圍，以便滿足各種不同需求的客戶端，協助程式人去因應。 注意須付出的代價 威力愈強大，通常意謂著彈性愈高，而這麼高的彈性，多半都伴隨著較高的複雜度。當專案所用的工具較為複雜時，你也得付出額外的成本及代價。 例如，專案成員可能不是人人都熟悉這樣的工具，複雜度高的工具有著較高的學習曲線，不熟悉的成員需要投入時間適應學習，在不熟悉的情況下使用，也更容易犯錯，付出更多的時間成本。又好比，愈複雜的工具，具備愈多的設定選項，因為它得要為開發客戶端系統的程式人，提供更多的操控可能性。這些選項不僅令人迷惑，而且不論設定透過外部設定檔（例如XML檔），或透過程式碼，因為選項多，設定起來成本多半也高昂。 越是威力強大的工具，越是能解決廣泛的問題。但是，當你所要解決的問題，其實並不那麼廣泛時，便值得仔細深思︰你究竟需不需要這麼強大的工具？ 相較而言，許多專案本身的需求及目標其實很單純，而且需求往往小於許多工具所能夠提供的功能。當你的系統只需要執行很簡單的SQL查詢動作時，運用Hibernate固然同樣可以解決你的問題，卻得引入許多無關於你真實需求的複雜性：也許完善，但必須面對更複雜的組態設定、和物件關聯對應有關的實作細目、更複雜的效能操控……。沒錯！有了這些，威力真的更強大。可是，你真的需要它們嗎？ 威力強大的工具，不僅需要更多額外的技巧，才能妥善加以駕馭，而且操控起來更費心力。正如當你在使用Struts時，不論需求究竟有多麼簡單，你設定的東西還是很多、很繁瑣。工具愈大，運用時需要付出的基本費用愈大。當你能從工具獲得的好處小於基本費用時，使用大型工具的整體效果，反而是負面的。現今許多對Struts之類的框架所做的反思，也都反映出這一點。 坊間有許多應用程式框架及程式庫，似乎都因為使用的程式人日益增加的關係，有著越來越強大的趨勢，但這也使得這些工具愈來愈重量化，往往逐漸不適用於小型的專案。我們通常不會採用最原始的方案，但此種重量級的工具，又同時顯得不甚稱手。我想，若能打造介於這二者之間的輕量化工具，必然能夠為許多小型或中型的開發專案帶來助益。 作者簡介： 王建興 清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。 |
資料來源：http://www.ithome.com.tw/itadm/article.php?c=48605
全站熱搜
留言列表
測試用 (1)
