Revision de Codigo

Hoy en dia me encuentro escribiendo estandares y buenas practicas para la programacion en Java, y en algunos casos, para cualquier desarrollo que trate de ser dinamico (no digo agil, digo dinamico porque los diferencio en metodologia).

Creo que la revision de codigo es un fantasma empresarial al que muchas veces le han atribuido mas poder de resolucion de problemas del que tiene.
La revision de codigo automatica es el primer paso a una politica de desarrollo que termine en un Continuous Integration (voy a retomar este tema en otra entry) con buenas auditorias, de modo tal que el codigo se mejore continuamente y se modifique de una forma mas segura, llegando a produccion un codigo probado y lo mas estable posible, mitigando riesgos en ambientes productivos.

La idea que tengo ahora, es (en orden de prioridades):

1. Revisar el formato del codigo... ok, eso ayuda a entender el codigo de la empresa siempre y cuando se determinen las reglas de nomenclatura mas importantes, el idioma del codigo, las entidades de negocio principales (para que este relacionado con el aspecto funcional y sea entendible) y archivos shipment y destinados al deploy.
2. Corregir errores tipicos en el codigo estatico.
3. Revisar de reglas de codigo de la empresa.
4. Revisar y recomendar buenas practicas en el codigo (automaticamente) a modo de ir capacitando a los recursos.
5. Crear un workspace comun a los diferentes proyectos y estandarizar los frameworks de desarrollo (maven).

Eso es lo que apunto en el primer paso. ya que creo que los pasos a Continuous Integration son:

1. a- Repositorio comun, trabajo en equipo ordenado. b-Division clara de ambientes de desarrollo, prueba, preproduccion y produccion.
2. Pruebas funcionales y regression tests
3. Revisiones de codigo, estandarizaciones, convensions (si, hablo de poner maven y fijar un repositorio propio en lo posible donde controle los fwks y versiones que se pueden utilizar), buenas practicas
4. Auditorias y automatizacion del proceso
5. Stress test y automatizacion de pruebas funcionales
6. Continuous Intregation (CI para los amigos :D).

No hablo de la integracion con todo el ciclo de SCM, ya que eso depende de las politicas de la empresa (si van a asociar cada cambio o si van a asociar un shipment por pedido, etc....). Ademas, el circuito de aprobacion de pedidos puede verse de forma separada, el ciclo de desarrollo como una caja negra y la salida (version, entregable, rollout, etc...) como el producto final del SCM.

• 1 y 2 ya los tengo, me faltan los demas.
• El 3 lo estoy haciendo.
• Para el 4 necesito fuerza de trabajo (mas gente, aunque esto depende de cuanto desarrollo in-house tenga la empresa)
• Para el 5, necesito suerte, porque voy a tener que trabajar muuuuucho para que las distintas areas me presten atencion y para que se definan las politicas de performance, atributos de calidad y se automaticen las pruebas funcionales :P
• Para el 6, si tengo todo lo demas solo necesito equipamiento de infraestructura y gente que brinde el soporte.
• Eso es lo que vengo calculando por ahora.

La idea, es que la mayor parte del trabajo sea automatica, por lo que no voy a ponerme a revisar cada regla que escribo, sino, que voy a buscar herramientas que se integren facilmente al desarrollo que lo hagan por mi.
Para .NET ya lo tenemos. Ahi todo bien, se integra con el IDE, se generan reportes y la auditoria de estos reportes.....bueno, todo bien.
Para Java aun no, asi que vamos a usar alguno de estos:

checkstyle
Se integra con eclipse y maven, esta ampliamente difundido, genera reportes en diferentes formatos. Es configurable desde el IDE, se pueden exportar e importar las reglas a traves de un XML, se pueden extender las reglas.
Limitacion: Evalua codigo estatico, sin tomar en cuenta euristicas de codigo en tiempo de ejecucion. Las reglas evaluan el contexto de una sola clase y no todo el programa.
PRO: Ya hay gente que lo esta usando y definio un conjunto de reglas.

PMD
Se integra con eclipse y maven, esta ampliamente difundido, genera reportes en diferentes formatos. Es configurable desde el IDE, se pueden exportar e importar las reglas, se pueden extender las reglas.
Limitaciones: remarla para que lo pongan y aprendan. Evalua codigo estatico, sin tomar en cuenta euristicas de codigo en tiempo de ejecucion.
PRO: Es igual que checkstyle pero permite que las reglas que se crean actuen en un contexto de ejecucion de programa y no de clase.

Otros...
Hay uno de Parasoft (tiene muy buenos productos, como Jtest que genera los casos de prueba funcional visualmente y de ahi podes obtener los Junit. Y trabaja con python :D) que aplica euristicas sobre el codigo estatico que evaluan como se comportara en tiempo de ejecucion.... Guaaauuuuu, pero es pago y es caro, ergo NOT.


Asi que, por el momento me encuentro escribiendo documentos, para al final llegar a la meta.
Paso a paso :D
Igual, esto tiene muuuuucho mas sentidos en compañias que tienen mucho desarrollo in-house y mas sentido para compañias productoras de aplicaciones.

Saludos.