假設你正在開發和維護一個包含2000個類別並使用了很多框架的Java開發者。你要如何理解這些程式碼？在一個典型的Java企業專案小組中，大部分能夠幫你的高階工程師看起來都很忙。文檔也很少。你需要盡快交付成果，並向專案組證明自己的能力。你會如何處理這種狀況？這篇文字為開始一個新專案的Java開發者提供了一些建議。
1、不要試圖一下子搞懂整個專案
好好考慮一下，為什麼理解專案代碼是第一位的？大部分情況是你被要求修復一個bug或加強系統已有功能。你要做的第一件事情不是理解整個專案的架構。當專案進行維護時，這樣（理解整個專案架構）可能會對你造成巨大的壓力。
即便是有著10年可靠程式設計經驗的Java開發者可能也沒有理解專案的核心工作機制，儘管他們可能已經在這個專案工作超過一年（假設他們並非原始開發人員）。例如，對於認證機製或事務管理機制。
他們是怎麼做的？他們對於自己負責的部分非常了解，並且能夠交付價值給小組。每天的交付價值遠比了解一些以後還不確定有沒有的東西重要的多。
2、專注於盡快交付價值
那我是否定了你對於專案架構理解的熱情了麼？完全不。我只是要求你儘早的交付價值，一旦你開始一個項目，搭建了開發環境，你就不應該花一兩週時間才交付什麼，無論他的規模大小。假如你是一個有經驗的程式設計師卻兩週都沒有任何交付，你的經理怎麼會知道你是真的在工作還是在看新聞。
所以交貨可以讓大家都輕鬆起來。不要認為你能夠做有價值的交付前必須理解整個專案。這是完全錯誤的。加上一段javascript的驗證程式碼對業務就很有價值，經理人能夠透過你的交付達到對你的信任。這樣能夠向上級領導證明你的貢獻以及員工價值。
日復一日，在你不斷修復bug及增強功能之後，就能夠慢慢開始理解專案架構。不要低估對系統方方面面理解時需要花費的時間。花3-4天理解認證機制，2-3天理解事物管理。這些都是依靠之前的相似項目的經歷，但關鍵還是要花時間才能透徹的理解。要在日常工作中擠出時間，不要向經理要求特定的時間來做這些。
找找專案是否有一些不斷維護的單元測試案例。有效的單元測試案例是理解大型專案程式碼的很好方法。單元測試能夠幫助理解程式碼片段，包括一個單元的外部介面（單元如何被呼叫以及返回內容）及其內部實現（調試單元測試比調試整個實際用例簡單許多）。
你如果能夠很好的理解一些內容，寫一些筆記，或者畫一些類圖、時序圖、資料模型圖，以便你或日後其他的開發者維護。
3、維護大型專案所必須的技能
你能從事當前的工作，必然已經具有良好的java技術。讓我們來談談能夠讓你在新專案中表現良好的其他技能。大部分時間，你在專案中的任務是修復bug和增強功能。
有兩項很重要的技能能夠協助你維護大型專案程式碼。
3.1能夠快速發現需要的類別
在任何維護活動中，無論是修復bug或增強功能，第一個動作就是識別出當前修復或增強的用例中調用的類別。當你定位到需要修復或增強的類別/方法，就已經完成一半了。
3.2能夠分析變更的影響
當你在完成必要的修改或增強工作後，最重要的就是要確認你的修改沒有破壞代碼的其他部分。你要用你的java技術及對其他框架的理解找出變更可能影響的部分。以下有兩個簡單的例子詳細描述了最後提及的情況：
a）當類別A的equals()方法變更後，呼叫一個保護A實例的List的contains()方法時就會被影響。若Java知識不夠，很難考慮到這樣的影響。
b）在一個web專案中，我們假設「user id」保存在session中。一個新入程式設計師可能會在「user id」中加入一些資訊作為bug修復的方法，但卻不知道會影響到那些關聯「user id」的用例。
當你提升瞭如上兩個技能，儘管你對專案不是非常了解，但大部分的維護任務會變得簡單很多。若你修復一個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 and IntelliJ's DSM。
給定一個變更後的類，上述工具均可識別對該類存在依賴的類的集合。開發者需要根據這些資訊「猜測」可能產生影響的用例，因為這些工具無法展示運行時類別之間的呼叫關係。
市場上的可以用於運行時影響分析的工具並不多，除了MaintainJ。 MaintainJ先捕捉在一個用例中所呼叫的所有類別和方法。當所有用例的上述資訊都 被捕獲之後，就很容易發現類別的變更對用例的影響。 MaintainJ能夠有效工作的前置條件就是專案的所有用例都應當先運行一遍，以便能夠獲得運行時的依 賴關係。
總之，目前你在快速準確分析變更影響方面，還是可以從工具中獲得有限的幫助。首先根據需要實施一些影響分析，然後根據自己或小組其他高階成員評審來判斷變更的影響。你可能需要上面提到的工具對你的判斷進行反覆確認。
5、對上述內容的兩個忠告
5.1不要降低程式碼品質
為了快速交付，所以沒有全盤理解架構，但絕不能以降低程式碼品質為條件。以下是一些你可能因為只考慮快速交付而引發的程式碼品質問題。
因為修改程式碼涉及到很多的依賴，所以新增程式碼相對而言風險較小。例如，有5個用例都呼叫了某個方法。為了改進某個用例，你需要修改這個方法的實作。最簡單的 做法就是複製這個方法，重新命名，然後在改進的用例中呼叫新方法。千萬不要這麼做。程式碼冗餘絕對是非常有害的。嘗試對方法進行包裝或重寫，甚至是直接修 改，然後重新測試所有用例，通常停下來想一想，然後親手去實施，是一個比較好的方式。
另一個例子是將“private”方法改為“public”，使得別的類別也可以呼叫。盡量不要將非必須的部分暴露出來。如果為了更好的設計需要重構，就該當著手去做。
大部分應用都有確定的結構和模式來實作。修復或增強程序時，確認你沒有偏離這樣的模式。若對約定不確定，請其他的資深開發者來審核你的變更。若你必須做一些違反約定的實施，盡量放置於一個規模較小的類別中（一個200行程式碼的類別中的私有函數應當不會影響應用的整體設計）
5.2 不要停止深入理解專案架構
依照文章列出的方式，假設你能夠在對專案了解較少的情況下進行交付並以此持續下去，可能你會停止對專案架構的深入了解。這樣從長遠角度來說對你的職涯沒 有幫助。當你的經驗增加時，你應承擔比較大的模組任務。如建構一個完整的新特性或修改專案的一些基礎設計等較大的改進。當你能夠做這些改進時，你對項 目的整體架構應該相當了解。文中列舉的方法是讓你在最短的時間內提升自己，而不是阻止你完整地理解整個專案。
6、結論
整篇文章集中在對專案進行必要了解的前提下進行快速交付。你可以在不降低程式碼品質的前提下這麼做。
若修復一個bug，迅速定位並修復。有必要可以使用運行時分析工具。若新增一個特寫，可以尋找相似特寫，理解流程（有必要使用工具）並編寫。
或許這些聽起來很簡單，但是實用嗎？當然。但前提是你有良好的java技術以及對框架足夠了解才能先修改程式碼，然後對變更影響進行分析。變更影響的分析比實施變更需要更多的技巧。你可能需要資深開發人員協助你分析變更影響。
大約有50%的IT可操作預算用於簡單的bug修復和功能增強。根據文中的建議，對於維護活動中的經費的節省應當還是很有幫助的。
