程序員開發大型應用程序的技巧(2)

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

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

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

　　要仔細地挑選運行時分析工具。信息過多是這類工具的主要問題。選擇一些工具，能夠提供簡單的信息，過濾掉無效信息，并能夠方便的查看各種視圖。

　　4.2 發現變更產生影響的工具

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

　　在此，仍然是有兩種技術——靜態代碼分析和運行時分析——可以使用。市場中有很多靜態代碼分析工具可用。如：Lattix、Structure101、Coverity、nWire和IntelliJ's DSM。

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

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

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

　　5. 對上述內容的兩個忠告

　　5.1 不要降低代碼質量

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

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

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

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

　　5.2 不要停止深入理解項目架構

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

　　6. 結論

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

　　如果要修復bug，那么迅速定位并修復?？梢栽诒匾臅r候使用運行時分析工具。如果要新增特性，那么就可以尋找類似特性，理解流程(在必要的時候使用工具)并編寫。

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

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

原文轉自：http://www.anti-gravitydesign.com