J2EE項目10大風險
來源:互聯網
上載者:User
在過去這段時期裡,我擔任過程式員、進階設計師以及架構設計師等工作,見識過很優秀的企業級Java項目,也見識過不好的,甚至很"醜陋"的項目。有時候我會自己問自己,為什麼一個項目可以取得成功,而另一個卻走向失敗?很難定義出某種規則或標準來表明各個不同的項目應該如何成功,J2EE項目也並不例外。但與此相反的是,我們可以從各個角度和層次上去考察項目失敗的原因,如果很好地避開了這些風險,項目就可以取得成功。在本文中,我將提出排名前10位的企業級Java項目風險,供讀者參考。
在各種各樣的風險中,有些風險只是延緩了項目的進度,有些帶來了一些不必要的工作,而另一些則會把成功的可能性徹底地消除。不過,如果預先有了足夠的準備和清醒的認識,那麼並沒有不可避免的事情。這好比如果你是一名旅行者,你清楚地知道前面的道路在什麼方向,做了充分的準備,又有一位清楚知道哪裡有危險的嚮導,這樣就會比較順利地到達自己的目的地。
本文採用了以下結構來描述風險:
風險名稱:風險的標題(使用粗體)
項目階段:在哪個項目階段會發生風險情況
影響階段:會影響到以後的哪些階段
癥狀: 風險產生時的癥狀
規避方案:如何規避風險或者把其對項目的影響降低到最小程度
備忘: 風險相關的補充說明和提示
通過對企業級Java項目的仔細考察,本文將J2EE項目過程分解為以下幾個階段:
供應商選擇: 在開始你的J2EE項目之前,要選擇最合適的供應商,從應用伺服器到開發工具組合,一直至工作期間享用的咖啡的廠商。
設計: 在遵照一系列嚴格的規範和軟體工程方法的前提下,可以開始進行足夠充分的設計,然後再很自然地進入開發階段。在開發之前,要周全地考慮好正在做什麼,以及如何往下做的問題。另外,我使用了一些設計範本來確信在進入開發之前,已經想到了所有的問題和可能的解決方案。但是,我有時也在該階段做一些編碼,有時候這樣做可以回答一些問題,有效地判斷出效能上和模組劃分上的問題。
開發: 也就是程式開發階段,選擇一些好的開發工具,進行精良的設計等等,在這個階段將顯示其優越性,並且可以給開發帶來很大的協助。
穩定性/負載測試:在該階段,系統架構師和專案經理應該凍結住產品特性,並把焦點放在品質以及產品參數(允許的並發使用者數量,故障恢複情況,等等)上。品質和效能在該階段應得到足夠的重視。當然,最好應該避免在前階段寫出不良的運行緩慢的代碼而到本階段來作很多的修改。