【MVC,MVC2,WEB设计编程的分层】
请阅读文章 http://forum.javaeye.com/viewtopic.php?t=11712&postdays=0&postorder=asc&start=0
【可扩展不等于功能强大,不要夸大其辞】
现在的系统,因为接口或者其他方法的使用,都具有很大的扩展性.但是扩展性不等于功能强大.
存在一个接口,用户可以实现自己的接口,确实非常方便.但是如果你的系统本身只实现了一个接口或者根本没有实现,那么对用户来说就谈不上方便.
例如WebWork的validators,本身是一个接口,但是实际上本身实现的具体类很少,而且功能很差,这个时候如果你说WebWork的校验器很厉害,那么就可能不太恰当了.当然扩展Webwork的Validator还是非常方便的.
当然,可扩展性还是需要的,但是不要吹嘘,在这个浮躁的年代,让我们多干点实事. :)
【20/80原则】
在工作中,我经常想到20/80原则,也就是"巴雷多原则".例如我们可以看到:
时间：我们20%的时间会产生成果的80%
产品：产品的20%带来利润的80%
阅读：20%的书篇幅包括了内容的80%
工作：20%的工作给我们80%的满意
演讲：20%的演讲产生影响的80%
领导：20%的人作出80%的决定
从上面可以看出,很多时候它都很有说服力.
在这里我想提到几点,但是和上面的可能出发点有所不同:
1.程序的80%都是在处理特殊情况,所以我们一定要对特殊情况重视,不要因为是特殊情况,就不很重视.80%的客户对特殊情况都很重视.
文档对特殊情况也要详细描述,因为开发人员80%的时候在查找这些东西,而对那些经常用到的用法却很少查阅文档.
2.优化问题:80%的瓶颈都出在20%的代码上,所以在优化代码的时候不需要优化所有代码,只需要优化20%的关键代码就够了.当然追求完美的人我们就不多说了.
记得有一条优化的原则是"不要优化!不要优化",是非常有道理的.
3.如果你20%的事情做砸了,往往会导致80%的事情都砸了,或者是导致别人认为你把事情几乎都做砸了.
如果你对一些事情发表了一些很不严谨的看法,那么别人会认为你在别的事情上也很不严谨.
依此类推,代码质量,文档完整性等等,都会让人产生类似的推理.
(当然一个代码写的很乱的人,往往文档也很乱.)
【强制绑定是不受欢迎的】
不要在程序中强制绑定一些额外的功能.
有的框架往往功能很多,是"大型计算机",有很多功能,但是在我需要打字的时候,给我打字的功能即可,不要强制我使用网络功能,打印功能,负载均衡功能等等.
一般来说,如果一个东西有很多功能,那么做好做成可配置,可插拔的,这样用户使用你的东西,没必要在不使用高级功能的时候,浪费用户的内存,磁盘.开发人员还得多copy好多lib文件,占用调试时间,岂不是很麻烦.
不要买一送一,我不想要就别给我. :)
【有时候也得考虑兼容性】
一般来说,一个公司的客户会有很多,用户的运行环境是各种各样的.jdk1.3,jdk1.4甚至还有jdk1.2.这样我们在编程的时候就必须做一些妥协,有些函数库就不能使用.
如果这些用户的jdk不能升级(一般来说都需要购买新的产品才能升级),或者我们必须对这些情况妥协,那么我们就要在开发中考虑这些问题.
例如以前,在Servlet 2.2的时候,因为没有setCharacterEncoding,我们必须手动对各种字符进行转换.当Servlet2.3的时候,可以使用这个函数了.但是为了客户考虑,我们只好没有升级还是使用原来的方法.(当然后来大多数用户都使用了新的App Server,我们就可以使用filter来处理编码问题了).
向下兼容性确实让人头疼,JDK1.5也发布好久了,不过我们现在也不能使用,只能自己没事测试测试.
在编程的时候,一定要设置好IDE的兼容性设置,防止我们使用了不能使用的特性.Jbuilder,Eclipse都有类似的设置.
【成本与现实,给用户以选择余地】
全文检索,lucene,like是三种对大文本字段检索的方法.那么你采用哪一种呢?
也许你会毫不犹豫的说"全文检索" (我看你像TRS公司的托 :P).
正如"强制绑定是不受欢迎的"里面所说的一样,我还是觉得应该给用户以选择的余地.
全文检索是要花钱的或者需要配置,而且一般来说数据库专用的全文检索都是不通用的,lucene是需要开发人员开发的,只有like最简单了,但是太简单了,而且性能也差.
这个时候,也许我们就应该提供几种方式供用户选择了,用户如何选择那就看他们了...
【结束语】
实际开发设计中肯定还存在很多其他的问题,本文不可能一一论述.到此为止. :)
希望各位在开发设计中成为高水平的设计师. :)
扫一扫
1348
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
