Escribir código basura no esta mal.

imagen_codigo_basura

Es imposible que un programador no produzca código basura, por el termino “basura” me refiero a código de calidad deficiente, difícil de leer y entender, código de un uso, ejemplos para aprender o código bajado de internet (Stackoverflowazo). Todo esto es indeseable en cualquier proyecto, es el equivalente al cáncer en nuestras aplicaciones. Nadie quiere escribir código feo, pero es imposible no escribirlo. ¿Como sobrevivo al código basura?, a continuación te explico:

Escribir lineas basura es una herramienta.

No siempre tendrás el tiempo ni la necesidad de pulir todas y cada una de tus lineas de código. Es aceptable, incluso deseable escribir scripts o aplicaciones de consola que te ayuden a salir  del paso. Codificas algo rápido que te permita salir del problema rápidamente. Probablemente algún procesador de texto que te permita generar clases y componentes a partir de una plantilla. O alguna aplicación de consola que ayude a corregir registros en base de datos. También puedes tener algún pet project que te sirva de herramienta de aprendizaje. Todo esto es valido, siempre y cuando puedas acelerar tiempos o automatizar aspectos de tu trabajo.

Puedes desarrollar proyectos orientados al código basura (al menos en parte).

Muchos proyectos inician con la construcción de módulos desechables llamados prototipos o pruebas de concepto. No es mas que un poco de código con un mínimo de funcionalidad el cual te permite demostrar un punto. Si el prototipo cumple su cometido puedes desecharlo y construir algo mas robusto. Al contrario, si el prototipo no aporta valor o no se obtiene el resultado esperado, este sera desechado permitiendo ahorrar recursos al no invertir mucho esfuerzo en un producto no viable. Un prototipo no es un sistema completo, ni siquiera es iterable, ni se construye nada con el. Es código de un uso destinado a ser basura.

Producir código basura es una actividad “malvada”.

Hay un peligro latente con las lineas de baja calidad. Y es que sean usadas para construir algo mas. La corrección rápida que hiciste puede ser interpretada por algún compañero tuyo o alguien de otra área como: “ya tenemos algo que lo hace”. Si, ese código horrible pero funcional puede llegar a formar parte del sistema o peor aun, volverse un producto comercial. Para la gente no instruida, que un programa funcione mal o que funcione bien es difícil de distinguir. Cuesta mucho explicar porque se deben desechar lineas de código funcionales. Hablamos de un diseño que no fue pensado para ser mantenido, las consecuencias de agregar estos componentes serán costosas. Bueno, siempre y cuando se asuman los costes de la decisión no habría problema, en mi experiencia agregar código basura a producción aun comunicando riesgos es un error.

Cada tipo de código para su propósito. ¡Escribe código basura!.

Siempre que codifiques debes de clasificar cuidadosamente el uso que le vas a dar a tus lineas. Piensas hacer componentes re utilizables y confiables, adelante. Trabaja con calidad y de la mejor manera posible. Si decides hacer algún programa desechable también es valido, solo desechalo lo mas pronto posible. Lo importante es saber el uso al que esta destinado y dejarlo así durante toda la vida útil del programa, se sincero contigo mismo. No inventes excusas para convertir algo no reutilizable en reutilizable.

Conclusiones.

No hay una definición clara de que es codificar bien o codificar mal. Lo que se si hay con consecuencias, con las que se vive a futuro. Lineas de mala calidad agregan complejidad innecesaria a tu sistema. Evitalas siempre que sean posible. Si te ves en la necesidad de usar código basura, que sea por decisión, no por accidente.

 

Autor imagen: Andrew Stawarz

 

 

 

Gustavo Sánchez