本来是在zhangxin09博客中对 EXTJS与后台（J2EE）实战开发经验与心得总结 的留言，早上看到没有显示完整，在自己的博客中发个全文。
主要是针对原文中的6个问题说下自己的看法，同意原作者的观点，只是做一点补充，希望能给使用extjs的朋友一点参考
1.前期不够投入 2.对API的不了解，以及资料匮乏。 3.不相信自己的能力，过度依赖百度和Google 4.前台与后台的那些纠纷 5.页面逻辑与后台逻辑分不清 6.JS的调试
我从ExtJS1.0用到2.x版，看着她的功能在一点点强大。到现在不写程序有一年多了，看到上面的贴子还是忍不住回个
对于 andy_ghg写的6点，有点小感触
1.前期不够投入
ExtJS是一个很优雅的框架，在认真学习之前没发现js可以写得如此漂亮。很多功能的实现都让人眼前一亮，不禁感叹作者的想像力！不讨论js是否是面向对像与否，我也分辨不清，呵呵。不过OO的思想不是依赖于语言的，有人一样可以用C来实现OO的。
像JS这种语言，需要programer有良好的基础素质。首先需要的是规范，我在做一个网络监控前台的项目时，项目组还不熟悉extjs，但是他们以前的代码是没有缩进的。能想像得到吗！一个上千行的js脚本，除了自己没人能够（有耐心）看完而且看得懂。最后我强制要求他们按我的代码模板进行开发，才勉强能够看。但一不小心，就会发现以前的坏习惯，堆叠代码。
js太灵活了，如果程序员的规范不好，习惯不好，能给项目带来灾难。比如以可加载一个脚本覆盖之前脚本中的变量；由于“逗号”的原因不能在ie中运行（这个做extjs开发的应该都会遇到）。从这个角度来看，也可以说是js的缺点，缺少发现错误的机制。
用得时间长了，就会感叹js的魅力，代码可以写得如此优美，同时感叹着也可以写得如此得糟糕！哈哈！
2.对API不了解，以及资料匮乏
extjs是一个框架，像windows MVC框架一样，需要学习，并不是一个拿就可以使用的东西。学习是一个过程，是否需要学习要自己判断，建议多看看demo程序。里面的例子很好，也比较全，我在学习的时候，基本上没有中文资料，全靠API和DEMO参考。
使用框架这种东西是需要思考的，需要解理作者的设计意图，然后再使用起来就方便很多。一味的按自己的想法做，相信也能实现，但走了野路子。代码不好看，也没有通用性
3.不相信自己的能力，过度依赖百度和Google
这个说不好，能运行还管什么google啊！爱信不信！
4.前台与后台的那些纠纷
5.页面逻辑与后台逻辑分不清
本来是按4回复的，写完发现4和5可以放在一起写。是我的思维混乱，原作者划分的比较准确，不过我也懒得再改了。
前后台的事比较闹心！特别是出现rich client之后，前后台的分界线并不是很清晰。前台如果只管表示，也不至于rich起来，简单的处理也没必要非从后台走一遍。
在没有rich client的时候，后台的输出就是view，所有请求都会发送到后台。但随着rich client的出现，后台的输出已经不再纯粹--有表示也有逻辑。后台代码会输出前台的执行代码，这个很有意思。所以在做项目前，起码先大致想好，哪些是要后台输出的，哪些是前台输出的。特别是使用extjs后，后台显得更加“靠后”了。在我的项目中，后台的工作大致分两个：一是输出页面和资源(js)，就是一个简单的html页面，包括调用哪些js脚本等，内容都不多；另一个功能是响应ajax请求，返回需要的结果。这两种请求的处理方式略有些不同，一个主要验证权限，一个主要验证参数。
基于这种模糊不清的关系，我会要求我的队员按纵向分工。每个或每组人负责一个模块，从后台到前台的代码。这样，他们会有清晰有逻辑，而且在代码出现问题时，不会影响其它模块。主要还是这种模糊不清的关系容易在两端扯皮。按纵向分工后，如果出现问题后，你可以说：自己去检查吧，都是你的代码！
总之，要尽量减少纠纷，也要在项目设计时多费心。
6.JS的调试
能够在FF用firebug来调试已经让我感到足够的开心了！JS的调试是个麻烦事，特别在IE和FF间还有不少的细小差别。对于不太常用的google等其它浏览器，一般的开发都已经忽略。
我的感觉，尽量把一个问题彻底修改完，再继续工作。设计代码是，要同时在FF和IE下进行，常规的频繁的调试可以在FF下做，小阶段性的完成后，如一段功能代码或一个功能完成后，一定要去IE跑一跑，如果想起来有半天都没有换过浏览器调试，最好马上换过去看看。以往的经验告诉我，JS不怕错，就怕一堆错，很难定位！。
先写这些，感谢andy_ghg 的sharing，起到抛砖引玉的作用，也希望大家都把自己的心得体会在这里分享。写了不少，也没检查，如有错误还请体谅。
724
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
