最近在做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了。