前陣子去買了兩本書，《重構》和《修改代碼的藝術》。根據高人指點，決定先讀《修改代碼的藝術》。

1.中文譯名問題
本書英文原名《Working Effectively with Legacy Code》，大體意思是有效的面對遺留代碼，但是不知道為何被翻譯為修改代碼的藝術，而我覺得本書所講述的內容并不是關于修改代碼的具體細節，更沒有太多藝術感。但是這絲毫不影響這本書的價值，以及方法的可行性。

2.本書的主要內容
提前說明一個概念，遺留代碼：已有的項目代碼，不管是你的，還是他人的，不管是維護中的，還是開發中的，總之是已經寫好的代碼，稱為遺留代碼。當代碼被寫下來，編譯通過，并checkin后，它就變成了遺留代碼。
本書主要講的是在對遺留代碼進行修改前，要進行的準備工作，即安置單元測試，保護當前代碼的已有行為，并在此基礎上引入測試驅動開發。
如何把測試安置到遺留代碼中，并不是一件簡單的事情，本書正是為了讓我們做到這件不簡單的事情而準備的，因此把本書看作測試驅動開發實踐的前哨和準備也不為過。

3.安置測試難在哪里？
簡單的單元測試說白了很簡單，實例化一個類，然后調用被測試方法，然后驗證測試結果。但現實很復雜，一個不良的類很難實例化，當你實例化這個類的時候，往往要實例化另外一個被依賴的類，如果該類涉及I/O，網絡，數據庫什么的，難道還要為了單元測試配置環境不成？
另外一個難處是難以調用被測試方法，因為該方法可能會顯性的（通過參數）或者隱性的（全局變量）依賴于一些難以實例化的類和對象。
最后一個難處是如何感知測試結果并驗證，有返回值的函數還可以判斷個返回值什么的，沒有返回值的函數怎么才知道它是正確的呢？
以上這三個問題，我是沒想到如何解決，在我早期接觸單元測試這個概念的時候。

4.如何安置測試
要安置測試首先必須找出測試點，當難以用相關技術在測試點安置測試的話，采取退一步的策略是比較劃算的。
當確定測試點后，為了在測試點安置測試，首先要進行的就是解依賴。解依賴的目的是分解出當前的類對其他難以實例化的類和全局變量過分緊密的依賴，使得被測試的類容易在測試工具中實例化，被測試方法容易調用。
要解依賴，就要利用被測試代碼中的接縫，在測試工具中分離出難以實例化的依賴。書中對接縫是這樣定義的：“是指程序中的一些特殊的點，在這些點上你無需做任何修改就可以達到改動程序行為的目的。”。
舉一個接縫的簡單例子，如虛函數，你無需對原來的代碼做任何改動，就可以通過繼承并重載來改變程序的行為。
遺留代碼也許并沒有多少接縫，因此為安置測試而解依賴的主要目的就是將依賴放置到接縫下，并在測試工具下改變接縫的行為，使得能夠實例化被測試類，以及調用被測試方法，并通過接縫感知和驗證測試結果。
總的來說，安置測試的過程如下：
      4.1找出測試點
      4.2解依賴：用接縫包住依賴
      4.3在測試工具下改變接縫行為
      4.4簡單的執行單元測試：實例化類，調用被測試方法
      4.5驗證測試結果，通過接縫驗證測試結果（需要的話）

5.接縫（解依賴技術）
本書一共給出24種解依賴技術，不過我感覺其實很多是已有方法的變種，因此總結了一下，常用的有4種：虛函數并子類化，設置并替換，獲取方法，參數化方法。特殊的有2種：參數包裝，方法對象。

6.《修改代碼的藝術》，這里有什么好修改的？
這本書能和修改細節扯上邊的地方，就是解依賴技術了。為了提供接縫，就必須在沒有測試保護的情況下對遺留代碼進行修改，因此最好采取盡量安全的修改方式。本書給出了為了解依賴，制造接縫而如何進行安全修改的修改細節，當然簡單的說無非就是簽名保持和剪切粘貼之類的了。

7.我的實踐
不動指頭不讀書。我用當前的項目中我寫的一個類進行了試驗，為它的每個public函數安置了多個單元測試，解依賴的運用還算正常，掌握得不是很好。
我選擇的測試框架是，CppUnitLite，這個比CppUnit易用，作者本身也承認了。
配置測試工程：建立一個exe工程，將產品工程的配置復制過來，并添加對測試框架的依賴。
為了方便分離測試代碼和產品代碼，一個好的建議是：產品的工程只做成一個殼子，而將相關的邏輯部分編譯成一個靜態庫，這樣測試工程和產品工程都可以使用，并且兩者是分離的。