grails之殇

  网络盛传rails、grails的开发效率，我也就尝试着使用其开发，不过最终效率都没能提升上去，原因不在乎于rails、grails本身，而在与自己。

  我选择的是grails，毕竟本来就是java系的人，而在外网访问权限封闭的公司主机上安装ruby on rails非常困难。

  grails提升开发效率的根本点在于：

  约定甚于配置：原本项目中需要配置spring bean xml、hibernate orm xml，在grails中自动完成了，MVC、ORM的配置由框架约定替代。这是我认为敏捷加速最快的一点，MVC的扭转、ORM domain与数据库的映射都已经自动化了，可以让一个初学者马上开始项目。一般的初学者很难运行起一个web应用，首先要熟悉tomcat，然后是war包结构、MVC配置，接着要搭建一个数据库..... 这样一下来几天时间过去了。grails可以让你几行代码就跑起来一个应用。 

  动态脚本语言敏捷于高级语言：groovy vs java，实际上你使用groovy要比java的效率高很多，而groovy诞生的原因正是如此。一个java高手在伦敦机场等老婆，于是乎玩起了python，玩着玩着就着迷了，认为java也需要变革下，减少过多的冗余语法，三下五除二，约了几个高手定下了创建groovy的计划。但学习groovy是要成本的，就好像你学习python一样，需要一个过程，特别是你本身不是英语母语的情况下你的学习周期将更长，你要完全熟练的掌握groovy，最起码要花一周，而这一周是被groovy独占。groovy的IDE是有了，grails的IDE则再现看来不是很强大，很多方法，特别是注入型的动态方法必须手工敲，这是很影响开发效率的。另外groovy的api很多是和java重合的，比如session、cookies。如果你是因为使用grails而被迫使用groovy，并且无法感受到groovy的简约和高效，仍旧用java风格写groovy，这等于是降低了你的开发效率。

  测试：grails不仅是一个开发框架，同时也是一个开发过程范例，它把集成测试、单元测试放进了框架，让你遵循测试先行的xp方法。不过一样的是如果你在第二条受挫的话，在这里你仍旧是举步维艰。

  环境部署、遗留代码集成、调试、团队grails技能等问题也是使用grails必须考虑的，如果你是一枝独秀，仅仅是开发一个毫无关联的新系统，使用grails是有优势的。

   社区中总有一群无私分享的高人，他们写了很多文档来帮助我们使用这些高效工具，最多的当然是reference document，grails的reference写的很完整。

总结下，grails是敏捷开发的代表，挑战rails，维护java社区之敏捷，却一直没有火起来。我之前非常疑惑，并亲身尝试了使用grails这个过程，确实，我没有建立起信心，也就是使用grails建立复杂应用的信心，它具有更多的不确定性，遇到了很多问题，一个个克服了，但总是收效甚微。如同以前在hibernate和ibaitis间抉择一样，也许，如果你是一张白纸，你会很快拥抱grails，它让你很快尝到甜头，并以一个无知者的身姿去面对一个个问题，学习学习再学习，而如果你本身就有了深厚的java web开发功力，这种选择就值得商榷了。