Enterprise Grails - Best Practices
After my presentation Adopting Grails at GR8Conf in Copenhagen, people approached me regarding the best practices part. Let’s recap and spend more words than available on the slides (http://www.slideshare.net/gr8conf/gr8conf-2011-adopting-grails). If I’m referring to ‘you’ in the text below, I assume that ‘you’, the reader, is the one that introduces Grails to a team
Clearly articulate the benefits of the framework
Ideally you have a meeting with your core team to discuss the benefits and come to a consensus. From the discussion create a pros/cons table which includes alternatives to Grails (e.g. doing all by yourself or another framework). You need this at least for your stakeholders. Do not rely on hype. Have one or more prototypes or previously created Grails apps available.
Create a local community
Once the team starts working with Grails, you will find people that like it and others that don’t. That’s ok. Find the people that think like you (the ones who like Grails) and start creating a community. Exchange tips and tricks and share it with the rest of the team.
Use the external community and help others using it
Sooner or later you will find yourself in a situation, where the manual or book does not help. This is the time to reach out for the mailing lists and/or IRC channels. Teach your team to work with these tools. It’s good to find a solution by yourself, but not for too long. Otherwise it becomes frustrating; and most of the problems have been seen before.
Provide tools
One of the very first things to do is to provide the team with a good IDE. In case you are not using IntelliJ or Spring-Tool-Suite (STS/Eclipse) now is the time to do so. I found this topic (IDE) the hardest one in the beginning of our Grails adoption.
The next is to install test coverage and static analysis tools like Codenarc.This raises the trust level. Also teach your team to use Grails-plugins.Often your own development can be replaced by simply installing a plugin. Or at least check out the plugin code and learn from it, if you cannot use it out of the box.
Find situations/cases in which Groovy/Grails really make a difference
In order to raise the awareness, expose special features of your development environment to other teams. E.g grails run-app vs. classical web-app redeploy cycle with heavy app servers is a huge time saver. In the long run this makes some teams really jealous.
Stay close to the Grails sweet-spot as long as possible
Grails is really flexible and this is one of its strengths. But the more you move away from the sweet-spot, the more special are your problems compared to the rest of the community. Also upgrading Grails to newer versions is more difficult if your project contains non-standard parts, like POJO based domain models or handcrafted hibernate mappings.
Be available
If you are the person who introduced Grails provide help when necessary. Helping the team should be of high priority. The will ask you many questions and if they don’t get answers they will find a solution to their problem somehow. This could be old-school Java code because of lacking Groovy experience or strange controller constructs.
Don’t let the team swim alone. At least for a while they need you.
Offer/Initiate code reviews/pair-programming
In order to bring the team up to speed with their Groovy/Grails skills offer yourself for code reviews and/or pair programming. Do not wait for them to ask you for reviews or programming sessions. Stay in the driver seat and push forward.
Maintain a catalog of design principles and guidelines
Grails gives you a frame to create your apps, but still enough freedom to stay flexible. But in your team you want to constrain lets say the number of ways to create XML response data or how you handle errors. Provide your team with architecture and coding guidelines. Make clear how things have to be done to avoid chaos. For example, give advice on
- Types, when to use types and when to use def
- Inheritance vs. composition
- controller and services responsibilities
- XML generation strategies
- Java vs. Groovy coding
- etc.
Further ideas
Finally, the following ideas might help you to run your Grails adoption even smoother:
- Use the create-* scripts to introduce own templates for controllers and services
- Provide own scripts for lab-specific tools
If you have more ideas, let me know, since Grails adoption is an ongoing process and I’m happy to know how it worked for you.
