英文原文：Tips to Developers Starting on Large Applications

　　假如你是一名Java開發(fā)者，正在開發(fā)和維護包含2000個類并使用了很多框架的應(yīng)用程序。你要如何理解這些代碼呢？在典型的Java企業(yè)項目小組中，大部分能夠幫你的高級工程師看起來都很忙，文檔也很少。你需要盡快交付成果，并向項目組證明自己的能力。你會如何處理這種狀況呢？這篇文章為開始開發(fā)新項目的Java開發(fā)者提供了一些建議。

　　1. 不要試圖一下子搞懂整個項目

　　仔細考慮一下，為什么你會想要先理解項目代碼呢？大部分情況是有人要求你修復(fù)一個bug，或者增強系統(tǒng)已有功能。你要做的第一件事情不是理解整個項目的架構(gòu)。當對項目進行維護時，這樣做（理解整個項目架構(gòu)）可能會對你造成巨大的壓力。

　　即便是有10年編程經(jīng)驗的Java開發(fā)者，也無法理解項目的核心工作機制，盡管他們可能已經(jīng)在這個項目工作超過一年（假設(shè)他們并非最初的開發(fā)人員）。比如，對于認證機制或事務(wù)管理機制還是缺乏確切的認識。

　　他們是怎么做的呢？他們對于自己負責的部分非常了解，并且能夠交付價值給小組。每天的交付價值遠比了解一些以后還不確定有沒有的東西重要的多。

　　2. 關(guān)注于盡快交付價值

　　那我是要打消你對于理解項目架構(gòu)的熱情嗎？完全不是。我只是要求你盡早地交付價值，一旦你開始一個項目，搭建了開發(fā)環(huán)境，你就不應(yīng)該花一兩周時間才交付內(nèi)容，無論它的規(guī)模大小如何。假如你是一位有經(jīng)驗的程序員，卻兩周都沒有任何交付，你的經(jīng)理怎么會知道你是真的在工作，還是在看新聞呢？。

　　所以交付能夠?qū)⑹虑樽兊煤唵巍２灰J為在做有價值的交付前，你必須理解整個項目。這是完全錯誤的。加一段Javascript的驗證代碼對業(yè)務(wù)就很有價值，經(jīng)理能夠通過你的交付對你更加信任。這樣能夠向上級領(lǐng)導(dǎo)證明你的貢獻以及員工價值。

　　日復(fù)一日，在不斷修復(fù)bug及增強功能之后，你就能夠慢慢開始理解項目架構(gòu)。不要低估對系統(tǒng)方方面面理解時需要花費的時間?；?到4天理解認證機制，2到3天理解事務(wù)管理。這些都是依靠之前的相似項目的經(jīng)歷，但關(guān)鍵還是要花時間才能透徹的理解。要在日常工作中擠出時間，不要向經(jīng)理要求特定的時間來做這些。

　　找找項目是否有一些有效維護的單元測試用例。有效的單元測試用例是理解大型項目代碼很好的途徑。單元測試能夠幫助你理解代碼片段，包括一個單元的外部接口（單元如何被調(diào)用以及返回內(nèi)容）及其內(nèi)部實現(xiàn)（調(diào)試單元測試比調(diào)試整個實際用例簡單許多）。

　　你如果能夠很好的理解一些內(nèi)容，那么就寫些筆記，或者畫些類圖、時序圖、數(shù)據(jù)模型圖等，以便你或日后其他的開發(fā)者可以進行維護。

　　3. 維護大型項目所必須的技能

　　你能從事當前的工作，必然已經(jīng)具有良好的Java技術(shù)。我們來談?wù)勀軌蜃屇阍谛马椖恐辛己帽憩F(xiàn)的其他技能。大部分時間里，你在項目中的任務(wù)是修復(fù)bug和增強功能。

　　有兩項很重要的技能能夠在你維護大型項目代碼起到幫助。

　　3. 1 能夠迅速發(fā)現(xiàn)需要的類

　　在任何維護活動中，無論是修復(fù)bug或增強功能，第一件事情就是識別出當前修復(fù)或增強的用例中調(diào)用的類。當你定位到需要修復(fù)或增強的類/方法，就已經(jīng)完工了一半。

　　3. 2 能夠分析變更的影響

　　當你在完成必要的修改或增強工作后，最重要的就是要確認你的修改沒有破壞代碼的其他部分。你要用你的Java技術(shù)及對其他框架的理解找出變更可能影響的部分。下面兩個簡單的例子詳細描述了最后提及的情況：

•  當類A的equals()方法變更后，調(diào)用保存A實例的List的contains()方法時就會受到影響。若Java知識不夠，就很難考慮到這樣的影響。
•  在web項目中，我們假設(shè)“user id”保存在session中。新加入的程序員可能在“user id”中加入一些信息來修復(fù)bug，但是卻不知道那會影響到 與“user id”關(guān)聯(lián)的用例。

　　因此，既要深入了解Java語言，又要深入了解你在應(yīng)用中使用的框架，這樣才能分析出一個改變的影響。

　　當你提高了如上兩個技能，盡管你對項目不是非常了解，但大部分的維護任務(wù)會變得簡單很多。如果你想要修復(fù)一個bug，就會定位并修復(fù)這個bug，并且保證變更不會破壞項目的其他部分。如果你想要增強或加入特性，基本上你只需要模仿現(xiàn)有的特性，使用類似的設(shè)計。

　　在一個在線銀行項目中，為什么“查看賬戶摘要”和“查看交易歷史”的設(shè)計要有巨大的差別呢？如果你理解了“查看賬戶摘要”的設(shè)計，完全可以模仿開發(fā)出“查看交易歷史”的功能。

　　就修復(fù)bug和增強來說，你不必完全理解所有2000個類的工作內(nèi)容和代碼驅(qū)動系統(tǒng)運行的原理。只要有上面的技能，你就能很快定位需要修改的代碼，使用良好的Java和框架技能修復(fù)，保證變更不會破壞項目的其他部分，然后交付，盡管你可能只知道一小部分項目的設(shè)計。

　　4. 使用工具找到所需變更內(nèi)容以及變更產(chǎn)生的影響

　　繼續(xù)我們盡快交付的主題，你應(yīng)該尋找工具作為輔助，只需要對項目又很少理解，就能幫助你盡快實施交付。

　　4. 1 迅速發(fā)現(xiàn)所需變更內(nèi)容的工具

　　無論是修復(fù)bug還是增強系統(tǒng)，首先你都要找到該用例調(diào)用且需要修改的類及方法?；旧嫌袃煞N方式理解用例的工作方式，靜態(tài)代碼分析和運行時分析。

　　源碼分析統(tǒng)計會掃描所有代碼并且展現(xiàn)類之間的關(guān)系。市場上有很多工具。比如：Architexa、AgileJ、UModel、Poseidon等。

　　所有靜態(tài)代碼分析工具的缺點在于，它們無法確切展現(xiàn)用例中類或方法的運行時調(diào)用情況。因此Java新加入了一些特性，如回調(diào)機制（callback patterns）。比方說，靜態(tài)分析工具無法推斷出當前頁面提交按鈕被點擊時，會調(diào)用哪個Servlet。

　　運行時分析工具能夠展現(xiàn)類和方法在用例運行時的狀態(tài)。這樣的工具包括：MaintainJ、Diver、jSonde、Java Call Tracer等。這些工具可以捕獲運行時的堆棧狀態(tài)，并以此為用例生成序列圖和類圖。

　　序列圖會展現(xiàn)該用例在運行時所有調(diào)用的方法。如果你在修復(fù)bug，那么這個bug很可能就是這些被調(diào)用的方法之一。

　　如果你在增強已有功能，可能是新增驗證，修改DAO等，那么就可以利用序列圖理解調(diào)用流程然后再修改。

　　如果你在新增功能，那么就可以找到一些相似的特性，利用序列圖理解調(diào)用流程，然后模仿開發(fā)新功能。

　　要仔細地挑選運行時分析工具。信息過多是這類工具的主要問題。選擇一些工具，能夠提供簡單的信息，過濾掉無效信息，并能夠方便的查看各種視圖。

　　4. 2 迅速發(fā)現(xiàn)所需變更內(nèi)容的工具

　　若單元測試有效，你就可以通過運行單元測試發(fā)現(xiàn)變更有沒有破壞其他測試用例。有效維護并且覆蓋大型企業(yè)應(yīng)用的單元測試還是比較少的。下面有一些針對該情況的工具。

　　在此，仍然是有兩種技術(shù)——靜態(tài)代碼分析和運行時分析——可以使用。市場中有很多靜態(tài)代碼分析工具可用。如：Lattix、Structure101、Coverity、nWire和IntelliJ's DSM。

　　對于變更后的類，上述工具均可識別對該類存在依賴的類的集合。開發(fā)者需要根據(jù)這些信息“猜測”可能產(chǎn)生影響的用例，因為這些工具無法展示運行時類之間的調(diào)用關(guān)系。

　　市場上可以用于運行時影響分析的工具并不多，可能只有MaintainJ。MaintainJ先會捕獲在用例中調(diào)用的所有類和方法。當所有用例的上述信息都被捕獲之后，就很容易發(fā)現(xiàn)類的變更對用例的影響。MaintainJ能夠有效工作的前提條件就是項目的所有用例都應(yīng)當先運行一遍，以便能夠獲得運行時的依賴關(guān)系。

　　總之，目前你在迅速準確分析變更影響方面，還是可以從工具中獲得有限的幫助。首先根據(jù)需要實施一些影響分析，然后根據(jù)自己或小組其他高級成員評審來判斷變更的影響。你可能需要使用上述工具對你的判斷進行反復(fù)確認。

　　5. 對上述內(nèi)容的兩個忠告

　　5. 1 不要降低代碼質(zhì)量

　　為了快速交付，可以不全盤理解架構(gòu)，但絕不能以降低代碼質(zhì)量為條件。下面是一些你可能因為只考慮快速交付而引發(fā)的代碼質(zhì)量問題。

　　因為修改代碼涉及到很多的依賴關(guān)系，所以新增代碼相對而言風險較小。例如，有五個用例都調(diào)用了某個方法。為了改進某個用例，你需要修改這個方法的實現(xiàn)。最簡單的做法就是復(fù)制這個方法，重命名，然后在改進的用例中調(diào)用新方法。千萬不要這么做。代碼冗余絕對是非常有害的。你要嘗試對方法進行包裝或者重寫，甚至是直接修改，然后重新測試所有用例，通常停下來想一想，然后親手去實施，是一種不錯的方式。

　　另一個例子是將“private”方法改為“public”，讓別的類也可以調(diào)用。盡量不要將非必須的部分暴露出來。假如是為了更好的設(shè)計而需要重構(gòu)，那么就應(yīng)當著手去做。

　　大部分應(yīng)用都有確定的結(jié)構(gòu)和模式來實施。修復(fù)或增強程序時，你要確保不會偏離這樣的模式。如果對規(guī)約不確定，那么就請其他高級開發(fā)者來審核你的變更。如果你必須做一些違背規(guī)約的動作，那么就盡量放置于規(guī)模較小的類中（一個200行代碼的類中的私有函數(shù)應(yīng)當不會影響應(yīng)用的整體設(shè)計）

　　5. 2 不要停止深入理解項目架構(gòu)

　　按照文章列出的方式，假設(shè)你能夠在對項目了解較少的情況下進行交付，并持續(xù)這樣下去，可能就會停止對項目架構(gòu)的深入了解。這從長遠角度來說對你的職業(yè)生涯沒有幫助。當你的經(jīng)驗增加時，就會承擔比較大的模塊任務(wù)。如構(gòu)建一個完整的新特性，或者修改項目的一些基礎(chǔ)設(shè)計等較大的改進。當能夠做這些改進時，你對項目的整體架構(gòu)應(yīng)該相當了解。文中列舉的方法只是讓你在最短的時間內(nèi)提升自己，而不是阻止你完整理解整個項目。

　　6. 結(jié)論

　　整篇文章的重點在于，對項目進行必要了解，然后進行快速交付。你可以在不降低代碼質(zhì)量的前提下做到這一點。

　　如果要修復(fù)bug，那么迅速定位并修復(fù)?？梢栽诒匾臅r候使用運行時分析工具。如果要新增特性，那么就可以尋找類似特性，理解流程（在必要的時候使用工具）并編寫。

　　或許這些聽起來很簡單，但是實用嗎？當然。前提是你有良好的Java技術(shù)，以及對框架足夠了解，然后才能先修改代碼，再分析變更所產(chǎn)生的影響。分析變更所產(chǎn)生的影響比實施變需要更多技巧。你可能需要高級開發(fā)人員協(xié)助你分析變更影響。

　　大約有50%的IT可操作預(yù)算用于簡單的bug修復(fù)和功能增強。文中的建議對于在維護活動中節(jié)省經(jīng)費應(yīng)當還是很有幫助的。

　　作者Choudary Kothapalli 也是MaintainJ項目的創(chuàng)立者。

　　關(guān)于作者

　　Choudary Kothapalli 是  MaintainJ Inc.創(chuàng)始人。該公司提供的工具用于在維護大型Java項目時節(jié)省開支。作者在開發(fā)和維護企業(yè)級Java應(yīng)用方面已經(jīng)有15年的經(jīng)驗，并且具有Sun認證的企業(yè)架構(gòu)師與Java開發(fā)者資格。他目前和妻子以及2個兒子居住在加拿大多倫多。

　　關(guān)于譯者

　　陳晨， 長期從事互聯(lián)網(wǎng)信息收集分析領(lǐng)域架構(gòu)研究。對海量數(shù)據(jù)處理，NoSQL等處理運用有豐富經(jīng)驗，關(guān)注過程方法及其自動化。他的新浪微博：一酌散千憂

it知識庫：程序員開發(fā)大型應(yīng)用程序的技巧，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。