Los analizadores est\u00e1ticos de c\u00f3digo permiten medir de una forma m\u00e1s o menos objetiva el estado del c\u00f3digo del proyecto. Se apoyan en reglas y convenciones, y van \u00ableyendo\u00bb nuestro proyecto y nos hacen cr\u00edticas.<\/p>\n\n\n
Si sabemos usarlos, los analizadores est\u00e1ticos de c\u00f3digo 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.<\/p>\n\n\n\n
Los analizadores de c\u00f3digo, nos muestran las partes con \u00abmal olor\u00bb de nuestro c\u00f3digo, y nos dan un feedback de las cosas que deber\u00edamos mejorar. Si no estamos acostumbrados a recibir feedback como parte del proceso de mejora cont\u00ednua, 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.<\/p>\n\n\n\n
Muchas veces nos vemos tentados a personalizar\u00a0las reglas. Ponemos excusas como \u00abesto es una pavada\u00bb, o \u00abel proyecto es legacy, ya se que est\u00e1 todo mal\u00bb, o \u00abahora no tengo tiempo\u00bb, y empezamos con la tijera a recortar reglas. <\/p>\n\n\n\n
Cada regla fue creada con un objetivo espec\u00edfico. A veces solemos desactivarlas sin siquiera pensar cu\u00e1l es el objetivo espec\u00edfico que persigue la regla v\u00edctima. Como primer paso, tengo que asegurarme que conozco ese objetivo. Puede pasarnos que no compartamos el para qu\u00e9 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\u00edfica del c\u00f3digo pensamos que no nos sirve, podemos hacer la excepci\u00f3n, solo en ese caso puntual.<\/p>\n\n\n\n
Por lo general, un error deber\u00eda ayudarme a replantearme cosas. Algunas preguntas adecuadas a plantearse pueden ser: \u00bfQu\u00e9 objetivo persigue? \u00bfQu\u00e9 me est\u00e1 queriendo decir? \u00bfPor qu\u00e9 alguien me marcar\u00eda eso? \u00bfQue efecto voy a producir si lo dejo como est\u00e1? \u00bfQu\u00e9 alternativas tengo? \u00bfQu\u00e9 dice este error acerca de mi dise\u00f1o? \u00bfDeber\u00eda 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\u00e1s atenci\u00f3n a esos peque\u00f1os code smells, y re cuestionarnos el dise\u00f1o, antes de que sea m\u00e1s tarde. <\/p>\n\n\n\n
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\u00edmite cuantitativo del que no podamos pasar, pero hag\u00e1moslo en serio, a conciencia. Luego, a medida que pase el tiempo, vayamos bajando ese l\u00edmite. Apliquemos \u00abla regla del boy scout\u00bb: ir dejando todo lo que toco un poco mejor que lo que estaba antes de que yo estuviera ah\u00ed. <\/p>\n\n\n\n
En un proyecto nuevo, usemos un analizador est\u00e1tico de c\u00f3digo desde cero. A lo primero puede resultarnos tedioso, pero vamos a pagar con creces la inversi\u00f3n. Es m\u00e1s, una vez que nos acostumbremos a las reglas, ya vamos a incorporarlas desde el momento de escribir el c\u00f3digo, y no vamos a necesitar andar haciendo correcciones. <\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Como dice PMD, \u00abDon’t shoot the messenger\u00bb<\/p>\n","protected":false},"excerpt":{"rendered":"