從設計角度審視Bug 衛語句良好的介面

最近專案組裡有乙個bug，雖然我們大家都沒有因為他而享受到「深夜靜靜改bug」的「樂趣」，但他也著實鬱悶了我們一番。還好我們的mr s同學已經將他拿下，在這篇blog，將記錄下我看到這個bug時的思考：

bug描述：我們既存的乙個連線池出現了洩漏問題。

bug原因：

我們有下面這麼乙個函式

void freeconnection(string type, connectionadapter con);

string dbconntype = "derby"
......
db.freeconnection("dbconntype", conn);

是的，因為根本不存在dbconntype這麼乙個連線池。所以執行一段時間之後，我們的的連線池裡面沒有了鏈結。

bug改修：

那麼這個bug該怎麼改呢? 拿掉那個變數的雙引號?我想不是的。好的辦法我認為有幾個，最後乙個是前面幾個的遞進，但他們思考的角度都是讓介面更友善，讓使用更方便：

1. 從freeconnection的角度思考，在freeconnection裡面加衛語句。

既然我們能確定我們的**中只有兩個pool，那麼當freeconnection在接受到"derby"和"demo"這兩個引數以為的引數的時候，他就應該報告他的呼叫者，說：「嗨，你使用我使用錯了。」比如我們可以丟擲乙個illegalargumentexception。

2. 從freeconnection的呼叫者的角度思考。改變freeconnection的呼叫引數。

這個問題的乙個很隱晦的地方在於，使用了字串來標識，我們要釋放拿個池的鏈結。而程式中又充值著這樣的使用方法。

db.freeconnection("derby", conn);             //想加引號，因為想直接釋放derby這個池
db.freeconnection("dbconntype", conn);   //不想加引號，無用了，但是編譯器沒有幫我們區分過來。

這兩個用法本身就很容易混，那麼從freeconnection函式的使用者看來，完全有理由呼籲乙個更友善的介面，比如像下面這樣

connectionmanager
void freeconnection( connectionpool pool , connectionadapter con);

這樣做的好處是，利用型別保證了引數不會被誤傳，但是這樣做的同時也暴露了很多東西，引來了其他的一些不可取之處。比如帶著乙個沒用的引數，還是乙個鏈結池，在**各處跑來跑去，這麼麻煩我們當初還為什麼要寫connectionmanager

3. 綜上，所以有了方法三：freeconnection方法的介面其實根本就應該是這樣的；

freeconnection(connection conn);

是的，總之是使用者傳遞錯誤了引數，那麼與其像上面那樣，幫助使用者傳遞正確的引數，到不如壓根就不要求使用者傳遞這個引數。而且，既然你有意要做乙個connectionmanage，那麼關於這個池那個池的，本身就應該封裝在你的裡面，don't make user think了。

恩，事情說完了。保證質量是多方面的，不是很努力的測就可以解決的問題，先撇開測試除錯的技巧之類，其勢必也受質量等其他因素的制約。好的設計從**來呢？好的設計應該即是程式設計師推敲的結果，又是他們的直覺使然。

乙個好的專案計畫需要在合適的時候計畫處理以下技術內容技術類文件的準備編碼規約是否定義了完善的編碼規約，是否在內部講解了編碼規約的內容。文件注釋規約是否定義了詳細的檔案注釋規約，檔案頭注釋格式定義，屬性，方法注釋定義，修改，刪除的注釋方法，版本公升級定義等。常見問題彙總是否將常見的問題收集...

從設計角度審視Bug 衛語句 良好的介面