最近在看Robert C.Martin的《敏捷软件开发 原则、模式与实践》。打算7月把这本书看完。早就该看这本书了。看他的这本书，就像看小说。大师之所以为大师，在于他的经验和文笔。他的文字和代码有种美感。我觉得投身软件行业的好处之一是：这一行有很多受人尊敬的公认的大师。要追随他们的脚步，决不把自己搞成一个苦什么的程序员。

    刚看完NULL Object模式，印象比较深刻。几年前，刚开始开发时，遇到最多的就是NullPointerException。当时感觉这个是很麻烦的常见异常。我问同事怎样避免这个异常，有人跟我说在调用一个对象的函数之前先判断一下对象是否为null. 之后我的代码几乎就布满了类似的代码：

if （obj !=null）{

...

}.

如果要遍历List,我习惯这样写：

 if( list != null && list.size()>0){

      for(ClassName one:list ){

       ...

   }

}

后来看到《Effective java》中说，“返回零长度的数组或者集合，而不是null”。我记住了。如果函数返回值为List，通常，函数体中第一条语句我就new 一个ArrayList。尽管我觉得直接返回一个null比new 一个ArrayList的代价要小得多，但我还是听从大师的建议，为了让代码好看一点。

现在又学了一招，如果用上NULL Object模式， 代码中不会出现 if （obj !=null）这样的代码了。

再讲一个故事。本周五项目经理把神州数码的数据库大牛都请来了。原因是一个统计页面在生产环境慢得出奇，将近一分钟才出来。客户没有等一分钟的耐心，他认为点击菜单之后就没有反应了。

这个统计页面是我做的。大牛要来，我还是有点担心我的sql语句是不是有问题。大牛来了，分析了一会儿，要我解释sql语句为什么要那样写，我自己写的，还是说得出来。最后大牛的结论是：在数据库层面没有办法优化。我稍微松了一口气。

那怎么办呢？还是有办法。在业务层面，如果其他单位把某个字段值传过来，用新的sql语句，生产环境，只需0.6秒。问题是现在要把那个字段值传过来，好像有困难，具体原因不是我关心的。我关心的是：在给我的东西的基础上，把该做的事情做好。即使出了问题，查下来也不是我的问题。

结论：不要把希望寄托在数据库身上。在业务层面考虑周全，尽量减轻数据库的负担，出问题了再搞数据库优化，希望渺茫。