Es imposible que un programador no produzca código basura, por el término «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. ¿Cómo sobrevivo al código basura?, a continuación te explico:
Escribir líneas basura es una herramienta.
No siempre tendrás el tiempo ni la necesidad de pulir todas y cada una de tus líneas 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 válido, 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 más 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 más robusto. Al contrario, si el prototipo no aporta valor o no se obtiene el resultado esperado, este será 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 él. Es código de un uso destinado a ser basura.
Producir código basura es una actividad «malvada».
Hay un peligro latente con las líneas de baja calidad. Y es que sean usadas para construir algo más. 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 aún, 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 por qué se deben desechar líneas 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 les vas a dar a tus líneas. Supones hacer componentes reutilizables y confiables, adelante. Trabaja con calidad y de la mejor manera posible. Si decides hacer algún programa desechable también es válido, solo deséchalo lo más pronto posible. Lo importante es saber el empleo al que está 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 sé si hay con consecuencias, con las que se vive a futuro. Líneas de mala calidad agregan complejidad innecesaria a tu sistema. Evítalas 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
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20