A lo largo de nuestras carreras como geeks, tendremos que diseñar muchas funcionalidades, escribir mucho código y también, la pesadilla de muchos: leer, entender y modificar cosas que ya están hechas, algunas de ellas obsoletas.
Lidiar con cosas que alguien mas hizo a menudo es un verdadero desastre, como bien dice nuestro buen amigo Dilbert:
En el comic, Dilbert como buen programador que es, seguro estaba pensando usar patrones de diseño sólidos y eliminar esos odiosos anti-patrones a menudo creados por programadores, tanto juniors como seniors, apuesto a que todos tienen una calavera de que hablar en este tema.
Pero… realmente que es un anti-patron? podemos crear nuevos patrones de diseño? hay un patron para cada anti-patron? hablemos un poco de ello:
Que es un anti-patron?
dejando de lado las definiciones que nos da wikipedia, para mi un anti-patron es una solución que solo podría ser aceptable en un estudiante de primer año de la facultad de ingeniería, vaya! yo era experto en anti-patrones cuando estaba aprendiendo, y no fue hasta que salí a trabajar (gracias a Dios en empresas geniales!) que me di cuenta de mis blasfemias!!! nombrare algunos de los anti-patrones que yo seguro cometí en algún momento y que al darme cuenta de ello los bautize como me vino en gana.
- “La Clase Maestra”: recuerdo como mi primer proyecto en el curso de introducción a la programación de computadoras 1, ejecutaba toda la lógica de un complicado juego de monopoli, en 1 clase que contenía 1 método (el main). Hasta la fecha aun me cause admiración mi yo del pasado… Como diablos fue que pude lograr algo tan monstruoso y sacar 85 de nota final?? (era un n00b y mi catedrático lo sabia). Así que el criterio que forme para evitar este anti patron fue básicamente el principio de responsabilidad única el cual nos dice que: “Si tu clase hace mas cosas de las que indica su nombre, lo estas haciendo mal” por ejemplo si tu clase se llama: “SaludadorDelMundo” y tiene métodos para decir “Hola Mundo”, “Como estas mundo”, “Adios Mundo”, en realidad tu clase hace el trabajo de 3 clases: “ConversadorConElMundo”, “DespedidorDelMundo” y debería ser refactorizada en 3 clases cada una de responsabilidad única, de manera que “los idiotas por venir” no tengan que reescribir todo porque no entienden un carajo de lo que hicimos!
- “Llamar métodos de otras clases indiscriminadamente” Mientras programamos es fácil hacer que nuestros objetos hablen con otros objetos que están lejos del contexto del contexto de dicho objeto… whaaat? bueno voy a tratar de explicarlo fácil, imaginen una Clase “Automóvil” que tiene varios métodos, y que en uno de estos métodos se hace una llamada a “Motocicleta.getCombustible()”… pero hey!!! no estamos en Motocicleta!!! estamos en “Automóvil”!! no tendría sentido usar los mismos criterios porque los objetos son distintos. Como lo evitamos? Supongan que tienen un objeto O que tiene métodos M, O no debería hablar con absolutamente nadie excepto:
- el mismo O
- los parámetros de M
- Componentes directos de O
- Variables globales de O, accesibles desde M
O en otras palabras, si tienen un objeto llamado “perro” y quieren sacar a pasear al perro, pues deberían darle la orden al perro de que camine, no ir a buscar cada una de sus patas para moverlas y hacer que así camine, perro debería tener las suficientes funciones como para hacerlo solo.
- “Código espaguetti” El código espagueti es lo totalmente opuesto a un estilo de programación estructurado, es a menudo secuencial y muy difícil de seguir. Son procedimientos “top-down” que hacen referencia a otras lineas a través del famoso y controversial goto. esto en general no es sano, no tanto para el computador que lo va ejecutar, si no mas bien para los humanos que lo tienen que leer y entender. simplemente es un “no, no”
- “Programación Copy Paste” Es común entre desarrolladores encontrar dentro del mismo proyecto o incluso en google código que soluciona un problema similar al que están tratando de resolver, por lo cual se curan de espantos y deciden que la solución ultima y buena es simplemente copiar de aquí y ponerlo allá y “ver que tal va”, probablemente Dilbert encontró bastante de esto en el proyecto de la tira cómica. Bueno pues déjenme decirles algo, si ustedes hacen esto LO ESTAN HACIENDO MAL, la solución real es entender el problema y crear una solución acorde al problema que están intentando resolver, eso que están copiando seguramente estaba visto para un problema distinto y probablemente introduce vulnerabilidad, y código muerto a su solución! eso sin mencionar que a algunas personas (yo he visto varias) incluso olvidan cambiar los nombres de las variables destruyendo así cualquier rastro de limpieza en el código que podría quedar de un copy-paste 🙁 la conclusión es: “NO HAGAN COPY PASTE” piensen un poco antes 🙂 es valido guiarse con soluciones de otros colegas, pero siempre escribir su propia solución es el camino correcto.
Finalmente como en algunos de mis posts, quisiera recomendar tres libros muy buenos para aquellos que buscan mejorar cada dia sus practicas en la creación y diseño del software que tanto nos apasiona aqui estan:
Si ustedes se preguntaron alguna vez en su vida, “Como puedo ser un mejor programador” pienso que leyendo y aplicando estos 3 libros, seria un excelente comienzo para mejorar lo aprendido 🙂 yo, no soy perfecto pero estos libros me han enseñado muchisimo! Si pueden comprenlos en hard-copy o para su kindle y tenganlos siempre presentes!
Saludos!