單元模塊開發本身就存在很多爭議，最典型的就是加密解密，現在很多做CA和認證的公司牛氣大了去了，搞得他們的用戶成了孫子，根子就在於當時用戶太信任他們，結果現在一被破解就得求他們升級，然後再被破解，再升級，中星九號的例子最能說明問題。
我們一開始開發的時候總是被告之：專注自己的模塊，別的模塊看看接口描述就好了，不用關係他們的細節，否則本末倒置了，出了問題先查查自己模塊有沒有問
題，確認自己模塊沒有問題再懷疑別人的。我得承認這些話有一定道理，不過實際問題經常是接口的描述非常簡單，你根本不知道這些調用怎麼實現的，需要注意些
什麼，有什麼限制，比如最簡單的就是時間，會不會阻塞，有沒有多線程產生，內存使用等等。
而你自己設計程序的時候可能根本不會也不可能考慮這麼因素，可能
把他們當成標準c庫調用一樣的來處理，當然單元測試你也不會考慮這些。結果等到系統測試的時候Bug一堆，問題出在你的代碼裏，可是你死活找不到原因，少
量的情況是白癡錯誤，比如“==”錯寫成“=”，大部分情況是你調用別的模塊出現的問題，你沒想到，也沒處理，然後問到他們的時候通常得到的結論是：這是
我們模塊的一個限制，沒寫在文檔裏，抱歉！我們已經在改了，或者沒時間改，等等！這時候你的蛋不是一般的疼啊！因爲你的設計已經層層疊疊，非大修不能達到
目的了，嘔血沒商量啊，而且還得往自己肚子裏咽：誰讓你不多問問細節，多考慮異常情況呢？
基於windows的開發我不清楚，基於linux開發特別需要注意底層技術實現的細節，當然是有用的細節。所以我的建議是：當你的程序高度依賴於別的模塊兒時，一定要搞清楚它們的實現過程，能瞭解代碼最好，如果實在看不到就必須多考慮異常情況，免得你的程序到頭來返工返通宵之類的。