Don’t Cut Yourself: Code Optimization as a Double-Edged Sword。中文翻译：过早优化是万恶之源。
代码优化的好处多多，但是这并不意味着所有的代码都需要进行优化，有时过度的优化反而适得其反——费时、费力、不讨好。
“现代计算机科学的鼻祖”Donald Knuth曾说过“过早的优化是万恶之源”，因为：让正确的程序更快，要比让快速的程序正确容易得多。文中讲了7个原则，简单罗列如下：
1. 究竟要优化什么？
2. 选择一个正确的优化指标
3. 优化在刀刃上
4. 优化层次越高越好
5. 不要过早优化
6. 依赖性能分析，而不是直觉
7. 优化不是万金油
更详细的大家可以看英文： http://blog.smartbear.com/programming/dont-cut-yourself-code-optimization-as-a-double-edged-sword/
为什么把这个话题拿出来讨论下，因为我现实中发现过早优化，其实是一个非常容易犯的错误。举几个例子：
1、数据库优化中，为了性能优化，放弃通用性，把SQL全部用C语言重写，这种技术是不可能得到发展的。
2、Hadoop领域里面，Tez/stringer为了解决hive性能，只是将M/R通过DAG作业来替代，将多个作业用一个作业来替代，减少中间过程。但是实际上hive用在查询上，除了M/R效率底下外，还有进程启动代价太高，以及最主要的是数据存储不是专门为分析场景准备的。所以我预计如果Tez/stringer只是按照目前的思路优化，最后肯定昙花一现。
3、Shark，hive on spark。简单的将hive拿到spark上来，从最新资料来看，DataBricks 已经被放弃了shark，转而将重心放到 Spark sql上面来。
不要为了优化而优化，优化应该先做好顶层设计，再落地到具体的技术细节，否则优化出来的东西，不会有长久的生命力。
