假如你是一名Java開發者,正在開發和維護包含2000個類並使用了很多框架的應用程序。你要如何理解這些代碼呢?在典型的Java企業項目小組中,大部分能夠幫你的高級工程師看起來都很忙,文檔也很少。你需要盡快交付成果,並向項目組證明自己的能力。你會如何處理這種狀況呢?這篇文章為開始開發新項目的Java開發者提供了一些建議。
1. 不要試圖一下子搞懂整個項目
仔細考慮一下,為什麼你會想要先理解項目代碼呢?大部分情況是有人要求你修復一個bug,或者增強系統已有功能。你要做的第一件事情不是理解整個項目的架構。當對項目進行維護時,這樣做(理解整個項目架構)可能會對你造成巨大的壓力。
即便是有10年編程經驗的Java開發者,也無法理解項目的核心工作機制,盡管他們可能已經在這個項目工作超過一年(假設他們並非最初的開發人員)。比如,對於認證機制或事務管理機制還是缺乏確切的認識。
他們是怎麼做的呢?他們對於自己負責的部分非常了解,並且能夠交付價值給小組。每天的交付價值遠比了解一些以後還不確定有沒有的東西重要的多。
2. 關注於盡快交付價值
那我是要打消你對於理解項目架構的熱情嗎?完全不是。我只是要求你盡早地交付價值,一旦你開始一個項目,搭建了開發環境,你就不應該花一兩周時間才交付內容,無論它的規模大小如何。假如你是一位有經驗的程序員,卻兩周都沒有任何交付,你的經理怎麼會知道你是真的在工作,還是在看新聞呢?。
所以交付能夠將事情變得簡單。不要認為在做有價值的交付前,你必須理解整個項目。這是完全錯誤的。加一段Javascript的驗證代碼對業務就很有價值,經理能夠通過你的交付對你更加信任。這樣能夠向上級領導證明你的貢獻以及員工價值。
日復一日,在不斷修復bug及增強功能之後,你就能夠慢慢開始理解項目架構。不要低估對系統方方面面理解時需要花費的時間。花3到4天理解認證機制,2到3天理解事務管理。這些都是依靠之前的相似項目的經歷,但關鍵還是要花時間才能透徹的理解。要在日常工作中擠出時間,不要向經理要求特定的時間來做這些。
找找項目是否有一些有效維護的單元測試用例。有效的單元測試用例是理解大型項目代碼很好的途徑。單元測試能夠幫助你理解代碼片段,包括一個單元的外部接口(單元如何被調用以及返回內容)及其內部實現(調試單元測試比調試整個實際用例簡單許多)。
你如果能夠很好的理解一些內容,那麼就寫些筆記,或者畫些類圖、時序圖、數據模型圖等,以便你或日後其他的開發者可以進行維護。
3. 維護大型項目所必須的技能
你能從事當前的工作,必然已經具有良好的Java技術。我們來談談能夠讓你在新項目中良好表現的其他技能。大部分時間裡,你在項目中的任務是修復bug和增強功能。
有兩項很重要的技能能夠在你維護大型項目代碼起到幫助。
3. 1 能夠迅速發現需要的類
在任何維護活動中,無論是修復bug或增強功能,第一件事情就是識別出當前修復或增強的用例中調用的類。當你定位到需要修復或增強的類/方法,就已經完工了一半。
3. 2 能夠分析變更的影響
當你在完成必要的修改或增強工作後,最重要的就是要確認你的修改沒有破壞代碼的其他部分。你要用你的Java技術及對其他框架的理解找出變更可能影響的部分。下面兩個簡單的例子詳細描述了最後提及的情況:
因此,既要深入了解Java語言,又要深入了解你在應用中使用的框架,這樣才能分析出一個改變的影響。
當你提高了如上兩個技能,盡管你對項目不是非常了解,但大部分的維護任務會變得簡單很多。如果你想要修復一個bug,就會定位並修復這個bug,並且保證變更不會破壞項目的其他部分。如果你想要增強或加入特性,基本上你只需要模仿現有的特性,使用類似的設計。
在一個在線銀行項目中,為什麼“查看賬戶摘要”和“查看交易歷史”的設計要有巨大的差別呢?如果你理解了“查看賬戶摘要”的設計,完全可以模仿開發出“查看交易歷史”的功能。
就修復bug和增強來說,你不必完全理解所有2000個類的工作內容和代碼驅動系統運行的原理。只要有上面的技能,你就能很快定位需要修改的代碼,使用良好的Java和框架技能修復,保證變更不會破壞項目的其他部分,然後交付,盡管你可能只知道一小部分項目的設計。
4. 使用工具找到所需變更內容以及變更產生的影響
繼續我們盡快交付的主題,你應該尋找工具作為輔助,只需要對項目又很少理解,就能幫助你盡快實施交付。
4. 1 迅速發現所需變更內容的工具
無論是修復bug還是增強系統,首先你都要找到該用例調用且需要修改的類及方法。基本上有兩種方式理解用例的工作方式,靜態代碼分析和運行時分析。
源碼分析統計會掃描所有代碼並且展現類之間的關系。市場上有很多工具。比如:Architexa、AgileJ、UModel、Poseidon等。
所有靜態代碼分析工具的缺點在於,它們無法確切展現用例中類或方法的運行時調用情況。因此Java新加入了一些特性,如回調機制(callback patterns)。比方說,靜態分析工具無法推斷出當前頁面提交按鈕被點擊時,會調用哪個Servlet。
運行時分析工具能夠展現類和方法在用例運行時的狀態。這樣的工具包括:MaintainJ、Diver、jSonde、Java Call Tracer等。這些工具可以捕獲運行時的堆棧狀態,並以此為用例生成序列圖和類圖。
序列圖會展現該用例在運行時所有調用的方法。如果你在修復bug,那麼這個bug很可能就是這些被調用的方法之一。
如果你在增強已有功能,可能是新增驗證,修改DAO等,那麼就可以利用序列圖理解調用流程然後再修改。
如果你在新增功能,那麼就可以找到一些相似的特性,利用序列圖理解調用流程,然後模仿開發新功能。
要仔細地挑選運行時分析工具。信息過多是這類工具的主要問題。選擇一些工具,能夠提供簡單的信息,過濾掉無效信息,並能夠方便的查看各種視圖。
4. 2 迅速發現所需變更內容的工具
若單元測試有效,你就可以通過運行單元測試發現變更有沒有破壞其他測試用例。有效維護並且覆蓋大型企業應用的單元測試還是比較少的。下面有一些針對該情況的工具。
在此,仍然是有兩種技術——靜態代碼分析和運行時分析——可以使用。市場中有很多靜態代碼分析工具可用。如:Lattix、Structure101、Coverity、nWire和IntelliJ's DSM。
對於變更後的類,上述工具均可識別對該類存在依賴的類的集合。開發者需要根據這些信息“猜測”可能產生影響的用例,因為這些工具無法展示運行時類之間的調用關系。
市場上可以用於運行時影響分析的工具並不多,可能只有MaintainJ。MaintainJ先會捕獲在用例中調用的所有類和方法。當所有用例的上述信息都被捕獲之後,就很容易發現類的變更對用例的影響。MaintainJ能夠有效工作的前提條件就是項目的所有用例都應當先運行一遍,以便能夠獲得運行時的依賴關系。
總之,目前你在迅速准確分析變更影響方面,還是可以從工具中獲得有限的幫助。首先根據需要實施一些影響分析,然後根據自己或小組其他高級成員評審來判斷變更的影響。你可能需要使用上述工具對你的判斷進行反復確認。
5. 對上述內容的兩個忠告
5. 1 不要降低代碼質量
為了快速交付,可以不全盤理解架構,但絕不能以降低代碼質量為條件。下面是一些你可能因為只考慮快速交付而引發的代碼質量問題。
因為修改代碼涉及到很多的依賴關系,所以新增代碼相對而言風險較小。例如,有五個用例都調用了某個方法。為了改進某個用例,你需要修改這個方法的實現。最簡單的做法就是復制這個方法,重命名,然後在改進的用例中調用新方法。千萬不要這麼做。代碼冗余絕對是非常有害的。你要嘗試對方法進行包裝或者重寫,甚至是直接修改,然後重新測試所有用例,通常停下來想一想,然後親手去實施,是一種不錯的方式。
另一個例子是將“private”方法改為“public”,讓別的類也可以調用。盡量不要將非必須的部分暴露出來。假如是為了更好的設計而需要重構,那麼就應當著手去做。
大部分應用都有確定的結構和模式來實施。修復或增強程序時,你要確保不會偏離這樣的模式。如果對規約不確定,那麼就請其他高級開發者來審核你的變更。如果你必須做一些違背規約的動作,那麼就盡量放置於規模較小的類中(一個200行代碼的類中的私有函數應當不會影響應用的整體設計)
5. 2 不要停止深入理解項目架構
按照文章列出的方式,假設你能夠在對項目了解較少的情況下進行交付,並持續這樣下去,可能就會停止對項目架構的深入了解。這從長遠角度來說對你的職業生涯沒有幫助。當你的經驗增加時,就會承擔比較大的模塊任務。如構建一個完整的新特性,或者修改項目的一些基礎設計等較大的改進。當能夠做這些改進時,你對項目的整體架構應該相當了解。文中列舉的方法只是讓你在最短的時間內提升自己,而不是阻止你完整理解整個項目。
6. 結論
整篇文章的重點在於,對項目進行必要了解,然後進行快速交付。你可以在不降低代碼質量的前提下做到這一點。
如果要修復bug,那麼迅速定位並修復。可以在必要的時候使用運行時分析工具。如果要新增特性,那麼就可以尋找類似特性,理解流程(在必要的時候使用工具)並編寫。
或許這些聽起來很簡單,但是實用嗎?當然。前提是你有良好的Java技術,以及對框架足夠了解,然後才能先修改代碼,再分析變更所產生的影響。分析變更所產生的影響比實施變需要更多技巧。你可能需要高級開發人員協助你分析變更影響。
大約有50%的IT可操作預算用於簡單的bug修復和功能增強。文中的建議對於在維護活動中節省經費應當還是很有幫助的。