给JAVA设计研发新手一些建议和意见(1)

　　　　为了给朋友同事一些设计问题上的指导，特撰写此文，非常多观点都是从别人的文章中获取，有些观点肯定也有偏颇，有些观点也仅仅是提出并没有做周详论述，请多拍砖，以便改正。　　【概述】　　在工作中，作为一个程式员或一个设计师，总是要设计一些函数库或一个框架，当然最经常的还是做项目，即使是个项目，也会被经常改动，甚至交给别人改动。　　当你做这些工作的时候，你的这些成果都是要给别人了解使用的，或说给以后的你使用的，为了别人的方便或为了自己的方便，我们要尽可能做好设计。　　【放正心态，所有东西都是不断发展的】　　技术是日新月异的，每一天都有新的技术出来，正所谓"山外有山，人外有人"，每一个新的轮子出来，都可能比你要设计的轮子好，所以在设计的时候，应该了解一下是否已有了类似的轮子，是否要设计一个新的轮子。　　即使你的轮子已设计好了，也不好认为自己的轮子一定比别人的轮子好，虽然你的轮子可能更适合你的实际使用。　　技术在不断的发展中，你及你的朋友/同事都在不断进步，"士别三日，当刮目相看"，所以不要认为你的水平一定比别人高，"尺有所短，寸有所长"，所以别人对你的函数库/框架提出意见，提出疑问的时候，请不要惊奇，不要反感，不要认为别人在"挑刺"，也许你的函数库/框架早就不适合当前的发展了。　　态度决定一切。你的领导或许更重视这一点。　　【必要的组成部分:单元测试，文件，实例，手册etc】　　单元测试，文件，API Doc，手册，演示程式，Change Log，Readme，build。xml等等　　有一天别人使用了你设计的函数库/框架，当你升级后，原来的项目却不能工作了，经过一天的调试，你终于找到了原因，原来是不小心写错了一个东西。　　你肯定不希望上述的事情发生，那么请你写单元测试吧，这样既不浪费自己的时间，也不耽误别人的工作，何乐而不为。你花在写单元测试的时间/带来的乐趣和你升级后改正莫名其妙的错误的时间和苦恼相比，肯定更有价值。你看到单元测试的绿条，难道不感到高兴吗?!　　如果你不能确保你的程式修改没有错误，不要指望你的同事认为你的错误是能容忍的，他们在心里早就开始骂你了，呵呵。写单元测试吧　　看看所有一个知名的框架，都包含完善的文件，单元测试，示例程式，用户手册，那么请你也包含这些吧。哦，对了，请周详地写好JavaDoc，他非常重要。　　使用你的框架/函数库的人如果到处去找使用方法，去找某个类(不过他不知道是否有这个类)，那么说明你的文件没有到位。如果你希望别人使用你的这个类或功能，那么请写好文件，不要指望别人去读你的源码然后就能理解他是干什么用的。　　如果你做到这些，那么你的函数库/框架也有了"知名"的前提，难道不是吗?如果没有，我想是没法让别人更好地使用的。　　对了，有了这些东西，还要有一个良好的目录组织，这个也能参考别的框架的组织方式。　　【借鉴成熟的设计，参考已有的项目】　　1.要做一个新的东西，没有想法。不要惊讶，我肯定先找一个现有的东西来借鉴。　　当然前提是不要重新发明轮子，或是你有充分条件要重新发明一个轮子。　　Struts，WebWork，Spring等等都是成熟的框架，不管你使用起来是否符合你的习惯。　　在你成为大师之前，你的设计思想估计前人都已提出并实践过了，所以要勇敢地去借鉴。"站在巨人的肩膀上"我们能更近一步。　　例如我们厌倦了在访问数据库时使用如下的代码:　　try　　{　　//your code here　　}　　catch(Exception e)　　{　　//catch Exception　　}　　finally　　{　　//must do something　　}　　我们就能借鉴Spring框架的JdbcTemplate类，看看他是怎么利用回调函数来处理的。　　我们使用hibernate时是不是也会使用类似上面的代码，那么能参考Spring框架的HibernateTemplate。　　借鉴也是一种捷径。　　警告:借鉴但不要抄袭，借鉴代码要注明来源，尊重他人也是尊重自己。　　2.在实际的项目中，往往能参考已有的项目来做自己的设计。　　例如做一个网站，我不知道怎么访问数据库，怎么布局，怎么分层，那么我们能参考已有的网站程式，看看别人是怎么利用SiteMesh或tiles布局，怎么使用Hibernate来访问数据库或使用已封装好的JDBC类来访问数据库，怎么利用Struts，WebWork或其他访问来分层。　　【遵守约定俗成的一些做法】　　为了使别人更方便地使用你的东西，那么在设计一些通用的函数或类的时候，请遵守通用的做法，不要和众不同，除非你的内部实现确实和众不同。　　例如实现一个类似ArrayList的类，那么请不要这样写:　　public int count()　　{　　return list。size();　　}　　public Item getItem(int i)　　{　　return list。get(i);　　}　　而应该这样:　　public int size()　　{　　return list。size();　　}　　public Item get(int i)　　{　　return list。get(i);　　}　　当然每个人都有自己的想法，如果你非常认为你原来的方式比普通的好，那么请提供2套方式供别人选择。他不会给你带来麻烦，只是个一看就懂的做法，不用怀疑，这样做有好处。　　非常多类的设计都有一些约定俗成的做法，那么在你设计一个新类的时候，先借鉴一下吧，多看看JDK的源码/文件，看看别人是怎么实现的。这更有助于推广你的成果。　　【不要迷信权威】　　在使用已有的框架或函数库时，不要认为所有的东西都是正确的或是最佳的最佳，肯定不是。没有完美的东西，已存在的东西在设计的时候因为种种局限或因为作者的水平，对目前来说肯定存在不合理的设计，或过于最佳化的设计，而不能满足实际情况。　　不迷信权威，才能到达新的境界。　　【不要轻易排斥，不了解就不要草率发表意见，要严谨】　　在网上经常看到。Net和Java的比较/火拼，或是Struts VS Webwork或是其他等等，非常之多。经常看到的是一方对对方的东西不甚了解，就开始批评，结果说不到点子上，反而被嘲笑一番。　　几种技术的比较有时候是必要的，例如技术选型的时候。不过如果一些对这些技术根本不了解的人来选型，来评判，你能对结果信服吗?　　存在就是合理，所有技术都有其存在的理由，虽然有些东西早就过时了，不过在当时他也是应运而生的。　　几种技术，都是来解决同样的问题，不过问题也有非常多方面，解决方式也有非常多种，每个人的想法也都不相同，思路也不相同，所以没有绝对符合需求的技术，不过应该有符合你的技术，不符合你的技术不等于也不满足别人的需求。所以不要轻易排斥别的东西。　　在做技术比较的时候，如果你不了解，那么请不要轻易发表意见，至少你能亲自去了解，去实践之后在发表你的意见岂不是更好。　　在发表意见的时候，也要严谨，不要轻易下结论，要经过求证，否则一旦错误只会让对手笑话，让你的同事看不起你。例如你说Hibernate3不支持jdk1。3，那么最佳去好好找到你的证据，否则就会成为错误。(Hibernate3支持jdk1。3)　　作为一个技术人员，严谨应该是我们的习惯之一，无论做研发还是做设计。