1. 库表的复杂度，首先取决于需求，不取决于设计，设计能力强的人，也要遵守库表设计的规范，从巴克斯三个范式上，原则上也要遵守。不能说用了Hibernate,自己的库表设计能力就强了。不能为了用Hibernate，就去一味批判复杂的关系不对。复杂的关系设计对不对，首先取决于是否有复杂的需求，其次才取决于设计者的能力。

    2. 只要你用的是关系数据库，就必须要明白，为什么叫关系数据库，而不叫面向对象数据库，把面向对象的那些观点，拿到库表设计上，后期维护和调优上，你要担起责任，不能让开发人员替早期决策人员擦屁股。我见过有的人，打着OO和扩展性的旗号，硬生生的把一个表，拆成了三个表，而这三个表，本来，只需要增加一个类型字段，再做一些冗余，就可以是一个表。现在查询时，还要把这三个表Union到一块来查。当需求变更时，增加一个字段，不仅要改变三个类，还要改变三个表，简直是乱伦。

    3.One-One的库表设计，对于DBA来讲，并不是一个best practice的设计。不能为了Hibernate，刻意把大表拆成小表，再用几个小类，做成One-One的映射关系。整体性，是不能随便的分割，毕竟开发人在调试、测试和维护的时候，更喜欢看数据库里的数据，本来一个SQL，就查出来，现在要到多个表中去查。

    4. 增删改存的实体维护
       Ibatis比不上Hibernate，说实在话，现在让我写SQL来维护一个多对多关系的实体维护，我都要考虑上半天，别说写代码了。

    5. 你需要写原生SQL吗
       首先你要确认，你项目的要求不需要写原生SQL，再来讲Ibatis和Hibernate的好坏，在写原生SQL上，特别是动态生成的SQL，ibatis比Hiberante有得一拼，ibatis就像一个模板一样，将SQL写在配置文件当中，集中配置，特别方便技术领导者监控项目成员写的SQL好坏，而且没有什么学习曲线，就写SQL就完事了。

       有人会说，Hibernate也支持写SQL，但是写代码当中，就失去了原来基于Hibernate的DAO的简洁性。那个DAO一点也不简洁，如果你将动态拼SQL的代码也放在DAO当中，那个DAO就会充斥大量的If 。。Else。。之类的语句，一坨一坨的，非常的壮观。

       还有人会说，Hibernate也支持命名查询，将SQL写在映射文件当中，但是命名查询，只支持占位符固定的情况，也就是说，where a = ? and b = ? and c=?，是三个问号，就是三个问号，传参时，少一个都不行。但是很多项目的查询，都是动态的，也就是说用户选了这个查询条件，才会生成这个占位符的。

       Hibernate办不到。

       还有人会说，我自己用Hibernate写一个框架，也可以做到，那你写的可能比Ibatis好，也可能差，你要造轮子，谁来拦不着。
  

    5. 调优
       早期调优，有些Bad SQL，其实在code review阶段，只要看看Ibatis的SQL配置文件，就可以扼杀掉的，如果使用HSQL，可能不会被发现，因为它不仅隐藏在代码当中，有的时候，还需要程序跑起来，通过日志打印出SQL或者通过其它工具如P6Spy来看的出来。

       后期调优，既然是调优，我想就一定是遇到了瓶颈，可能要在库表上做冗余，可能要检查那些Bad SQL，可能要修改代码，可能要动用DBA层次上的一些调优手段，那么调优越深入，Ibatis的优势就越能体现出来，比如说增加临时表，中间表，增加冗余字段等。

    6. 开发速度
      
       如果项目当中，没有一个Hibernate高手，你的项目又相对的复杂，不仅有复杂的库表关系，还有大量的报表查询，那么使用Hibernate，速度上逊于Ibatis.

       问题在于，怎么样算是一个Hibernate高手，别看论坛上，那么多人，群情激奋的在说Hibernate的好，有谁真的是高手？

       我认识一个人，连Hibernate的命名查询、悲观锁、乐观锁之类的，都不清楚，还在那说：“说Hibernate不好的人，只是他不会用Hibernate，高手使用EJB也一样用的很顺溜“，我这辈子，最最讨厌的就的这样的人，人家明明用Spring很简单，很快乐，为什么要用EJB，充高手。换过来，项目使用Ibatis来做动态查询，很快的就解决问题了，为什么要去学Hibernate里面高深的东东，是不是这样就是高手了？

    7. 平台移植性
       如果你的项目要做产品，而且打算基于多个数据库平台的发布，使用Hiberante是没有说了。

    8. 维护性
       如果不考虑移植性，Ibatis的可维护不差于Hibernate，库表变动引起实体类变动时，HSQL也会有改动，有人说不用改，说这话的那个人可能整天只会有select * ，如果ibatis也是这样写，也不用动了。

       HSQL好阅读吗，From order，确实很简单，但实际当中，这跟拿HelloWord做例子，有什么区别？

     
   
    9. 我在实际项目当中的运用
    项目背景：
       我自己从Hibernate2开始使用，我现在也不认为我是Hibernate高手，我也没有时间去钻研Hibernate，更深的东西，我也不喜欢坐在开发人员旁边老半天，去帮他们解决Hibernate遇到的问题，因为我自己还有很多事要做。

       我的项目当中，在Hibernate方面，还有一个比我更强的人，他也很烦去看Hibernate打印出来的sql，看上老半天，再调上老半天，项目进度，嗖嗖的过去了。

       水平越高的人，任务越重，很少有时间和耐心去解决一般性的问题。

    最终的运用：

       在基于Spring的容器事务管理之下，
       增、删、改、存及在事务中的查询，使用Hibernate。
       非事务性的查询及报表，都用Ibatis，维护非常的直观方便，开发速度上也快很多。

       我觉得现在技术换代很快，使用一项技术，首先是要快速的解决问题，然后要学习他的思想，那些整天死抱着Hibernate，自认为学习到ORM的设计技巧的人，就去继续的学吧。

       我已经会用Hibernate的一些方面，我觉得够用就行了，犯不上，天天钻研HSQL，如果有时间，我觉得躺在草坪上看看Unix的编程艺术，看看代码大全，看看Oracle的编程艺术，比看Hibernate的SB书要惬意多了。

       简单能够带来快乐，用过EJB，再用Spring的人，都有体会，那简直是一种思想上的重生。

       Ibatis的设计者认为，在新的项目当中，可以使用Hibernate，在旧的遗留项目当中，可以使用Ibatis，不明白，他为什么说这样的话，这与新旧项目有什么区别？ 新的项目就真的可以使用Hibernate吗。

        我认为回避代码是可耻的，只要编码有意义，我们在任何阶段，都应当投入到编码当中。

   最近一个项目，我下面有两个设计人员（GM派过来的），协助我做设计，我做了一个设计的骨架，然后交给他们去迭代细化。下班前，我去看看他们的工作只有一些空洞的UML图和一个还没有写内容的概要设计模板，我对他们说，不要求你们去写文档，我也没有时间去看，我不知道你们以前，是怎么做这设计的，但在我这个组，这样做，不行。做为设计者，首先是自己要理解要做的东西，并且真正知道怎么去设计它才能满足涉众需求，第二步，才是让别人能够理解你的设计。怎么样让别人理解你的设计，文档并不是唯一的途径，对于普通程度员来讲，白板上的讲解和直白的代码注释甚至比UML图更容易理解和平易近人，我们很多的设计者，总是喜欢用大量的4＋1 UML图和文档中生硬、冰冷的词汇来吓唬程序员，恰恰反映出了设计者内心的空虚与胆怯。

   以往自身的设计经历，谈一下：
       我第一次给另一个组做一个子模块的设计时，心里很紧张，因为我不在他们那个组中，也不参与他们的开发，这个设计对于他们的项目进度来说，又是一个关键路径，我生怕我自己设计的不好，考虑问题考虑的不周到，在项目后期，如果出现问题，自己责任重大。

       我对他们说，这个设计需要两个星期，其实我只化了三天，就把接口文档写好了，我对着接口考虑来考虑去，还是觉得没有底，我忍不住想写代码，来验证这样做对不对，又怕别人说我的设计能力不强。我就偷偷摸摸的写代码，又和他们的组的主要使用者反复沟通了几次，根据需求，设计了几种不同的案例，来验证我的设计是否有漏洞。

   最后，又对接口修复了几次，觉得接口相对稳定和健壮了，就让他们过来看看，提出问题，结果也没有提出什么问题。于是我就交工了。

   实事上，这个接口，在开发后期，还是有一点修改，但并没有给他们的项目造成很大的影响，他们自己也认为能考虑的这么全面，已经不易。
       做开发这么多年，越来越觉得设计是一个很复杂的东东，他不像建筑工程中的设计一样，可以用工程化的方法去中规中矩的验证，并交给工人进行构造。但如果没有好的验证方法，一个设计就交工了，大家都没底。就好像选择是狮子还是公主，只有把门打开才能知道。

      这几年，我经历的每个项目，几乎都有评审，需求评审，设计评审等等，但我现在回想过来，我想不出对我的项目有太多的意义，很多人痴迷于通过文档和评审来试图证明设计是正确的，而通过评审，对于PM和Architect，似乎也被当做是一个项目当中非常重大的milestone，直到现在，我的上级和我的同事，似乎从未改变。而我的自己观点的表白在OP会上，迎来的是批判。

       我认为文档必须要有，总体的架构设计和模块的详细设计，都是需要的，但是设计者，往往忘记了，文档只是设计者自己对已经构思好的设计的一种反映，这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具，它绝对不是一个证明自己完成一个良好设计的方法。

        编码、测试、调试、交付用户UAT，都应当视为是设计的过程，也应当是验证设计是否正确的最好的办法。

        尽早的进入代码开发，是敏捷开发中一个很重要的标志，所谓的标志，我认为如果在项目前期的前一两个月，你仍然徘徊在需求分析、文档编写的工作当中，而没有代码产生，你绝对不是敏捷。这个观点是我自己加的，我很难容忍，我的设计、分析人员天天在写文档，开发人员在心猿意马的看长遍大论的需求和设计文档。
          一句话，越早进入开发，我就越主动。

   我验证设计的一些方法：
   1.根据以往的设计经验，做一些check list.
   2.写代码，做demo。做Demo是我非常喜欢的一个方法，一个可以运行的Demo，远胜过文档了。开发人员一看，直接copy、paste就完了。做汽车、计算机等新产品，都会有样机，对样机做大量的试验后，才能上线，大批量的生产，在软件当中，怎么一做完设计，就大规模的进行开发了呢。
   3.做测试案例，TDD是一种方法，有长期开发经验的人很容易吸收的思想，并且愿意在重要的地方使用，来理顺和验证自己思路。
   4.对于设计的涉众人员，能够尽早的看到，并充分的沟通，不要把文档写完了，才交给他们，那是一种思想上的强暴。很多时候，在领导的安排下，设计人员与开发人员，在能力上，并差不了多少。所以设计人员要虚心，并且要有责任心。

   好的设计应当交付什么：
   1. 有简洁注释的代码
   2. TestCase
   3. Demo
   4. 模型
   5. 文档

       其实，大家经常解释时说的一句话："我也是就事论事"，但在OP这样比较高层面的会上，还是尽量不要这样搞，就事论事，可以在下面一对一的搞，不要动不动都拿到OP会上搞，得不到别人的协作，要尽量的沟通，不能动不动，就上报给CTO之类的领导，这样会更糟糕。因为CTO可能会不能罩你一辈子。也并不是每个CTO都是清明的领导。

        email有email的用处，但它不是command, 也不是communication, 从你的坐位上站起来，在公司内走一走，要比一个email强万倍。

     4.架构师
       
        架构设计是个很复杂的东东，但如何选择合适的架构师，如何进行最终的决策，很多公司做的并不好，很多领导在架构师的任命上，很容易草率，说你行，你就行，说你不行，你就不行。于是一些不负责的、半桶水的人，就在领导的指示下，走上前台，将项目推向死亡之谷。

        架构的设计依赖你全生命周期项目经验的积累，格局要大，依赖于你对技术的敏感度，技术上比较全面，就像参谋长一样，从军校毕业的，就容易纸上谈兵，比较激进，从士兵，一路杀过来的，就比较慎重，但如果不爱学习上进，则又属于野路子，做又不究其理，不善于抽象，不讲究方法论。

        总之，在这点上，能找一个NB的，又有理性的，不太容易。

     5. 文档
       
         项目组与项目组之间，项目组与客户，项目组与测试部门，项目组与评审组之间的交互，有很重要的部分就是文档。

         文档这个东东，说实在话，就是一个鸡肋，但不要又不行，客户要签字，领导要评审，测试组要拿它写测试用例，但对于项目组来说，天天在那咬文嚼字的，实在是没有意义的，俺在原型分析与用例驱动上探索了很长时间，虽然用例直接了当，且很容易转化成功能书、测试用例，但工作量，比之传统的需求文档说明书，有过之而无不及，在时间紧的时候，也很难保持实时一致。

        我目前的做法是原型必须与客户的需求保持一致，基于静态页面的原型，修改起来，速度很快，且更容易被客户、程度员、设计者所接收，长篇大论，动不动上百页的需求文档，你喊破喉咙，也没有人看。

       文档，有专人写，专人维护，但会比较滞后，只要能够保证在提交测试部门时，有一份完整的文档，这样测试部门，也更方便测试。培训的时间也少。

        在评审时，可以评审，但具体文档要拖一拖了。

        客户签字，就以原型为主了。文档，它也不看。如果动真格，要看，那就抽时间赶出来。

        当然对于接口等技术文档，还是必须要的。

         (未完待续)
      
    

　　面试考官来了以后，故做认真的看了看，并让我讲了讲整个思路，讲完后，突然问我，你能不能不用工作流的思路，来写这个案例，我说那很简单，如果不用工作流，流程数据就要保存在业务层中或与业务层紧密的耦合在一起，流程的跳转就要写死，但这样做很难去适应业务流程的变化与功能扩展需求。如果不想写死，就得走可配置的道路，同样也必然回归到工作流思想上。
　　他反问我，但那样做，是不是更快一点，性能上要好点呢，我说，工作流引擎的开发上可能会花点时间，但如果一旦开发完成或者采用第三方包的话，那么业务层的开发将会非常的快，通过简单的配置和表单定义及描述层的开发，就会很快的完成工作。
　　他却说你这套代码写的很好，但如果技术水平不高的程序员，他们没有工作流思想, 看到我写的这些代码，会看不懂。而如果使用常规的做法，不使用工作流，那些人就能很快的接受并能很快实现这个需求。
　　我当时很恼火，但仍然耐着性子说，如果从单纯从实现速度上，确实要很快，但后面维护的代价是很沉重的，而我基于工作流的设计，根本不需要他们看懂，工作流引擎对于他们就是一个黑匣子，完全通过灵活的配置和接口调用来完成工作，为什么一定要看内部的代码实现呢，再说即使没有工作流思想，通过简单的培训，相信也可以使用的。我心里想，为什么要招这么蠢的程序员呢？
　　但他仍然很固执的说服我，我也不想再纠缠下去，就同意了他的看法，心里已打定注意了。谁知那个SB竟然对我说，你回去后，按我刚才的说法再完整的写一份的设计发给我，我听了这句话，心里真有点怀疑，他是不是在诈骗，让我免费替他写程序。
　　我口头答应下来，然后头也不回的走了，由于走的快，鞋子里的水与脚摩擦，发出噗嗤噗嗤的声音，很是狼狈，前台小姐捂着嘴偷笑。
　　闷了４个小时，出了写字楼，有点头晕目眩的感觉，心情很不好。自己每天不断的学习，不断的鼓励自己要踏实上进，回报却是这么的不公平。

　　我这一生经历过的比较厌恶的面试经历：
　　1、给一张破纸，让写一个算法，草纸都没有（就像让人蹲在光滑干洁的地板上拉屎一样，巨痛苦）
    2、让写足足有四张的个人信息登记表，里面还要写家庭关系。就像唐僧问山妖，你妈贵姓？
　　3、排队面试，在会议室里，等了有４０多分钟
    4、做SUN公司Java程序员认证的考题，里面还有SWING，AWT，Applet之类的题目
　　5、与一个考官讨论接口与抽象类的差别，争论了一个下午，巨傻
        6、每次都被问为什么离职
        7、进度控制和需求分析，都是很有挑战性的，但问的多了，也就想吐了。
       8、做名词解释题，SCM，TDD，XP，这些都见过，还好说，竟然有SWOT，有点过份，也算说的过去，还有一些至今都GOOGLE不到的缩写，因为不会，现在都忘记了。不明白人为什么要耍酷，装什么装，谁不知道谁呀。
　　9、经过三面、四面后，音讯全无
　　

　　这几天太累了，不想再出去找工作了，努力让自己的心态平稳下来，时间是最宝贵的，不能再东奔西跑的了，以后再有面试的邀请，不再刻意的去准备了，爱咋咋地，同时一定要讲明：
　　不再盲目的屁颠屁颠的去面试了，要求对方先有同技术负责人的一个电话面试，在电话中讲明自己的缺点或者弱点及长处，如对方说要熟悉JMS，而自己就没有做JMS的项目，但对于底层的TCPIP协议通信，还是很了解的，SOCKET通信更是不在话下，相信对于JMS，应当很容易掌握。
　　
       

先说一下JDK 对List的随机排序的实现：

public static void shuffle(List list, Random rnd) {　　　　
    　　final int SHUFFLE_THRESHOLD        =    5;　　//这应当是一个经验值吧

        int size = list.size();
　　/** 为什么要判断，后面有论述 */
        if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
            for (int i=size; i>1; i--)
                swap(list, i-1, rnd.nextInt(i));  //这一种方法是直接调用List.set方法，属于RandomAccess中的方法
        } else {
            Object arr[] = list.toArray();

            // Shuffle array
            for (int i=size; i>1; i--)
                swap(arr, i-1, rnd.nextInt(i));

            // Dump array back into list
            ListIterator it = list.listIterator();      //如果不是Random Access实现，就使用迭代器遍历
            for (int i=0; i<arr.length; i++) {
                it.next();
                it.set(arr[i]);
            }
        }
    }

再说一下我自己的笨拙实现：
　　public static List randomSortList(List ls, Random random) {
                List randomList = new ArrayList();               
                int size = list.size();
               while (size > 0) {
                  int randomNum = random.nextInt(size);
                  randomList.add(ls.get(randomNum));
                  ls.remove(randomNum); //这一步，对于RandomAccess的集合来说，是O(1)操作
               }
               return randomList;
     }
评述：
　　如果List的实现是ArrayList，在时间效率上要多循环一次，但在空间上，我的方法非常差，多生成一个List集合，如果List很大，就更差了。同时我的算法如果用于Sequence List上，效率是相当的差，只能适合ArrayList,有很大的局限性。
　　这是因为： 如果集合类是RandomAccess的实现，则尽量用for(int i = 0; i < size; i++) 来遍历而不要用Iterator迭代器来遍历，在效率上要差一些。反过来，如果List是Sequence List，则最好用迭代器来进行迭代。
　　JDK中说的很清楚，在对List特别是Huge size的List的遍历算法中，要尽量来判断是属于RandomAccess(如ArrayList)还是Sequence List (如LinkedList），因为适合RandomAccess List的遍历算法，用在Sequence List上就差别很大，常用的作法就是：
    要作一个判断：
    if (list instance of RandomAccess) {
        for(int m = 0; m < list.size(); m++){}
    }else{
        Iterator iter = list.iterator();
        while(iter.hasNext()){}
    }
   我的项目中List都是基于ArrayList的，所以基本上很少用迭代器来遍历，而是用for循环来遍历，对于迭代器的作用我当然很清楚，但是我觉得有点庸人自扰了。
   除非你经常用Collection作为你的接口方法中的输入或输出的集合参数类型时，你也就只能用Iterator。
   但我一般在接口方法中，一般用List，所以我就不用迭代器，除非我的List是Linked List实例。
   好的作法是：在供外部调用的接口方法中，使用Collection作为集合参数类型，在内部实现当中，使用List，而不是一味的使用Collections及Iterator，这样做无异于作茧自缚。
   顺便说一下JDK中推荐的是对List集合尽量要实现RandomAccess接口。