“不要重复发明轮子”，很多开发者在新入行不久，就经常会被这样叮嘱：这个世界上程序员已经太多，遇到的问题已经够多，而解决方案层出不穷。你走过的路，跳下的坑，已经有无数的先驱在你之前路过，跳过。
所以在做技术选择的很多时候，你不需要自己从头去实现一个东西，就可以在现实世界中找到现成的趁手的利器，小到一个类库，工具，大到一个框架，平台，来满足自己的“需求”。你以为你看到了绝美的风景，后面是一马平川。
而这，只是不愿意拒绝懒惰和诱惑的借口，背后很可能面临更多的困难，陷入其中不得自拔。
开发者在技术选型的过程中，很容易对已有的神往已久的某个技术或者工具情有独钟。
“什么都是现成的，直接拿来用（一套）就好了！”
而往往忽略了它们在后期定制化需求，或者弹性及扩展方面对自己可能存在的限制。下面看两个例子。
关于构建工具的例子
比如Maven在Java的世界里很长时间都是主要的自动化构建工具，它的插件化结构，提供的很多现成的archetype和插件，以及命令行和插件化扩展的可能让很多程序员眼前一亮。
而随着手头的项目变得愈加复杂的时候，你会发现Maven的XML声明式结构和插件化，恰恰是阻碍自身伴随项目复杂度进化的绊脚石，因为它缺乏灵活性，以及对于自动化测试实践的支持，尤其在持续交付方面。
而Ant有同样的问题，我们不断发现团队在不可维护的Ant和Nant构建脚本上耗费了巨大的精力。由于工具自身与生俱来缺少的表现力以及清晰的模块性，这些脚本难以理解和扩展。
XML配置文件中太多让人觉得多余的尖括号，以及粗糙的插件架构。虽然语法问题可以通过升级换代来解决，但插件化架构严重限制了构建工具随着项目变得愈加复杂自我优雅进化的能力。我们发觉插件的抽象层次是错误的，相反我们更青睐基于语言的工具，比如Gradle和Rake，因为提供了细粒度的抽象，以及更多的灵活性。
Gradle是一个把理智带入企业级构建世界的尝试，它把划时代的技术和最佳工具组合相结合。Gradle可以让你访问你已有的Maven仓库，但通过清晰的领域特定语言为你的构建添加脚本功能。
相对于像Ant和Maven这样基于XML和插件的构建工具，像Gradle和Rake这种基于语言的构建工具，在持续提供细粒度的抽象和更多的灵活性。这样它们就能伴随项目变得越来越复杂而随机优雅地应对。
关于前端可视化框架的例子
另外一个例子是关于前端（可视化）框架的选择上，一些提供了丰富UI渲染样式的框架库很是夺人眼球，漂亮的表格和图表样式，简单的Demo示例代码，让开发人员都以为这是实现当下棘手UI需求的不二法宝，可以极大地提高开发的效率。
比如ExtJS，开发人员在经历了初期的甜蜜之后，会发现他们很难控制Ext渲染出的HTML和DOM，而编写功能测试代码看起来也不太可能，尤其是当对UI的外观和样式有个性化的定制变化需求时，会显得一筹莫展。
Ext会把你限制在它的UI实现思想框框里面，这样也许可以在那些不需要投资UX的团队里面工作得很好。
Highcharts是个另外一个例子，丰富的图表类型，以及基于提供的图表类型的定制化功能，优异的JavaScript引擎，对HTML内嵌SVG文档的支持，一度是我们在项目中选择前端图表展现库的不二选择：
但随着对图表渲染的个性化UX定制需求的加入，我们会发现Highcharts通过公开API提供的很多灵活性，比如对于X轴、Y轴和渲染细节的定制，已经很难满足我们对更多图表本身的修改，和添加新的样式。
而这时候，如果不是让UX设计迁就Hightcharts既有的实现，也许更好的选择是D3，虽然它会在开始显得底层，需要团队更多的精力来创建通用的不那么复杂的可视化元素，但这也意味着更多的灵活性，加上它的插件模型，以及像Rickshaw和Crossfilter这样的库支持，会让D3比以前更具亲和性。
最后
所以对于技术的官方网站提供的所见即所得的特性展示，简单的示例代码，和想当然的心满意足，开发者需要在接受诱惑的同时，多考虑一些在技术投资后可能存在的风险，以及是否有足够的支持。
需要考量的因素和角度可能但不限于：
- 文档和社区支持的成熟度
- 复杂的代码示例
- 可能的功能性需求变化
- UI呈现上可能的需求变化
- 性能，安全等非功能性需求
- 团队知识和学习能力
- 后期的维护成本
需要针对这些因素，做一一的评估和侦测，才能最大限度地保护成本的投入。
有的时候，你真的需要重复发明轮子。
