Well, for automated code reviewing, I'd look at something like findbugs for the
Java side and HTMLTidy (in its XML mode) for the View side. JSF tries very hard to be as much plain old Java as possible, so the stock Java tools are a good start.
For the actual process, there are a few other things I'd look at as well:
1. How many times are JSF packages other than the javax.faces model packages used? And is the usage localized or splattered all over the app? Grep can help automate this, but how the non-model JSF code is used is important as how much it is used.
2. Is there persistence code in the backing beans? You can scan for java.sql imports if
JDBC is the persistence mechanism and for javax.persistence imports if JSF is in use (or org.hibernate,
etc.)
3. Are the Views loaded up with listeners and bindings? People often overdo this. Usually a straight value or action property is sufficient. You can grep for "binding" and "Listener".
And, of course, my own personal pet peeve: Is the app using standard
J2EE security (defined in web.xml) or does it create its own "security" system? Even the best-written apps are worthless if they're just security exploits waiting to happen. And unless you have a full-time dedicated Java web security person on staff, I can pretty much guarantee that will be the case if the app is based on some "clever" person's self-invented security system - even if he/she has managed to make it the corporate standard. Most DIY systems I've seen didn't stand up to even 5 minutes casual meddling by non-hacker types like me.
