較好的代碼維護實踐

在別人實現的基礎上進行開發，基本是一種常態。特別是對原來的代碼陌生的情況下，有沒有什麼好的實踐方法呢？

基本原則:類似重構一樣，盡量減少對原有流程和結構的修改，最好能相容原有結構。上來就按自己的相法來修改代是比較容易的，這樣做很大程度是因為理解原有的代碼需要較長的時間且有一定的難度，但這樣會增加系統的複雜度，也會引入許多不必要的風險。除非得到項目負責人的同意，否則相當然的直接動手重寫，絕非是什麼好事！

那麼如何做呢？要花大量的時間從頭閱讀代碼嗎？你以為文檔寫得那麼好嗎？

嗯，閱讀代碼和文檔是免不了得，但需要有明確的目標和有序的安排。有效地控制各個階段所關注的內容是成功的關鍵。過早的被許多的細節困擾會嚴重打擊自信，有可能會變得越來越艱難！

首先應當解決掉兩個問題:

  1. 原來程式的行為是什麼? (試著像個使用者一樣跑一下，對照一下規格書,去理解它對做什麼?)

  2.現在新的需求是什麼?  (看看需求說明，找人瞭解一下！)

並不需要直接進入代碼和相關技術文檔的閱讀。特別在分析第二個問題時，應當列出一個清單，包含要變更的功能。

到這裡，按照那個清單，從中間找出你認為比較簡單或影響面小的功能，以它為目標展開對現有代碼的分析。因為強烈的目標，這讓你會更有效地關注相關的代碼。而不是，一邊看，發現一個分支，就去轉過去，就像走迷宮一樣。當然雖然是焦點明確，但也免不了困在迷宮中。那麼走出迷宮最好的方式是什麼呢？在走過路上做個標記吧！Easy, 那就一邊看代碼，一邊畫個草圖或流程圖。你可以使用深度搜尋或寬度搜尋的方式，把你的道路打掃乾淨。但只是面前的這條路！

這個過程最為關鍵，你要開始去瞭解原來作者的意圖，適應代碼的寫法。如果發現有類似的變數和函數，不要重新寫，想想有沒有可能重用它。這樣也會促使你用原作者的邏輯來思考。

當然也有工具可以輔助一下，比如Doxygen或者SourceInsight,Kscope之類的。無論如何，運用當前的IDE環境才是最關鍵的。

到這，如果你在沒有失去信心的情況下搞定了，那麼恭喜你。如果開始有點著急了，那就果斷地回頭看一下你定的列表，你現在的選擇真得是最簡單的嗎？

如果這個程式對你而言是一門的新語言，也沒關係。一開始寫錯幾個函數命名或多一個符號，少一個符號的沒有關係，這就是一個成長的過程。只要方法對，方向對，好的結果並不會太遠。

這樣來回幾次之後，有些可能會重工，記得要同步修改你的圖，那是最關鍵的東西！

最後，這是一個迭代的過程，不要一開始就嘗試著掌握一切!  你不是上帝，你只是來給上帝修修房子的。