2010-09-03 71 views
17

我是一位初級程序員,作爲我的項目的一部分,我必須修改一個開放源代碼工具(用java編寫),它有數百個類。我必須修改它的一個重要部分以適應項目的需要。在過去的一個月中,我一直在努力嘗試閱讀代碼,試圖找出每個類的功能並試圖從頭到尾找出流水線。瞭解和修改大型項目

80%的課程文件不完整/缺失。剩下的20%是構成該工具通用API的那些。 一個月的代碼閱讀剛剛幫助我理解了基本的體系結構。但是我一直無法弄清楚我需要爲我的項目做些什麼改變。有一次,我開始修改代碼的一部分,很快做了很多我不能記住的更改。

一位朋友建議我嘗試寫下類層次結構。有沒有更好的(標準?)方法來做到這一點?

+0

你可以使用Eclipse本身或其他一些工具,如MaintainJ逆向工程的代碼轉換爲UML圖表。由於您對基本架構有一個公正的理解,因此Class和Sequence圖將爲您提供一個很好的入門代碼。 – InSane 2010-09-03 13:29:36

+0

爲什麼作爲新手程序員必須修改開源工具?即使它是開源的,大多數情況下配置比修改更好。 – emory 2010-09-03 22:17:47

回答

10
  • 檢查在一些源代碼庫中的代碼(顛覆,CVS,GIT中,水銀...)
  • 確保您可以從源生成項目,它
  • 如果你已經運行有一個使用這個開源工具的應用程序,嘗試移除二進制依賴項並在eclipse或任何其他IDE中引入項目依賴項。運行代碼,並通過您想了解
  • 每一個細小的變化犯
  • 後,如果您有不同的看法分支代碼
+4

版本控制+1。另外,不要使用CVS。不要。 – 2010-09-03 13:43:36

0

理解代碼的唯一方法就是閱讀它。繼續工作,這是我的建議。

有些項目比其他項目有更好的文檔。這是一對夫婦,我知道有良好的組織工程: TomcatJettyHudson

您應該檢查java-source更多的開源項目。

2

我的朋友的執行代碼,你是在深塗塗。修改大量,記錄不完整的遺留代碼是使有經驗的程序員認真考慮銷售保險或其他替代職業的樂趣的項目之一。然而,這不是不可能的,這裏有一些我希望能提供幫助的提示。

你的第一個任務是儘可能地理解代碼。你至少在正確的軌道上。獲得關於類結構的好主意是非常重要的,而圖可能是最好的方法。我建議的另一件事是,當你發現什麼是課堂時,自己添加缺失的文檔。這樣,當你回到它時,你不會忘記你發現了什麼。

不要忘記調試器。如果你想知道實際發生了什麼,單步執行相關的代碼,或者直接找出一個調用堆棧在某個特定點上的樣子,這可能會非常有用。

+0

當文檔完成後,請考慮將其提供回原始項目。 – JeremyP 2010-09-03 14:21:09

1

就我個人而言,我認爲嘗試一次性理解整個應用程序非常困難。相反,嘗試只關注某些模塊。例如,如果您可以識別需要更改的模塊(例如,基於屏幕或某個輸入/輸出點),那麼先做一個小小的更改並對其進行測試。從那裏出發,做一個小小的改變,測試並繼續前進。

此外,如果您的項目有單元測試(認爲自己很幸運),並查看您關注的模塊的單元測試。這將有助於您瞭解模塊預期的功能。

4

Eclipse(以及其他IDE)也提供了兩種「戰鬥」。我用他們在非常大的項目:

  • 調用層次 - 右鍵單擊​​方法,然後選擇「呼叫層次」,或使用CTRL + ALT + H。這樣,您撥打所選方法的所有方法,可以選擇進一步檢查樹狀結構。這個功能是真的非常有用。

  • 類型層次結構 - 請參閱類的繼承層次結構。在日食是F4或CTRL + T.

另外:

  • 找到一種方法,使以便更改承擔保存效果,您不必重新部署
  • 使用一個調試器 - 在IDE中以調試模式運行,以便看到流程如何進行
0

在我看來,沒有標準的方法來理解項目。它取決於很多因素,從您正在分析的代碼/架構的可理解性到您之前在大型項目上的經驗。

我建議你使用建模工具對代碼進行逆向工程,以便可以從現有源代碼生成一些UML模型。在您的代碼分析過程中,這些圖表可以作爲圖形指南。

不要害怕使用調試來獲取項目最複雜功能的邏輯。通過指令運行最複雜的代碼指令,查看變量的確切值和對象之間的交互可能會有所幫助。

在重構改變項目以滿足您的需求之前,請務必編寫一些測試用例,以便您可以驗證您的修改不會以意外的方式破壞代碼。

0

這裏有幾個建議

  • 獲取代碼轉換成某種形式的CVS的。 這樣,如果您開始進行更改 您可以隨時回顧以前的 版本。
  • 花時間記錄你 已經學習/經歷了什麼。 Javadoc爲此很好 。
  • 爲您創建一個UML結構代碼。 有很多插件,並會給你一個很好的代碼佈局。
8

Michael Feathers寫了一本名爲Working Effectively with Legacy Code的書。有一個較短的文章版本here

他的一個觀點是,你可以做的最好的事情就是爲現有代碼編寫單元測試。這有助於您瞭解入口點的位置以及代碼的工作方式。然後它可以讓你重構它而不用擔心你會打破它。

從鏈接的文章,他的策略的總結:

1. Identify change points 
2. Find an inflection point 
3. Cover the inflection point 
    a. Break external dependencies 
    b. Break internal dependencies 
    c. Write tests 
4. Make changes 
5. Refactor the covered code.