|
|
英文原文：Tips to Developers Starting on Large Applications
假設(shè)你是正在開發(fā)和維護(hù)一個(gè)包含 2000 個(gè)類并使用了很多框架的 Java 開發(fā)人員。你要如何理解這些代碼？在一個(gè)典型的 Java 企業(yè)項(xiàng)目小組中，大部分能夠幫你的高級工程師看起來都很忙。文檔也很少。你需要盡快交付成果，并向項(xiàng)目組證明自己的能力。你會如何處理這種狀況？這篇文字為開始一個(gè)新項(xiàng)目的 Java 開發(fā)者提供了一些建議。
0. 不要試圖一下子搞懂整個(gè)項(xiàng)目
好好考慮一下，為什么理解項(xiàng)目代碼是第一位的？大部分情況是你被要求修復(fù)一個(gè) bug 或者加強(qiáng)系統(tǒng)已有功能。你要做的第一件事情不是理解整個(gè)項(xiàng)目的架構(gòu)。當(dāng)對項(xiàng)目進(jìn)行維護(hù)時(shí)，這樣（理解整個(gè)項(xiàng)目架構(gòu)）可能會對你造成巨大的壓力。
即便是有著 10 年可靠編程經(jīng)驗(yàn)的 Java 開發(fā)者可能也沒有理解項(xiàng)目的核心工作機(jī)制，盡管他們可能已經(jīng)在這個(gè)項(xiàng)目工作超過一年（假設(shè)他們并非原始開發(fā)人員）。比如，對于認(rèn)證機(jī)制或事務(wù)管理機(jī)制。
他們是怎么做的？他們對于自己負(fù)責(zé)的部分非常了解，并且能夠交付價(jià)值給小組。每天的交付價(jià)值遠(yuǎn)比了解一些以后還不確定有沒有的東西重要的多。
1. 關(guān)注于盡快交付價(jià)值
那我是否定了你對于項(xiàng)目架構(gòu)理解的熱情了么？完全不。我只是要求你盡早的交付價(jià)值，一旦你開始一個(gè)項(xiàng)目，搭建了開發(fā)環(huán)境，你就不應(yīng)該花一兩周時(shí)間才交付什么，無論他的規(guī)模大小。假如你是一個(gè)有經(jīng)驗(yàn)的程序員卻兩周都沒有任何交付，你的經(jīng)理怎么會知道你是真的在工作還是在看新聞。
所以交付可以使大家都輕松起來。不要認(rèn)為你能夠做有價(jià)值的交付前必須理解整個(gè)項(xiàng)目。這是完全錯誤的。加一段 Javascript 的驗(yàn)證代碼對業(yè)務(wù)就很有價(jià)值，經(jīng)理能夠通過你的交付達(dá)到對你的信任。這樣能夠向上級領(lǐng)導(dǎo)證明你的貢獻(xiàn)以及員工價(jià)值。
日復(fù)一日，在你不斷修復(fù) bug 及增強(qiáng)功能之后，就能夠慢慢開始理解項(xiàng)目架構(gòu)。不要低估對系統(tǒng)方方面面理解時(shí)需要花費(fèi)的時(shí)間。花3-4天理解認(rèn)證機(jī)制，2-3天理解事務(wù)管理。這些都是依靠之前的相似項(xiàng)目的經(jīng)歷，但關(guān)鍵還是要花時(shí)間才能透徹的理解。要在日常工作中擠出時(shí)間，不要向經(jīng)理要求特定的時(shí)間來做這些。
找找項(xiàng)目是否有一些不斷維護(hù)的單元測試用例。有效的單元測試用例是理解大型項(xiàng)目代碼的很好途徑。單元測試能夠幫助理解代碼片段，包括一個(gè)單元的外部接口（單元如何被調(diào)用以及返回內(nèi)容）及其內(nèi)部實(shí)現(xiàn)（調(diào)試單元測試比調(diào)試整個(gè)實(shí)際用例簡單許多）。
你如果能夠很好的理解一些內(nèi)容，寫一些筆記，或者畫一些類圖、序列圖、數(shù)據(jù)模型圖，以便你或日后其他的開發(fā)者維護(hù)。
2. 維護(hù)大型項(xiàng)目所必須的技能
你能從事當(dāng)前的工作，必然已經(jīng)具有良好的 Java 技術(shù)。我們來談?wù)勀軌蜃屇阍谛马?xiàng)目中良好表現(xiàn)的其他技能。大部分時(shí)間，你在項(xiàng)目中的任務(wù)是修復(fù) bug 和增強(qiáng)功能。
有兩項(xiàng)很重要的技能能夠協(xié)助你維護(hù)大型項(xiàng)目代碼。
2. 1 能夠迅速發(fā)現(xiàn)需要的類
在任何維護(hù)活動中，無論是修復(fù) bug 或增強(qiáng)功能，第一個(gè)動作就是識別出當(dāng)前修復(fù)或增強(qiáng)的用例中調(diào)用的類。當(dāng)你定位到需要修復(fù)或增強(qiáng)的類/方法，就已經(jīng)完工了一半。
2. 2 能夠分析變更的影響
當(dāng)你在完成必要的修改或增強(qiáng)工作后，最重要的就是要確認(rèn)你的修改沒有破壞代碼的其他部分。你要用你的 Java 技術(shù)及對其他框架的理解找出變更可能影響的部分。下面有兩個(gè)簡單的例子詳細(xì)描述了最后提及的情況：
a）當(dāng)類A的 equals () 方法變更后，調(diào)用一個(gè)保護(hù)A實(shí)例的 List 的 contains () 方法時(shí)就會被影響到。若 Java 知識不夠，很難考慮到這樣的影響。
b）在一個(gè) web 項(xiàng)目中，我們假設(shè)“user id”保存在 session 中。一個(gè)新入程序員可能在“user id”中加入一些信息作為 bug 修復(fù)的方法，但是卻不知道會影響到那些關(guān)聯(lián)“user id”的用例。
當(dāng)你提高了如上兩個(gè)技能，盡管你對項(xiàng)目不是非常了解，但大部分的維護(hù)任務(wù)會變得簡單很多。若你修復(fù)一個(gè) bug，你會定位并修復(fù)這個(gè) bug，并且保證變更不會破壞項(xiàng)目的其他部分。若你增強(qiáng)或加入一個(gè)特性，基本上你只需要模仿現(xiàn)有的特性使用相似的設(shè)計(jì)。
在一個(gè)在線銀行項(xiàng)目中，為什么“查看賬戶摘要”和“查看交易歷史”的設(shè)計(jì)需要巨大的差別呢？如果你理解了“查看賬戶摘要”的設(shè)計(jì)，完全可以模仿開發(fā)出“查看交易歷史”的功能。
就修復(fù) bug 和增強(qiáng)來說，你不必完全理解所有 2000 個(gè)類的工作內(nèi)容和代碼如何運(yùn)行來推動系統(tǒng)。你若有上面的技能，就能很快定位需要修改的代碼的部分，使用良好的 Java 和框架技能修復(fù)，保證變更不會破壞項(xiàng)目的其他部分并交付，盡管你可能只知道一小部分項(xiàng)目的設(shè)計(jì)。
3. 使用工具找到需要的變更內(nèi)容以及變更產(chǎn)生的影響
繼續(xù)我們盡快交付的主題，你應(yīng)當(dāng)尋找那些能夠通過盡量少的了解項(xiàng)目但能幫助你盡快實(shí)施交付的工具作為輔助。
3. 1 迅速發(fā)現(xiàn)需要變更內(nèi)容的工具
無論是修復(fù) bug 還是系統(tǒng)增強(qiáng)，首先都要找到該用例調(diào)用的你需要修改的類及方法。基本有兩種方式理解一個(gè)用例的工作方式：靜態(tài)代碼分析和運(yùn)行時(shí)分析。
源碼分析統(tǒng)計(jì)工具掃描所有代碼并且展示類之間的關(guān)系。市場上有很多設(shè)備與工具。比如：Architexa， AgileJ， UModel， Poseidon 等。
所有的靜態(tài)代碼分析工具的缺點(diǎn)在于無法確切展示用例中類或方法的運(yùn)行時(shí)調(diào)用情況。因此 Java 新加入了特性，如回調(diào)機(jī)制（callback patterns）。如靜態(tài)分析工具無法推斷出當(dāng)頁面提交按鈕被點(diǎn)擊時(shí)哪個(gè) Servlet 被調(diào)用了。
運(yùn)行時(shí)分析工具能夠展示類和方法在用例運(yùn)行時(shí)的狀態(tài)。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer 等。這些工具可以捕獲運(yùn)行時(shí)的堆棧狀態(tài)，并以此為一個(gè)用例生成序列圖和類圖。
序列圖展示了該用例在運(yùn)行時(shí)所有調(diào)用的方法。若你在修復(fù)一個(gè) bug，那這個(gè) bug 很可能就是這些被調(diào)用的方法之一。
若你在增強(qiáng)已有功能，利用序列圖理解調(diào)用流程然后再修改。可能是新增一個(gè)驗(yàn)證，修改 DAO 等。
若你在新增功能，找到一些相似的特性，利用序列圖理解調(diào)用流程，然后模仿開發(fā)新功能。
要小心挑選運(yùn)行時(shí)分析工具。信息過多是這類工具的主要問題。選擇一些提供簡單的過濾無效信息并能夠方便的查看各種視圖的工具。
3. 2 迅速發(fā)現(xiàn)需要變更內(nèi)容的工具
若單元測試有效，可以通過運(yùn)行單元測試發(fā)現(xiàn)變更有沒有破壞其他測試用例。有效維護(hù)并且覆蓋大型企業(yè)應(yīng)用的單元測試還是比較少的。下面有一些針對該情況的工具。
仍然是有兩種技術(shù)靜態(tài)代碼分析和運(yùn)行時(shí)分析可以使用。市場中有很多靜態(tài)代碼分析工具可用。如：Lattix, Structure101, Coverity, nWire and IntelliJ’s DSM。
給定一個(gè)變更后的類，上述工具均可識別對該類存在依賴的類的集合。開發(fā)者需要根據(jù)這些信息“猜測”可能產(chǎn)生影響的用例，因?yàn)檫@些工具無法展示運(yùn)行時(shí)類之間的調(diào)用關(guān)系。
市場上的可以用于運(yùn)行時(shí)影響分析的工具并不多，除了 MaintainJ。MaintainJ 先捕獲在一個(gè)用例中調(diào)用的所有類和方法。當(dāng)所有用例的上述信息都被捕獲之后，就很容易發(fā)現(xiàn)類的變更對用例的影響。MaintainJ 能夠有效工作的前置條件就是項(xiàng)目的所有用例都應(yīng)當(dāng)先運(yùn)行一遍，以便能夠獲得運(yùn)行時(shí)的依賴關(guān)系。
總之，目前你在迅速準(zhǔn)確分析變更影響方面，還是可以從工具中獲得有限的幫助。首先根據(jù)需要實(shí)施一些影響分析，然后根據(jù)自己或小組其他高級成員評審來判斷變更的影響。你可能需要上面提到的工具對你的判斷進(jìn)行反復(fù)確認(rèn)。
4. 對上述內(nèi)容的兩個(gè)忠告
4. 1 不要降低代碼質(zhì)量
為了快速交付，所以沒有全盤理解架構(gòu)，但絕不能以降低代碼質(zhì)量為條件。下面是一些你可能因?yàn)橹豢紤]快速交付而引發(fā)的代碼質(zhì)量問題。
因?yàn)樾薷拇a涉及到很多的依賴，所以新增代碼相對而言風(fēng)險(xiǎn)較小。例如，有 5 個(gè)用例都調(diào)用了某個(gè)方法。為了改進(jìn)某個(gè)用例，你需要修改這個(gè)方法的實(shí)現(xiàn)。最簡單的做法就是復(fù)制這個(gè)方法，重命名，然后在改進(jìn)的用例中調(diào)用新方法。千萬不要這么做。代碼冗余絕對是非常有害的。嘗試對方法進(jìn)行包裝或者重寫，甚至是直接修改，然后重新測試所有用例，通常停下來想一想，然后親手去實(shí)施，是一個(gè)比較好的方式。
另一個(gè)例子是將“private”方法改為“public”，使得別的類也可以調(diào)用。盡量不要將非必須的部分暴露出來。假如為了更好的設(shè)計(jì)需要重構(gòu)，就應(yīng)當(dāng)著手去做。
大部分應(yīng)用都有確定的結(jié)構(gòu)和模式來實(shí)施。修復(fù)或增強(qiáng)程序時(shí)，確認(rèn)你沒有偏離這樣的模式。若對約定不確定，請其他的高級開發(fā)者來審核你的變更。若你必須做一些違背約定的實(shí)施，盡量放置于一個(gè)規(guī)模較小的類中（一個(gè) 200 行代碼的類中的私有函數(shù)應(yīng)當(dāng)不會影響應(yīng)用的整體設(shè)計(jì)）
4. 2 不要停止深入理解項(xiàng)目架構(gòu)
按照文章列出的方式，假設(shè)你能夠在對項(xiàng)目了解較少的情況下進(jìn)行交付并以此持續(xù)下去，可能你會停止對項(xiàng)目架構(gòu)的深入了解。這樣從長遠(yuǎn)角度來說對你的職業(yè)生涯沒有幫助。當(dāng)你的經(jīng)驗(yàn)增加時(shí)，你應(yīng)當(dāng)承擔(dān)比較大的模塊任務(wù)。如構(gòu)建一個(gè)完整的新特性或者修改項(xiàng)目的一些基礎(chǔ)設(shè)計(jì)等較大的改進(jìn)。當(dāng)你能夠做這些改進(jìn)時(shí)，你對項(xiàng)目的整體架構(gòu)應(yīng)該相當(dāng)了解。文中列舉的方法是讓你在最短的時(shí)間內(nèi)提升自己，而不是阻止你完整理解整個(gè)項(xiàng)目。
5. 結(jié)論
整篇文章集中在對項(xiàng)目進(jìn)行必要了解的前提下進(jìn)行快速交付。你可以在不降低代碼質(zhì)量的前提下這么做。
若修復(fù)一個(gè) bug，迅速定位并修復(fù)。有必要可以使用運(yùn)行時(shí)分析工具。若新增一個(gè)特性，可以尋找相似特性，理解流程（有必要使用工具）并編寫。
或許這些聽起來很簡單，但是實(shí)用嗎？當(dāng)然。但前提是你有良好的 Java 技術(shù)以及對框架足夠了解才能先修改代碼，然后對變更影響進(jìn)行分析。對變更影響的分析比實(shí)施變更需要更多的技巧。你可能需要高級開發(fā)人員協(xié)助你分析變更影響。
大約有 50% 的 IT 可操作預(yù)算用于簡單的 bug 修復(fù)和功能增強(qiáng)。根據(jù)文中的建議，對于維護(hù)活動中的經(jīng)費(fèi)的節(jié)省應(yīng)當(dāng)還是很有幫助的。
作者 Choudary Kothapalli 也是 MaintainJ 項(xiàng)目的建立者。
it知識庫：給開發(fā)維護(hù)大型項(xiàng)目開發(fā)者的建議，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
