假如你是一名Java開(kāi)發(fā)者，正在開(kāi)發(fā)和維護包含2000個(gè)類(lèi)并使用了很多框架的應用程序。你要如何理解這些代碼呢？在典型的Java企業(yè)項目小組中，大部分能夠幫你的高級工程師看起來(lái)都很忙，文檔也很少。你需要盡快交付成果，并向項目組證明自己的能力。你會(huì )如何處理這種狀況呢？這篇文章為開(kāi)始開(kāi)發(fā)新項目的Java開(kāi)發(fā)者提供了一些建議。
仔細考慮一下，為什么你會(huì )想要先理解項目代碼呢？大部分情況是有人要求你修復一個(gè)bug，或者增強系統已有功能。你要做的第一件事情不是理解整個(gè)項目的架構。當對項目進(jìn)行維護時(shí)，這樣做（理解整個(gè)項目架構）可能會(huì )對你造成巨大的壓力。
即便是有10年編程經(jīng)驗的Java開(kāi)發(fā)者，也無(wú)法理解項目的核心工作機制，盡管他們可能已經(jīng)在這個(gè)項目工作超過(guò)一年（假設他們并非最初的開(kāi)發(fā)人員）。比如，對于認證機制或事務(wù)管理機制還是缺乏確切的認識。
他們是怎么做的呢？他們對于自己負責的部分非常了解，并且能夠交付價(jià)值給小組。每天的交付價(jià)值遠比了解一些以后還不確定有沒(méi)有的東西重要的多。
那我是要打消你對于理解項目架構的熱情嗎？完全不是。我只是要求你盡早地交付價(jià)值，一旦你開(kāi)始一個(gè)項目，搭建了開(kāi)發(fā)環(huán)境，你就不應該花一兩周時(shí)間才交付內容，無(wú)論它的規模大小如何。假如你是一位有經(jīng)驗的程序員，卻兩周都沒(méi)有任何交付，你的經(jīng)理怎么會(huì )知道你是真的在工作，還是在看新聞呢？。
所以交付能夠將事情變得簡(jiǎn)單。不要認為在做有價(jià)值的交付前，你必須理解整個(gè)項目。這是完全錯誤的。加一段javascript的驗證代碼對業(yè)務(wù)就很有價(jià)值，經(jīng)理能夠通過(guò)你的交付對你更加信任。這樣能夠向上級領(lǐng)導證明你的貢獻以及員工價(jià)值。
日復一日，在不斷修復bug及增強功能之后，你就能夠慢慢開(kāi)始理解項目架構。不要低估對系統方方面面理解時(shí)需要花費的時(shí)間?；?到4天理解認證機制，2到3天理解事務(wù)管理。這些都是依靠之前的相似項目的經(jīng)歷，但關(guān)鍵還是要花時(shí)間才能透徹的理解。要在日常工作中擠出時(shí)間，不要向經(jīng)理要求特定的時(shí)間來(lái)做這些。
找找項目是否有一些有效維護的單元測試用例。有效的單元測試用例是理解大型項目代碼很好的途徑。單元測試能夠幫助你理解代碼片段，包括一個(gè)單元的外部接口（單元如何被調用以及返回內容）及其內部實(shí)現（調試單元測試比調試整個(gè)實(shí)際用例簡(jiǎn)單許多）。
你如果能夠很好的理解一些內容，那么就寫(xiě)些筆記，或者畫(huà)些類(lèi)圖、時(shí)序圖、數據模型圖等，以便你或日后其他的開(kāi)發(fā)者可以進(jìn)行維護。
你能從事當前的工作，必然已經(jīng)具有良好的java技術(shù)。我們來(lái)談?wù)勀軌蜃屇阍谛马椖恐辛己帽憩F的其他技能。大部分時(shí)間里，你在項目中的任務(wù)是修復bug和增強功能。
有兩項很重要的技能能夠在你維護大型項目代碼起到幫助。
在任何維護活動(dòng)中，無(wú)論是修復bug或增強功能，第一件事情就是識別出當前修復或增強的用例中調用的類(lèi)。當你定位到需要修復或增強的類(lèi)/方法，就已經(jīng)完工了一半。
當你在完成必要的修改或增強工作后，最重要的就是要確認你的修改沒(méi)有破壞代碼的其他部分。你要用你的java技術(shù)及對其他框架的理解找出變更可能影響的部分。下面兩個(gè)簡(jiǎn)單的例子詳細描述了最后提及的情況：
因此，既要深入了解Java語(yǔ)言，又要深入了解你在應用中使用的框架，這樣才能分析出一個(gè)改變的影響。
當你提高了如上兩個(gè)技能，盡管你對項目不是非常了解，但大部分的維護任務(wù)會(huì )變得簡(jiǎn)單很多。如果你想要修復一個(gè)bug，就會(huì )定位并修復這個(gè)bug，并且保證變更不會(huì )破壞項目的其他部分。如果你想要增強或加入特性，基本上你只需要模仿現有的特性，使用類(lèi)似的設計。
在一個(gè)在線(xiàn)銀行項目中，為什么“查看賬戶(hù)摘要”和“查看交易歷史”的設計要有巨大的差別呢？如果你理解了“查看賬戶(hù)摘要”的設計，完全可以模仿開(kāi)發(fā)出“查看交易歷史”的功能。
就修復bug和增強來(lái)說(shuō)，你不必完全理解所有2000個(gè)類(lèi)的工作內容和代碼驅動(dòng)系統運行的原理。只要有上面的技能，你就能很快定位需要修改的代碼，使用良好的java和框架技能修復，保證變更不會(huì )破壞項目的其他部分，然后交付，盡管你可能只知道一小部分項目的設計。
繼續我們盡快交付的主題，你應該尋找工具作為輔助，只需要對項目又很少理解，就能幫助你盡快實(shí)施交付。
無(wú)論是修復bug還是增強系統，首先你都要找到該用例調用且需要修改的類(lèi)及方法?；旧嫌袃煞N方式理解用例的工作方式，靜態(tài)代碼分析和運行時(shí)分析。
源碼分析統計會(huì )掃描所有代碼并且展現類(lèi)之間的關(guān)系。市場(chǎng)上有很多工具。比如：Architexa、AgileJ、UModel、Poseidon等。
所有靜態(tài)代碼分析工具的缺點(diǎn)在于，它們無(wú)法確切展現 用例中類(lèi)或方法的運行時(shí)調用情況。因此Java新加入了一些特性，如回調機制（callback patterns）。比方說(shuō)，靜態(tài)分析工具無(wú)法推斷出當前頁(yè)面提交按鈕被點(diǎn)擊時(shí)，會(huì )調用哪個(gè)Servlet。
運行時(shí)分析工具能夠展現類(lèi)和方法在用例運行時(shí)的狀態(tài)。這樣的工具包括：MaintainJ、Diver、jSonde、Java Call Tracer等。這些工具可以捕獲運行時(shí)的堆棧狀態(tài)，并以此為用例生成序列圖和類(lèi)圖。
序列圖會(huì )展現該用例在運行時(shí)所有調用的方法。如果你在修復bug，那么這個(gè)bug很可能就是這些被調用的方法之一。
如果你在增強已有功能，可能是新增驗證，修改DAO等，那么就可以利用序列圖理解調用流程然后再修改。
如果你在新增功能，那么就可以找到一些相似的特性，利用序列圖理解調用流程，然后模仿開(kāi)發(fā)新功能。
要仔細地挑選運行時(shí)分析工具。信息過(guò)多是這類(lèi)工具的主要問(wèn)題。選擇一些工具，能夠提供簡(jiǎn)單的信息，過(guò)濾掉無(wú)效信息，并能夠方便的查看各種視圖。
若單元測試有效，你就可以通過(guò)運行單元測試發(fā)現變更有沒(méi)有破壞其他測試用例。有效維護并且覆蓋大型企業(yè)應用的單元測試還是比較少的。下面有一些針對該情況的工具。
在此，仍然是有兩種技術(shù)——靜態(tài)代碼分析和運行時(shí)分析——可以使用。市場(chǎng)中有很多靜態(tài)代碼分析工具可用。如：Lattix、Structure101、Coverity、nWire和IntelliJ's DSM。
對于變更后的類(lèi)，上述工具均可識別對該類(lèi)存在依賴(lài)的類(lèi)的集合。開(kāi)發(fā)者需要根據這些信息“猜測”可能產(chǎn)生影響的用例，因為這些工具無(wú)法展示運行時(shí)類(lèi)之間的調用關(guān)系。
市場(chǎng)上可以用于運行時(shí)影響分析的工具并不多，可能只有MaintainJ。MaintainJ先會(huì )捕獲在用例中調用的所有類(lèi)和方法。當所有用例的上述信息都被捕獲之后，就很容易發(fā)現類(lèi)的變更對用例的影響。MaintainJ能夠有效工作的前提條件就是項目的所有用例都應當先運行一遍，以便能夠獲得運行時(shí)的依賴(lài)關(guān)系。
總之，目前你在迅速準確分析變更影響方面，還是可以從工具中獲得有限的幫助。首先根據需要實(shí)施一些影響分析，然后根據自己或小組其他高級成員評審來(lái)判斷變更的影響。你可能需要使用上述工具對你的判斷進(jìn)行反復確認。
為了快速交付，可以不全盤(pán)理解架構，但絕不能以降低代碼質(zhì)量為條件。下面是一些你可能因為只考慮快速交付而引發(fā)的代碼質(zhì)量問(wèn)題。
因為修改代碼涉及到很多的依賴(lài)關(guān)系，所以新增代碼相對而言風(fēng)險較小。例如，有五個(gè)用例都調用了某個(gè)方法。為了改進(jìn)某個(gè)用例，你需要修改這個(gè)方法的實(shí)現。最簡(jiǎn)單的做法就是復制這個(gè)方法，重命名，然后在改進(jìn)的用例中調用新方法。千萬(wàn)不要這么做。代碼冗余絕對是非常有害的。你要嘗試對方法進(jìn)行包裝或者重寫(xiě)，甚至是直接修改，然后重新測試所有用例，通常停下來(lái)想一想，然后親手去實(shí)施，是一種不錯的方式。
另一個(gè)例子是將“private”方法改為“public”，讓別的類(lèi)也可以調用。盡量不要將非必須的部分暴露出來(lái)。假如是為了更好的設計而需要重構，那么就應當著(zhù)手去做。
大部分應用都有確定的結構和模式來(lái)實(shí)施。修復或增強程序時(shí)，你要確保不會(huì )偏離這樣的模式。如果對規約不確定，那么就請其他高級開(kāi)發(fā)者來(lái)審核你的變更。如果你必須做一些違背規約的動(dòng)作，那么就盡量放置于規模較小的類(lèi)中（一個(gè)200行代碼的類(lèi)中的私有函數應當不會(huì )影響應用的整體設計）
按照文章列出的方式，假設你能夠在對項目了解較少的情況下進(jìn)行交付，并持續這樣下去，可能就會(huì )停止對項目架構的深入了解。這從長(cháng)遠角度來(lái)說(shuō)對你的職業(yè)生涯沒(méi)有幫助。當你的經(jīng)驗增加時(shí)，就會(huì )承擔比較大的模塊任務(wù)。如構建一個(gè)完整的新特性，或者修改項目的一些基礎設計等較大的改進(jìn)。當能夠做這些改進(jìn)時(shí)，你對項目的整體架構應該相當了解。文中列舉的方法只是讓你在最短的時(shí)間內提升自己，而不是阻止你完整理解整個(gè)項目。
整篇文章的重點(diǎn)在于，對項目進(jìn)行必要了解，然后進(jìn)行快速交付。你可以在不降低代碼質(zhì)量的前提下做到這一點(diǎn)。
如果要修復bug，那么迅速定位并修復?？梢栽诒匾臅r(shí)候使用運行時(shí)分析工具。如果要新增特性，那么就可以尋找類(lèi)似特性，理解流程（在必要的時(shí)候使用工具）并編寫(xiě)。
或許這些聽(tīng)起來(lái)很簡(jiǎn)單，但是實(shí)用嗎？當然。前提是你有良好的java技術(shù)，以及對框架足夠了解，然后才能先修改代碼，再分析變更所產(chǎn)生的影響。分析變更所產(chǎn)生的影響比實(shí)施變需要更多技巧。你可能需要高級開(kāi)發(fā)人員協(xié)助你分析變更影響。
大約有50%的IT可操作預算用于簡(jiǎn)單的bug修復和功能增強。文中的建議對于在維護活動(dòng)中節省經(jīng)費應當還是很有幫助的。
作者Choudary Kothapalli 也是MaintainJ項目的創(chuàng )立者。
Choudary Kothapalli 是 MaintainJ Inc.創(chuàng )始人。該公司提供的工具用于在維護大型Java項目時(shí)節省開(kāi)支。作者在開(kāi)發(fā)和維護企業(yè)級Java應用方面已經(jīng)有15年的經(jīng)驗，并且具有Sun認證的企業(yè)架構師與Java開(kāi)發(fā)者資格。他目前和妻子以及2個(gè)兒子居住在加拿大多倫多。
陳晨， 長(cháng)期從事互聯(lián)網(wǎng)信息收集分析領(lǐng)域架構研究。對海量數據處理，NoSQL等處理運用有豐富經(jīng)驗，關(guān)注過(guò)程方法及其自動(dòng)化。他的新浪微博：一酌散千憂(yōu)
聯(lián)系客服
