Colaboración de Ernesto Alfonso
La mayoría de las personas piensa que programar es simplemente sentarse frente a una computadora y aporrear el teclado de forma aleatoria hasta que mágicamente todo funciona, nada más alejado de la realidad, pero de alguna forma debían mostrarlo en las películas.
El desarrollo de un programa de computadora, como cualquier tarea de ingeniería, conlleva múltiples etapas, desde planificación y diseño hasta las pruebas, garantizando la calidad del proceso.
“Hablar es fácil. Muéstrame el código.”
― Linus Torvalds
Podemos compararlo con la ingeniería civil, desde el punto de vista de que casi cualquier persona es capaz de apilar palos y piedras y hacer una choza que, con suerte, no lo aplastará mientras duerme. Pero como diría Castiel, “…hay un límite hasta donde puedes apilar piedras y estiércol…”(cita original aquí) antes de que colapse. Lo mismo aplica a la programación, cualquiera puede escribir una calculadora y hasta puede funcionar, pero requiere de equipos multidisciplinarios, separados en múltiples roles, con cientos de horas de planificación, diseño, análisis, implementación, pruebas, para desarrollar los productos que hoy en día son parte fundamental de nuestro modo de vida, desde Facebook hasta los controladores automáticos que hacen funcionar las fábricas.
Con el paso del tiempo y mucho sufrimiento, los programadores han aprendido una serie de reglas informales que permiten el desarrollo y posterior mantenimiento del código. Muchas veces se subestima la importancia del mantenimiento, olvidando que los programas necesitan evolucionar en el tiempo, pues pueden surgir nuevas restricciones del negocio, nuevas necesidades o errores ser detectados.
“No soy un gran programador; Solo soy un buen programador con buenos hábitos.”
― Kent Beck
Todos aquellos que necesitan escribir código, sin importar el lenguaje de programación utilizado, deberán estar familiarizados con estas reglas o “buenas prácticas”
Mantén las cosas simples (KISS, Keep It Simple)
Tú sabes que eres brillante, pero tal vez te gustaría entender dentro de dos semanas, lo que hiciste hoy.
Linux 1.3.53 CodingStyle documentation (1995)
Una premisa en la ingeniería es que las soluciones deben ser lo más simples y baratas posible, esto se debe a que la acumulación de elementos complejos, aparte de ser costosos y difíciles de implementar, son mucho más difíciles de mantener (referido a cualquier acción realizada posterior a la implementación). Si crees que tu problema es muy complejo como para dar una solución simple, entonces es posible que pase una de dos cosas, la más probable es que tu solución no sea la correcta, sospecha de tu aproximación y plantea diversas alternativas. Lo segundo que puede ocurrir es que verdaderamente el problema requiera una respuesta compleja, lo aconsejable para esto es fragmentar el problema en pasos (Divide y Vencerás) e implementar soluciones para estos pasos. Se deben seguir las reglas igual que si fueran problemas independientes, al final tendrás los pasos agrupados en funcionessencillas.
No repitas nunca (DRY, Don’t Repeat Yourself)
Nunca, pero nunca, repitas un fragmento de código. Ese es uno de los peores errores que se pueden cometer, no solo referido al código en la unidad en que se esté trabajando, sino en ninguna parte de la aplicación. Si una funcionalidad será utilizada en varias unidades, deberá separarse a una unidad para ella sola o para otras como ella. Un ejemplo sería si tienes que utilizar un formato de fecha específico y formateas las fechas en varios lugares del código, si en el futuro el formato de fecha cambia, será necesario buscar en toda la aplicación donde fue implementado el formato y actualizarlo. El problema empeora si es otro el que lo tiene que arreglar, de seguir trabajando de esa forma se pierde mucho tiempo cada vez que es necesario modificar algo. Esto es inaceptable y es el motivo por el cual muchos proyectos dejan de ser factibles para los clientes.
Los nombres son importantes
“Programa siempre como si la persona que termina manteniendo tu código es un psicópata violento que conoce donde vives.”
― John Woods
Hoy en día no hay ninguna necesidad de poner siglas como nombres de variables, funciones o clases, ya que el código en la mayoría de los lenguajes pasa por un proceso de mimificado o compilado que optimiza estas cosas, garantizando que la longitud de un nombre no interfiera para nada en el rendimiento del producto final. Las siglas pueden tener sentido en el momento en que se declara una variable, pero al paso del tiempo y al desconectar del contexto en que se creó, requiere de esfuerzo adicional entender su significado, esto hace que el código sea menos legible y por lo tanto dificulta el mantenimiento.
Desarrolla basado en pruebas
Un ingeniero de pruebas entra a un bar. Pide una cerveza. Pide 0 cervezas. Pide 99999999999 cervezas. Pide un lagarto. Pide -1 cerveza. Pide una ueicbksjdhd. El primer cliente real entra y pregunta donde está el baño. El bar estalla en llamas.
Otra mala práctica que se realiza con mucha frecuencia es ignorar la generación de pruebas tanto unitarias como de integración a la hora de implementar una funcionalidad, implicando que para ser probada requiere su ejecución manual, haciendo perder tiempo y disminuyendo la exhaustividad de la prueba. Lo aconsejable es crear primero la prueba que debe pasar la funcionalidad y luego implementarla, para que durante el desarrollo se resuelvan problemas relacionados con el dominio de la funcionalidad. Un buen analista de software debe proporcionar las precondiciones y postcondiciones que debe cumplir la solución, además de los valores extremos que podrían afectarla.
Falsa optimización
A veces muchos desarrolladores, tanto experimentados como novatos, tienden a querer optimizar todo, es muy fácil pensar que eso es bueno. El problema surge cuando para optimizar un fragmento de código se utilizan estructuras de datos auxiliares, algoritmos de búsqueda avanzados, árboles, paralelismo y un largo etc. para optimizar una función que solo se va a ejecutar una vez en un intervalo de tiempo relativamente grande, además, la función no es en sí costosa ni está ralentizando ningún proceso. Esto es contraproducente, ya que la mejora no es perceptible por el usuario y dificulta la legibilidad del código, así como su mantenimiento o actualización. En otros casos se utilizan métodos abreviados del código pensando que al tener menos líneas, es más rápido, cuando su implementación real es igual de costosa.
“Programar hoy es una carrera entre los ingenieros de software tratando de hacer mejores y mas grandes programas a prueba de idiotas y el Universo tratando de producir mejores y mayores idiotas. Hasta ahora, el Universo está ganando..”
The Wizardry Compiled
― Rick Cook
Aunque existen otras muchas técnicas para lograr un código correcto, las mencionadas pueden ser un buen punto de partida para aquellos que comienzan en esta senda.
Finalmente, lo más importante es no desanimarse, el camino es largo y complejo, lleno de frustraciones, pero queda eclipsado por el resultado. Nada mejor que tu código funcione.
Comentarios
Publicar un comentario