我一直在想，如果下次要作類似改介面的事，要怎樣作，才能減少測試的成本與錯誤發生的情況。我又重看「重構」這本書有關介面修改和測試的部份。配合「重構」所介紹的方法與我們開發現況，我有幾點建議。
1.舊有的介面暫時不要移除，等整體連結測試完成，再看是否需要移除。
不移除的原因主要有幾點。
a.可階段性修改，測試。
在大幅度翻修介面時，像這次多對多的介面修改，改的初期希望可以先對同樣介面修改
處先作測試，在一步一步修改不同的介面，如果拿掉舊介面，我們必須一次就把他改完才能測試。
b.比對測試。
當舊介面與新介面產生的結果不同時，可以馬上就知道哪裡不一樣，也可利額外的測試函式來進行比對。
c.配合舊有程式邏輯
有時候舊程式邏輯是配合舊介面所得出的資料，而且大部來說更改舊有程式邏輯並不是好的修改方法（太複雜了），通常我們會把新介面的資料改成跟舊介面所得資料一樣，當有舊介面時，我們就可以較容易比對、產生相同邏輯的資料。
當然把舊介面移除有時是控制舊介面的遺毒不要殘留，在「重構」這本書建議說有時介面替換太複雜或牽扯太多，無法一次移除介面，可以利用thorw
error的方式並標注不建議使用，來強迫使用介面者必須使用新介面或catch error。不過書中改介面的流程也是在測試完才把舊介面移除。
2.利用中介（轉藉）函式作二段式修改，像GetTWSECategoryIndex(TWSE_SERVID, CBK_CAT_ALL,
vcsCat)這這舊函式，vector同時回傳包含長名和短名的資料，遺憾的新介面並沒有提供這樣的功能，因此在改的時候我們通常要將他轉為我們需要的格式，而有時不是傳回的vector資料格式不符，有時是回傳的bool直改變，舊介面再沒抓到資料會回傳false，而新介面則是傳回一個空vector。這種情形我想到利用中介函式來修改，共同創一個中介函式或類別來轉藉新函式至舊函式的邏輯，例如寫一個類別叫newBkTalk裡面包含GetTWSECategoryIndex這函式，但是他實際的工作是將新介面轉換成舊介面的處理邏輯，而在修改時也很好修改只要把需要換介面處將bktalk的指標轉成newbkTalk即可。
這有兩個好處，1.集中管理，當我們修改時不用再一個個對照，想要換成什麼，並作測試，而當一個錯誤發生，又得重新測試相同的舊介面轉換之處，對每個地方修改只要作一次即可。2.可寫測試函式來測試轉換邏輯是否正確。通常會遇到某些參數帶入時，才發現竟然會與原來預想不同。利用中介函式，可以列舉所有可能進行比對測試，避免轉換出我們未預期的結果，這筆我們在測試還要找各種資料來測所有的結果好很多吧！但是這是在寫測試計畫時才想到的，都已經改完了所以就沒有用了。
暫時寫到這，腦袋裡好像還有一些東西沒表達出來，有點亂，等釐清在繼續寫下去。
對了告訴大家一個方法可以不用登入論壇就能回覆相同主題的方法，只要回覆同一主題至F61RShare@googlegroups.com這裡就可以了。而大家也不需要登入論壇就可以看到論壇討論的文章，只要登入後選擇訂閱論壇文章即可。只有有新主題或文章就會寄信至大家的信箱了。而要發表新主題也只要寄信至F61RShare@googlegroups.com即可。希望論壇能多些水，都乾掉了。
在 2007/3/8，河馬 <hippo_su@yahoo.com.tw> 撰寫：
> 呵呵...原本就有排時間呀.....
> 之前是漏排了吧.....所以我才提醒要特別注意呀....
>
> On 3月6日, 下午11時26分, cccm...@gmail.com wrote:
> > 今天配合bk修改介面，將sysset裡面有用到的函式都改完了，具統計sysset也才僅僅"65"個要改介面的地方，但就搞了我一個下午，才剛剛進
> > 入測試而已。原本看起來只是要換一下函式而已，就像更名一樣，嘿嘿！改第一個，就明顯的體會出沒那麼簡單，除了要找到對應的函式，裡面所該帶的函式也要
> > 稍稍想一下，有時不是一眼就看得出來到底該帶那一個參數，上下程式碼要稍微看一下，就算sysset我幾乎改過一半以上，在改的時候也會稍微猶豫一下。
> > 果不其然，全部修改完成後，編譯後，開始測試時，果然輕易發現一個bug，天知道還有多少bug藏在裡面。有時候某些函式只是特殊的檢查機制，只在特定
> > 時候才可能發生，有可能出了一兩個版本才會發現吧。嘿嘿！最近又找到一個至少是180版本之前就存在的bug，這種bug可是四處存在的。我可以想
> > 像，IMMain此版bug爆增的慘狀了。
> > 這是我改完的建議，是類似這種重構，應該正式的排入時程，而且時程還短不得，正常來講應該是改一個測試一個，而且像這次是多介面轉成同一介面的，要帶入
> > 適當的參數，程式碼有時要還要稍微理解一下，可不是簡單的替換，如果以改一個測試一個來說，一個大概平均也要十分鐘吧，那麼sysset要650分鐘，
> > 也就是大約11個小時，1個半天，當然這是最佳狀況，如果從與熊共舞所提出奈米完成度來看，大概乘以2是合理認為70％有可能達成的機會。所以
> > sysset光改介面應該可以排三天吧。不知道IMMain要排多久？
> > 其實我有另一個想法，應該先開新介面，將舊介面先轉藉到新介面上，等於是說舊介面底子是用新介面的函式，先看看運行是否有問題，沒問題的話，就可以利用
> > 舊介面轉藉新介面的原理一對一對轉，也就不用一個一個測試了。這是重構那本書提供的作法。
> > 不過如果依重構的正常作法來說的話，得先預想所有測試案例，對每次重構都得保證和原來程式運算出來的結果需一致，當然我們是沒有作這種事。重構的兩難是
> > 沒有新增新功能，看不出實際的效果，但他的確會把系統架構改的更好，但所花的時間並沒有想像中的少，尤其花在測試的時間。
>
> --~--~---------~--~----~------------~-------~--~----~
> 您收到此郵件，是因為您訂閱了 Google 網上論壇的「個金產品研發處分享論壇」
> 群組。
> 如要在此群組張貼留言，請寄電子郵件至 F61RShare@googlegroups.com
> 如要取消訂閱此群組，請寄電子郵件至 F61RShare-unsubscribe@googlegroups.com
> 如需更多選項，請造訪此群組：http://groups.google.com/group/F61RShare?hl=zh-TW 。
> -~----------~----~----~----~------~----~------~--~---
>
>
留言