噢，等等，先想想再說
最近我和同事犯了幾個錯誤，那位同事所犯的錯誤也正是我以前常犯的。說是錯誤或許有些嚴重，但至少這種做法不是那麼正確吧。相信很多人都有類似的毛病，寫到這裡，希望大家引以為戒。 1.
完成了嗎？再想想，有遺漏沒？前幾天解決了乙個關於setlocale的問題，那是乙個遺留很久的問題，以前不知道如何在遠端除錯時在共享庫里設定斷點。因些除錯非常困難，只能靠printf，而setlocale的實現又很複雜，所以後來這事就擱下了。現在已經如何遠端除錯共享庫了，只花了一天多時間就解決了。我測試過setlocale，確認沒有問題，自以為萬事大吉了。
今天發現iconv轉換字元編碼還是失敗，只好重新去看glibc的**。和同事花了半天才查明，原來是沒有把gconv下的動態庫拷貝到小機上。上次雖然解決了主要問題，仍然留了個小漏洞，為此我心裡耿耿於懷。解決setlocale之後，本來我應該再測試一下iconv的，如果當時發現問題，有現存的除錯環境，很快就可以查出來。
前段時間看了一下《如何求解問題》，這是一本非常好的書。由於比較忙，只是粗略的翻了一下，有時間一定仔細閱讀。其中有一句話給我留下了深刻的印象，大意是說，一旦找到問題的乙個解，千萬不要輕易放棄。繼續思考！看看是否真正找到了所有的解，或者是否有更好的解。如果你馬上放棄的話，就可能永遠不知道這些解了。
2.走捷徑了嗎？再想想，有***沒？同事遇到乙個問題，在daemon裡呼叫乙個初始化函式，程序就停在這個函式裡不出來了，而正常呼叫時沒有任何問題。同事比較聰明，但缺少經驗，他把這個函式挪了下位置，放到fork之前去調，一切正常了。今天我發現，把**移到fork之前，移動距離不遠，但設計發生了本質性的變化了：這個函式從外掛程式裡移到框架裡，位置雖然不遠，邏輯關係完全變了，這使得框架**依賴於外掛程式**，兩者緊密耦合，失去了外掛程式式設計的意義。我建議他先找到問題真正原因，再決定如何修改。
走捷徑即是通過轉換面臨的問題，簡化求解問題的方法。這本來沒有錯，特別是作為臨時解決方案非常有效。但在需要長期維護的專案中，權宜之計通常得不償失。因為問題雖然表面上解決了，但問題的實質被掩蓋了(我們甚至不知道問題的實質是什麼)，而且捷徑本身也可能有些***，從長遠來看，走捷徑引發的問題比較解決的問題更多。
如果你用乙個巧妙的方法解決了乙個難題，在沾沾自喜之後，冷靜一下，看看這個方法是不是真的很巧妙。就花一點點時間，有益無害。 3.
要重新發明輪子？再想想，有必要沒？同事說他在寫乙個helper launcher，我問他為什麼不用scim自帶的helper launcher。他說scim太複雜，使用它自帶的可能要花更多時間，所以就自己寫了。我以前也是這樣，有些**太複雜，我寧願自己寫，也不願去把它們研究清楚，然後重用它們。
重新發明輪子，雖然一時暢快了，但從長遠來看，通常要付出更大的代價。原因在於： l
新寫的程式要花更多的時間去測試，才能達到原來**的穩定性。 l
新寫的**要與環境吻合，要經過很長的磨合期。在這段時間，你會很多因素你都沒有考慮到。 l
新寫的**，從功能上講是重複的，維護重複的**是一件痛苦而且容易出錯的事情。 l
或許還違反了某些規則…
在有重新發明輪子的衝動時，先冷靜一下，仔細想想，是否真有必要，原先的**是否真的無可救藥，你是否準備好應付重新發明輪子帶來的種種後果。
~~end~~