【轉】程式員開發大型應用程式的技巧

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

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

即便是有10年程式設計經驗的java開發者，也無法了解項目的核心工作機制，盡管他們可能已經在這個項目工作超過一年（假設他們并非最初的開發人員）。比如，對于認證機制或事務管理機制還是缺乏确切的認識。

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

那我是要打消你對于了解項目架構的熱情嗎？完全不是。我隻是要求你盡早地傳遞價值，一旦你開始一個項目，搭建了開發環境，你就不應該花一兩周時間才傳遞内容，無論它的規模大小如何。假如你是一位有經驗的程式員，卻兩周都沒有任何傳遞，你的經理怎麼會知道你是真的在工作，還是在看新聞呢？。

是以傳遞能夠将事情變得簡單。不要認為在做有價值的傳遞前，你必須了解整個項目。這是完全錯誤的。加一段javascript的驗證代碼對業務就很有價值，經理能夠通過你的傳遞對你更加信任。這樣能夠向上級上司證明你的貢獻以及員工價值。

日複一日，在不斷修複bug及增強功能之後，你就能夠慢慢開始了解項目架構。不要低估對系統方方面面了解時需要花費的時間。花3到4天了解認證機制，2到3天了解事務管理。這些都是依靠之前的相似項目的經曆，但關鍵還是要花時間才能透徹的了解。要在日常工作中擠出時間，不要向經理要求特定的時間來做這些。

找找項目是否有一些有效維護的單元測試用例。有效的單元測試用例是了解大型項目代碼很好的途徑。單元測試能夠幫助你了解代碼片段，包括一個單元的外部接口（單元如何被調用以及傳回内容）及其内部實作（調試單元測試比調試整個實際用例簡單許多）。

你如果能夠很好的了解一些内容，那麼就寫些筆記，或者畫些類圖、時序圖、資料模型圖等，以便你或日後其他的開發者可以進行維護。

你能從事目前的工作，必然已經具有良好的java技術。我們來談談能夠讓你在新項目中良好表現的其他技能。大部分時間裡，你在項目中的任務是修複bug和增強功能。

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

在任何維護活動中，無論是修複bug或增強功能，第一件事情就是識别出目前修複或增強的用例中調用的類。當你定位到需要修複或增強的類/方法，就已經完工了一半。

當你在完成必要的修改或增強工作後，最重要的就是要确認你的修改沒有破壞代碼的其他部分。你要用你的java技術及對其他架構的了解找出變更可能影響的部分。下面兩個簡單的例子較長的描述了最後提及的情況：

 當類a的equals()方法變更後，調用儲存a執行個體的list的contains()方法時就會受到影響。若java知識不夠，就很難考慮到這樣的影響。

 在web項目中，我們假設“user id”儲存在session中。新加入的程式員可能在“user id”中加入一些資訊來修複bug，但是卻不知道那會影響到 與“user id”關聯的用例。

是以，既要深入了解java語言，又要深入了解你在應用中使用的架構，這樣才能分析出一個改變的影響。

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

在一個線上銀行項目中，為什麼“檢視賬戶摘要”和“檢視交易曆史”的設計要有巨大的差别呢？如果你了解了“檢視賬戶摘要”的設計，完全可以模仿開發出“檢視交易曆史”的功能。

就修複bug和增強來說，你不必完全了解所有2000個類的工作内容和代碼驅動系統運作的原理。隻要有上面的技能，你就能很快定位需要修改的代碼，使用良好的java和架構技能修複，保證變更不會破壞項目的其他部分，然後傳遞，盡管你可能隻知道一小部分項目的設計。

繼續我們盡快傳遞的主題，你應該尋找工具作為輔助，隻需要對項目又很少了解，就能幫助你盡快實施傳遞。

無論是修複bug還是增強系統，首先你都要找到該用例調用且需要修改的類及方法。基本上有兩種方式了解用例的工作方式，靜态代碼分析和運作時分析。

源碼分析統計會掃描所有代碼并且展現類之間的關系。市場上有很多工具。比如：architexa、agilej、umodel、poseidon等。

所有靜态代碼分析工具的缺點在于，它們無法确切展現 用例中類或方法的運作時調用情況。是以java新加入了一些特性，如回調機制（callback patterns）。比方說，靜态分析工具無法推斷出目前頁面送出按鈕被點選時，會調用哪個servlet。

運作時分析工具能夠展現類和方法在用例運作時的狀态。這樣的工具包括：maintainj、diver、jsonde、java call tracer等。這些工具可以捕獲運作時的堆棧狀态，并以此為用例生成序列圖和類圖。

序列圖會展現該用例在運作時所有調用的方法。如果你在修複bug，那麼這個bug很可能就是這些被調用的方法之一。

如果你在增強已有功能，可能是新增驗證，修改dao等，那麼就可以利用序列圖了解調用流程然後再修改。

如果你在新增功能，那麼就可以找到一些相似的特性，利用序列圖了解調用流程，然後模仿開發新功能。

要仔細地挑選運作時分析工具。資訊過多是這類工具的主要問題。選擇一些工具，能夠提供簡單的資訊，過濾掉無效資訊，并能夠友善的檢視各種視圖。

若單元測試有效，你就可以通過運作單元測試發現變更有沒有破壞其他測試用例。有效維護并且覆寫大型企業應用的單元測試還是比較少的。下面有一些針對該情況的工具。

在此，仍然是有兩種技術——靜态代碼分析和運作時分析——可以使用。市場中有很多靜态代碼分析工具可用。如：lattix、structure101、coverity、nwire和intellij's dsm。

對于變更後的類，上述工具均可識别對該類存在依賴的類的集合。開發者需要根據這些資訊“猜測”可能産生影響的用例，因為這些工具無法展示運作時類之間的調用關系。

市場上可以用于運作時影響分析的工具并不多，可能隻有maintainj。maintainj先會捕獲在用例中調用的所有類和方法。當所有用例的上述資訊都被捕獲之後，就很容易發現類的變更對用例的影響。maintainj能夠有效工作的前提條件就是項目的所有用例都應當先運作一遍，以便能夠獲得運作時的依賴關系。

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

為了快速傳遞，可以不全盤了解架構，但絕不能以降低代碼品質為條件。下面是一些你可能因為隻考慮快速傳遞而引發的代碼品質問題。

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

另一個例子是将“private”方法改為“public”，讓别的類也可以調用。盡量不要将非必須的部分暴露出來。假如是為了更好的設計而需要重構，那麼就應當着手去做。

大部分應用都有确定的結構和模式來實施。修複或增強程式時，你要確定不會偏離這樣的模式。如果對規約不确定，那麼就請其他進階開發者來稽核你的變更。如果你必須做一些違背規約的動作，那麼就盡量放置于規模較小的類中（一個200行代碼的類中的私有函數應當不會影響應用的整體設計）

按照文章列出的方式，假設你能夠在對項目了解較少的情況下進行傳遞，并持續這樣下去，可能就會停止對項目架構的深入了解。這從長遠角度來說對你的職業生涯沒有幫助。當你的經驗增加時，就會承擔比較大的子產品任務。如建構一個完整的新特性，或者修改項目的一些基礎設計等較大的改進。當能夠做這些改進時，你對項目的整體架構應該相當了解。文中列舉的方法隻是讓你在最短的時間内提升自己，而不是阻止你完整了解整個項目。

整篇文章的重點在于，對項目進行必要了解，然後進行快速傳遞。你可以在不降低代碼品質的前提下做到這一點。

如果要修複bug，那麼迅速定位并修複。可以在必要的時候使用運作時分析工具。如果要新增特性，那麼就可以尋找類似特性，了解流程（在必要的時候使用工具）并編寫。

或許這些聽起來很簡單，但是實用嗎？當然。前提是你有良好的java技術，以及對架構足夠了解，然後才能先修改代碼，再分析變更所産生的影響。分析變更所産生的影響比實施變需要更多技巧。你可能需要進階開發人員協助你分析變更影響。

大約有50%的it可操作預算用于簡單的bug修複和功能增強。文中的建議對于在維護活動中節省經費應當還是很有幫助的。

作者choudary kothapalli 也是maintainj項目的創立者。