JSP項目設計中的方法論

js|設計|項目 作者：運氣
email: webmaster@chinaspx.com

在設計JSP項目的時候，現行的方法學提供的更多是限制而不是協助。按照Casey Kochmer的觀點，成功的運行一個JSP項目的關鍵是專案管理而不是設計
。

與一般的想法相反，在運行一個項目的時候，最好的設計方法學並不是那種正式的方法。多數設計方法學都是臃腫而不切實際的。如果一種設計方法需要200頁的手冊才能說明，那隻能說明它在實際應用的時候顯得太複雜了。我認為，設計方法的本質應該是簡單和整體的。實際上，對於一個成功的設計方法，最關鍵的甚至可以說是與設計無關的東西，而是專案管理策略。如果管理不當，即使你有最好的設計也有可能失敗。在設計方法中，最重要的一點是必須提供一個簡單的架構，這個架構要能把任何成功設計中廣泛存在的對立和矛盾包容在一起。

在下面的指南中，我們將解釋這個問題，講述專案管理中最基本的組成原則。

專案管理原則

有幾個主要的因素可以導致項目失敗。我們在下面列出最主要的10個，還包含對每個因素的簡單解釋。
項目過於死板，不能按照使用者需要進行必要的改動。
項目毫無原則，經常因使用者的意願進行改變，因而無法在合理的時間內完成。
在編程人員和客戶之間缺乏溝通或者溝通很差。
有不切實際的預期目標。
時間表是不切實際的。
項目過大，無法進行成功的管理。
沒有測試或者測試過多。
使用錯誤的工具。
項目使用的技術對於項目和使用者來說太過先進，超前。
項目進行不尊重項目成員。
下面的多數原則就是為瞭解決這些問題而提出的。當然，每個項目都有其自身的平衡點。因此每個專案經理和主程式員都要按照自己項目的內部特色進行調整。

在項目的設計過程中，必須允許使用者提出改變設計的要求。但是同時一個項目又要有一定的“剛性”，要使設計的改變盡量少。平衡這個矛盾需要非常好的設計藝術，而且每個項目的平衡點都是不一樣的。
在項目進行過程中，團隊需要直接與客戶溝通，至少也要保證最低限度的項目回顧和問題澄清/分析過程。
一個項目的時間不要超過一年，以6到9個月為最佳。任何更大更長的項目最好切割為小的子項目。
專案經理與程式設計主管一定要是不同的兩個人。將者兩個角色合一使一個人的負擔過大，兩個角色都作不好。
一個項目的人數不要超過7個，以5個為最佳。
一個項目小組最好能混合資深的和年輕的開發人員
我發現，如果一個開發小組全是資深的開發人員，那麼小組很容易陷入陳腐和習慣化的情況。而一個完全又年輕的開發人員組成的隊伍又明顯的缺乏經驗。團隊中的年輕成員可以消除老的資深人員的惰性，年輕的新手可能經常會問，這個為什麼要這樣作？這種問題經常帶來良好的改進。同時，資深的開發人員可以訓練新手，讓他們經常對設計進行檢查，這也可以帶來改進。 7.項目所使用的工具對項目成員來說必須是容易使用和控制的，或者在這方面能夠提供協助的人必須是容易找到的。
開始的時候就要制定比較現實的時間表。如果時間表在開始後發現是不合理的，就要儘快對人員或者是時間表進行調整。多數項目的錯誤在於一味的增加資源以加速進度。這通常都是錯誤的。如果發現一個時間表是不合理的，其錯誤之處多數不僅僅是缺乏資源。在檢查時間表的同時也要檢查一下項目目標，方法和選擇。確保你在可靠的前提和資訊下工作。在完成這種重新審查後，按照自己的想法重新調整項目。
項目中的主要參與者必須感覺舒適，可以自由的提問，自由的進行溝通。缺乏有效溝通的項目通常會迅速失敗。出現問題的第一個訊號通常就是在交換資訊的時候有問題。沉默並不是項目要完成的訊號，而是說明你的成員在無法溝通的真空中工作。
項目小組中的所有成員都要明白這些原則，以便經常對項目情況進行檢查。如果一個項目不符合這些原則，那麼所有的成員都有義務儘快找出問題之所在。我在項目中也經常弄錯點什麼，但是也盡量將這些錯誤迅速找出。當問題在爆發前被發現，或者是在項目的初始階段被發現，通常解決問題的方法也簡單。但是，忽略這些問題則經常導致更嚴重的問題，導致項目失敗。如果有項目不能體現這些原則，我是不會接受這種項目的。
這些原則是我為項目成功總結的一些基本點。我個人的經驗告訴我忽視上面任何一個原則都很可能導致嚴重的結果。

設計原則

雖然在設計上設定過多剛性的原則是有害的，但是這裡我們還是提出一些可以遵循的基本原則。

避免成為使用新技術的群體。一定要等到技術和產品的支援資訊成熟了再考慮。但是如何判斷一個技術是否足夠成熟呢？看看在Internet上的支援資訊的豐富程度和深度。一個新的工具，只有在你可以很容易地找到其協助資訊的時候才是好的。
如果你不得不使用比較新的技術，記住一定要準備有後備的方案，以便在新技術實施中出現問題的時候使用。我的感覺是新技術在你項目的關鍵點上有大概50%的機會會出問題。從一開始就準備好後備的方案可以避免日後問題擴大。在使用新技術的時候，一定要在項目的早期使用，以爭取更多的時間對其可行性進行評估。
保證使用者的技術水平可以使用你的項目中的各種技術，例如如果使用者使用的是3.x版本的瀏覽器，你就不要採用用戶端的XML/XSL。當然，你還是可以使用伺服器端的XML/XSL，因為使用者不會因此受到影響。
以滿足最小限度的需求為目的，這樣做可以防止項目變的臃腫，同時可以加快程式編寫速度，也更容易測試。而使用者只應該要求他們真正需要的功能。
在編碼的時候，最主要的目標是製作可維護的代碼；第二個目標是製作可重用的代碼。藉助Java，物件導向是我們達到成功的最重要工具。但是也不要完全依賴物件導向技術，藉助最簡單的模板，函數庫或者是良好設計方法也可以很好地對代碼進行重用。物件導向只是我們在編程的時候可以選擇眾多技巧中的一種。
測試和試用是成功的重要部分。試用是非常重要的部分，一定要給以充足的時間以便有機會對發現的錯誤進行修正。
在主要項目完成後，可以給出一個小的第二階段，在這個階段中可以將項目中不夠完善，沒有完全達到預期水準的部分進行修改。
想想多重項目的概念。一個項目小組經常要面對多重專案。項目人員在不同的項目中，要不斷的變換職責，一方面這樣的作為為以後的人員使用增加了後備。而且由於每個項目小組成員都不斷作新的事情，也減少了人員產生倦怠情緒的可能(這意味著你的項目小組可以長時間保持相對穩定)
預先作好計劃，使多個人可能不斷對一段代碼進行加工。為了作到這一點，我在不同的項目之間進行代碼重用。其實，我們做的不僅僅是代碼重用。在每個項目中，都可能有個新的人在使用現有的一部分代碼。新的人可能會不斷的對這些代碼進行修正和最佳化。因此這些代碼可以不斷的增加效率，同時出現問題的機會也很少。代碼的效率可以得到提高，另外文檔也可以不斷完善。不僅僅是代碼本身可以不斷被修改，提高，隨著新技術的出現，代碼也可以不斷應用新的技術，從而得到提高。
如果可能，盡量使用公開源碼
將JSP的分布式環境變成你的優勢。使用用戶端指令碼來利用客戶機的能力。真正依靠資料庫的儲存進程，將資料處理邏輯集中儲存。使用J2EE伺服器產生XML和XSL資料範本來產生HTML輸出。避免將處理集中在一點，將處理工作分布開來是完成工作最有效方式。
避免把太多的邏輯放到一個單一的JSP頁中。一個JSP頁作的事情越多，當你需要升級或者是修改項目的時候，影響就越大。盡量使每個JSP頁只完成一個最基本的小操作。也可以使用Tag和JavaBean庫的優勢來建立可重用的模組。這些手段有助於使JSP頁便於維護。