事情的起因與經過
我們公司的合作伙伴使用我們的實時數據庫做一個數據中心的項目，項目使用DotNet開發。合作伙伴的公司有一個員工專門負責封裝數據層--對實時數據庫的增刪改查的封裝。
但是這個人的脾氣有點怪，或者說有點傲氣，一段時間下來，只要他遇到操作數據庫的問題，大部分歸結於數據庫或者我們提供的DotNetSDK的問題。無論是他不會使用的問題，還是確實是我們產品的問題，我們基本上每次都會遠程或者直接到他公司去給他解決問題。
就這樣持續了大概一年的的時間，直到前段時間他遇到一個問題：調用DotNetSDK的一個方法時，根據傳入參數的不同會出現有時正常，有時會拋出一個”找不到DotNetSDK程序集”的異常。
后來同事遠程給他查看問題，發現他是使用Remoting的技術進行遠程調用，而真正調用DotNetSDK的地方是服務端，出現”找不到DotNetSDK程序集”的異常為客戶端。
客戶端出現異常后，查看異常的詳細信息為”無法進行反序列化”。查資料了解后，應該是Remoting無法對異常、null進行序列化反序列化。
當服務端調用DotNetSDK時，傳入了無效的參數，DotNetSDK會拋出異常，而服務端並沒有對異常進行捕捉，導致異常通過Remoting返回到客戶端，而由於Remoting不能對異常反序列化，所以導致客戶端拋出異常，至於為什么異常的標題是”找不到DotNetSDK程序集”，就不清楚原因了。
找到問題的原因后，給對方的開發人員解釋這屬於Remoting調用的問題，和DotNetSDK無關。但是不清楚對方的開發人員是不了解Remoting調用還是其他原因，他就一口咬定是DotNetSDK出了問題。
沒辦法，我們讓他在服務端調用DotNetSDK的地方加入了try catch，並在catch中將異常信息記錄到日志中。
運行了一次，查看日志，記錄的異常信息為”無效的參數”。
這樣，通過這個日志信息，我們證明了我們的DotNetSDK並沒有問題，而是他的Remoting調用的問題。對方的開發人員總算承認不是DotNetSDK的問題了，這時候給他講Remoting的事情，他才總算稍稍認可。
就是這樣一個事情，我們向領導匯報后，領導把我們批了一頓“你們之所以和對方的開發人員，關系處理的這么緊張、不舒服，就是因為出現問題后，你們總是想證明是別人的錯。加上他這個人是個比較傲氣的人，他可能覺得在他們公司，他是DotNet技術最牛的一個，可是被你們證明他錯了，那么他心里自然不舒服了。時間長了， 次數多了，你們之間的關系自然會緊張了。像這種情況，最好的辦法就是，你能證明自己是清白的，也能間接提高對方的技術水平。”
退而次之，如果做不到上面那點，可以這樣：找到問題原因后，不要說你這個地方的代碼不能這么寫，要改成怎樣怎樣，那個地方的代碼不能那么些，要怎樣怎樣。而是應該說：我也不知道改了什么地方，它就好了。如果對方有心，他自然會比較原來的代碼，你改了什么地方。進而他回去了解你用了什么技術。如果他無心，你想要證明他錯了，那么情況也不會好到什么地方去。
總結
不要證明別人是錯的，只需要證明自己沒有錯。當你證明別人是錯的時候，你就輸了。你贏的了芝麻，卻輸了西瓜；你證明別人錯了，那么也就留下了與人相處關系緊張的問題。
遇到問題，只需證明自己是清白的，同時能間接提高對方的技術水平，那就最好不過了。
這應該是很高的境界了吧，值得吾輩深刻學習。