最近在做documentum相關的項目，docoumentum作為一個內容管理平臺，本身提供了很多功能，但它有提供了一些API讓你做一些定制化。我們team里面沒有docuemntum的專家，這方面網上的資料也比較少，所有的東西都是靠我們自己一點點摸索出來的。最近我們摸索出來怎么利用documentum提供的API來實現功能。按道理這是一件好事，但矛盾出來了，面對一個功能，你是先去找相關資料看看documentum是否提供這樣的功能，然后研究怎么來配置，還是直接寫方法自己實現呢？很多team member更傾向于后者，原因是：
1，寫代碼更靈活，更自由。
2，這功能并不復雜，自己寫花不了多少時間。
3，研究documentum是否有這功能，并且配置它也需花不少時間，因為資料比較少。

公司的architect認為，寫代碼永遠是最后的選擇，如果documentum有這樣的功能，就要用它，不應該自己去實現，他認為documentum這么強大的平臺我們沒有必要去寫代碼，基本上通過配置就能搞定（這點我倒是不敢茍同，我不覺得documentum提供的功能夠豐富）。特別是他聽說了我們反編譯docuemntum的開發庫來研究它的實現時，他覺得我們走錯方向了，我們應該把精力花在了解documentum提供的功能上，而不是花時間去研究它的實現。其實我們也是迫于無奈，介紹documentum開發的資料實在太少了。

但我覺得architect說的還是有道理的，我們永遠要避免‘開發輪子’。今天有個team member跟我討論這個事情，他也說道理是對的，但明明我可以自己實現的東西，卻老是要去research一把，確認docuemntum不能提供這功能，才自己去寫，是不是太累人了。

這讓我想到做事的方式問題，其實無論做什么事，都是有一定的pattern在里面，像project management, PMI有一套規范，development，也有很好的pattern，像TDD。這些pattern都是前人經驗的總結，如果我們堅持按照pattern來做，成功的幾率肯定高。但我們往往圖一時之便利而放棄了這些pattern，結果卻浪費了更多的時間。比如TDD，很多人都覺得好，但真正這樣做的人卻很少，原因很多，像時間緊啊，比較麻煩啊。結果呢，表面上確實開發快了。但更多的時間花在defect fixing了。