¿Por qué usar un analizador estático de código?
Los analizadores estáticos de código permiten medir de una forma más o menos objetiva el estado del código del proyecto. Se apoyan en reglas y convenciones, y van “leyendo” nuestro proyecto y nos hacen críticas.
¿Por qué en algunos equipos es tabú?
Si sabemos usarlos, los analizadores estáticos de código pueden darnos gran valor en nuestro proceso de desarrollo. Por el contrario, si los usamos con vicios, podemos llegar a dispararnos un tiro en el pie y llegar a odiarlo.
Los analizadores de código, nos muestran las partes con “mal olor” de nuestro código, y nos dan un feedback de las cosas que deberíamos mejorar. Si no estamos acostumbrados a recibir feedback como parte del proceso de mejora contínua, tendemos a desestimarlo. Si le sumamos que probablemente no empezamos el proyecto usando el analizador desde cero, vamos a ver que hay muchas cosas por mejorar, y eso puede llegar a abrumarnos.
¿Por qué usar las reglas por defecto?
Muchas veces nos vemos tentados a personalizar las reglas. Ponemos excusas como “esto es una pavada”, o “el proyecto es legacy, ya se que está todo mal”, o “ahora no tengo tiempo”, y empezamos con la tijera a recortar reglas.
Cada regla fue creada con un objetivo específico. A veces solemos desactivarlas sin siquiera pensar cuál es el objetivo específico que persigue la regla víctima. Como primer paso, tengo que asegurarme que conozco ese objetivo. Puede pasarnos que no compartamos el para qué de la regla, y en ese caso podemos borrarla impunemente. Pero si compartimos el objetivo de la regla, probemos dejarla. En todo caso, si para una parte específica del código pensamos que no nos sirve, podemos hacer la excepción, solo en ese caso puntual.
¿Cómo usar constructivamente el analizador de código?
Por lo general, un error debería ayudarme a replantearme cosas. Algunas preguntas adecuadas a plantearse pueden ser: ¿Qué objetivo persigue? ¿Qué me está queriendo decir? ¿Por qué alguien me marcaría eso? ¿Que efecto voy a producir si lo dejo como está? ¿Qué alternativas tengo? ¿Qué dice este error acerca de mi diseño? ¿Debería replantearlo? Cada vez que veamos un error, tratemos de dar respuesta a esos interrogantes. Nos va a ayudar a pensar. Si transitamos ese camino, vamos a empezar a prestarle más atención a esos pequeños code smells, y re cuestionarnos el diseño, antes de que sea más tarde.
En los proyectos legacy, o que no empezaron desde cero, sabemos que muy probablemente tengamos muchas advertencias. No las ignoremos, pero tampoco querramos cambiar todo de golpe. Nos vamos a pegar un golpe feo si tratamos de hacerlo. Marcar un límite cuantitativo del que no podamos pasar, pero hagámoslo en serio, a conciencia. Luego, a medida que pase el tiempo, vayamos bajando ese límite. Apliquemos “la regla del boy scout”: ir dejando todo lo que toco un poco mejor que lo que estaba antes de que yo estuviera ahí.
En un proyecto nuevo, usemos un analizador estático de código desde cero. A lo primero puede resultarnos tedioso, pero vamos a pagar con creces la inversión. Es más, una vez que nos acostumbremos a las reglas, ya vamos a incorporarlas desde el momento de escribir el código, y no vamos a necesitar andar haciendo correcciones.
Siempre empezar a usar el set de reglas por defecto. Solo luego de un tiempo extendido de usar el analizador podemos empezar a revisar (en equipo y a conciencia) cada una de las reglas que veamos que nos traen problemas.
Como dice PMD, “Don’t shoot the messenger”