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

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

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

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

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

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

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

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