忠告：送給Java項目開發者的幾點Tips

時間 2019-11-06

原文原文鏈接

假設你是正在開發和維護一個包含2000個類並使用了不少框架的Java開發者。你要如何理解這些代碼？在一個典型的Java企業項目小組中，大部分可以幫你的高級工程師看起來都很忙。文檔也不多。你須要儘快交付成果，並向項目組證實本身的能力。你會如何處理這種情況？這篇文字爲開始一個新項目的Java開發者提供了一些建議。html

　　一、不要試圖一會兒搞懂整個項目

　　好好考慮一下，爲何理解項目代碼是第一位的？大部分狀況是你被要求修復一個bug或者增強系統已有功能。你要作的第一件事情不是理解整個項目的架構。當對項目進行維護時，這樣（理解整個項目架構）可能會對你形成巨大的壓力。java

　　即使是有着10年可靠編程經驗的Java開發者可能也沒有理解項目的核心工做機制，儘管他們可能已經在這個項目工做超過一年（假設他們並不是原始開發人員）。好比，對於認證機制或事務管理機制。程序員

　　他們是怎麼作的？他們對於本身負責的部分很是瞭解，而且可以交付價值給小組。天天的交付價值遠比了解一些之後還不肯定有沒有的東西重要的多。web

　　二、關注於盡快交付價值

　　那我是否認了你對於項目架構理解的熱情了麼？徹底不。我只是要求你儘早的交付價值，一旦你開始一個項目，搭建了開發環境，你就不該該花一兩週時間才交付什麼，不管他的規模大小。假如你是一個有經驗的程序員卻兩週都沒有任何交付，你的經理怎麼會知道你是真的在工做仍是在看新聞。編程

　　因此交付可使你們都輕鬆起來。不要認爲你可以作有價值的交付前必須理解整個項目。這是徹底錯誤的。加一段ｊａｖａｓｃｒｉｐｔ的驗證代碼對業務就頗有價值，經理可以經過你的交付達到對你的信任。這樣可以向上級領導證實你的貢獻以及員工價值。微信

　　日復一日，在你不斷修復bug及加強功能以後，就可以慢慢開始理解項目架構。不要低估對系統方方面面理解時須要花費的時間。花3-4天理解認證機制，2-3天理解事物管理。這些都是依靠以前的類似項目的經歷，但關鍵仍是要花時間才能透徹的理解。要在平常工做中擠出時間，不要向經理要求特定的時間來作這些。session

　　找找項目是否有一些不斷維護的單元測試用例。有效的單元測試用例是理解大型項目代碼的很好途徑。單元測試可以幫助理解代碼片斷，包括一個單元的外部接口（單元如何被調用以及返回內容）及其內部實現（調試單元測試比調試整個實際用例簡單許多）。架構

　　你若是可以很好的理解一些內容，寫一些筆記，或者畫一些類圖、時序圖、數據模型圖，以便你或往後其餘的開發者維護。框架

　　三、維護大型項目所必須的技能

　　你能從事當前的工做，必然已經具備良好的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.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.1不要下降代碼質量

　　爲了快速交付，因此沒有全盤理解架構，但毫不能以下降代碼質量爲條件。下面是一些你可能由於只考慮快速交付而引起的代碼質量問題。

　　由於修改代碼涉及到不少的依賴，因此新增代碼相對而言風險較小。例如，有5個用例都調用了某個方法。爲了改進某個用例，你須要修改這個方法的實現。最簡單的作法就是複製這個方法，重命名，而後在改進的用例中調用新方法。千萬不要這麼作。代碼冗餘絕對是很是有害的。嘗試對方法進行包裝或者重寫，甚至是直接修改，而後從新測試全部用例，一般停下來想想，而後親手去實施，是一個比較好的方式。

　　另外一個例子是將「private」方法改成「public」，使得別的類也能夠調用。儘可能不要將非必須的部分暴露出來。假如爲了更好的設計須要重構，就應當着手去作。

　　大部分應用都有肯定的結構和模式來實施。修復或加強程序時，確認你沒有偏離這樣的模式。若對約定不肯定，請其餘的高級開發者來審覈你的變動。若你必須作一些違背約定的實施，儘可能放置於一個規模較小的類中（一個200行代碼的類中的私有函數應當不會影響應用的總體設計）

　　5.2 不要中止深刻理解項目架構

　　按照文章列出的方式，假設你可以在對項目瞭解較少的狀況下進行交付並以此持續下去，可能你會中止對項目架構的深刻了解。這樣從長遠角度來講對你的職業生涯沒有幫助。當你的經驗增長時，你應當承擔比較大的模塊任務。如構建一個完整的新特性或者修改項目的一些基礎設計等較大的改進。當你可以作這些改進時，你對項目的總體架構應該至關了解。文中列舉的方法是讓你在最短的時間內提高本身，而不是阻止你完整理解整個項目。