¡Arregla ese código ya!

Sin categoría

 

robots_programmer_psychiatrist_285645

 

Vale. Estas tocando código en el proyecto en el que estás metido ultimamente y de repente encuentras un mal trozo de código en una función. Las malas aproximaciónes -aunque muchas veces habituales- pueden ser del estilo “bueeeeno… ese es el código de otro y no tengo nada que ver con el” o “no tengo tiempo ahora, tengo otras tareas” o “seguro que rompo algo si toco esto”

El (gran) problema es que el mal código tiende a acumularse y crecer. Incluso si es un pequeño trozo de mal código, crecerá y en breve tendrás un nuevo proyecto heredado del que se dira que fué escrito por incompetentes y que nadie querrá mantener. ¿Te suena?.

Ese es el motivo por el que tienes que arreglar ese código inmediatamente. Cuando veas algo mal hecho, que use una mala practica, o que sea manifiestamente mejorable: mejóralo. YA. O, teniendo en cuenta que unas partes de código depende de otras, seguramente muy pronto será demasiado tarde para hacerlo y las nuevas lineas que añadas (peor aún si alguien se dedica a copiar y pegar) serán una auténtica pesadilla para mantener. Veamos como solucionar las excusas anteriores:

Bueeeeno… ese es el código de otro y no tengo nada que ver con el. ¿Cómo?. ¿Que me dices?. Tu *estas* en ese proyecto, asi que tienes el “derecho” a modificarlo. Si otro ha escrito ese código que tu consideras que no es bueno, es probable que ni siquiera se haya dado cuenta de lo malo que es, asi que no lo arreglará nunca. Seguramente no se ofenderá si lo arreglas y le cuentas porqué lo has hecho. O tal vez si, pero ese es otro problema (y no es tuyo).

No tengo tiempo ahora, tengo otras tareas . Esto tambien es una tarea. Y ademas seguramente puedes incluso anotar una nueva incidencia en tu sistema de control tipo Jira, Redmine, Bugzilla o lo que quiera que uses indicando refactorizacion de lo-que-sea y apuntar ahí las correspondientes horas. Tambien puedes simplemente anotarlo para resolver en el próximo sprint si usas metodologias ágiles. Si hay problemas con la gente de administración o gerencia puedes sugerirles que lean algo sobre ‘refactorización’. Normalmente no sirve de mucho pero al menos limpiarás tu conciencia.

Seguro que rompo algo si toco esto . Vale, seguramente si que lo vas a romper. Hmmm.. espera. Tienes test unitarios, ¿verdad?. Y test de integración, funcionales y de aceptación, ¿no?. Si no es asi, arregla eso lo primero de todo. A partir de ese momento no tendras miedo de romper nada. Las revisiones de código tambien son importantes para solucionar este problema. Si el equipo revisa el nuevo código que entra en el proyecto, las probabilidades de que entre mal código sin que nadie de se cuenta decrecen. Puede pasar, pero es mucho mas dificil.

El gran problema de esta aproximación al código es, ¿como puedes estar seguro de que ese trozo de código esta realmente mal hecho?. Bueno, al final es un tema de experiencia, conocimiento de buenas prácticas, patrones de diseño y toda la artilleria de los mejores programadores. No se puede dar una receta única para esto, pero seguramente en tu equipo debe haber un par de personas capaces de identificar mal código. Si no es asi, deberias intentar conseguir al menos una persona con ese perfil.

Resumiendo: arregla el codigo inmediatamente. Te ahorrará tiempo, dolores de cabeza y hará que estes mas orgulloso de tu proyecto. Porque si el código de tu proyecto es una basura, también es tu culpa.

Anotaciónes: No deberias cambiar algo sólo porque de repente te parezca que está mal. Enseñaselo a tus compañeros y/o líderes técnicos. Si es mas de un par de lineas, discute la mejor forma de afrontarlo y crea una histora para solucionar el problema. Pero hazlo pronto.

Estos consejos no se refieren a código complejo o dificil de leer precisamente por solucionar un problema complejo. Es bastante probable que el código sea complicado porque los requerimientos de negocio tambien lo fueran. Asi que si realmente quieres mejorarlo, investiga como y porqué se hizo de esa forma.


Esta anotación es una traducción mas o menos libre del artículo Fix That Code Immediately! en JavaCodeGeeks.

Nos encantaría decir que en Virtual Software estamos ya en un punto como para dar lecciones sobre lo que se cuenta en este articulo: tests que cubren todo el código, líderes de conocimiento, refactorización inmediata del código, revisión por parte del equipo… En realidad, estamos iniciando el camino y siempre está bien tener un punto de referencia en el horizonte para conocer el objetivo. Esa es la motivación de esta anotación.

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s