Antipatrones y desarrollo de software


Al iniciar en el mundo de la programación es usual preguntarse ¿Cómo puedo programar mejor? Este interrogante nos acompañará durante todo el trayecto profesional, independiente de la experiencia acumulada, se puede decir que está en la naturaleza humana buscar la perfección.


Pero a veces, incluso con la mejor de las intenciones, llegamos a resultados pocos satisfactorios. Estas situaciones aparecen en el desarrollo de software, donde ciertas costumbres o formas de programar impactan de forma negativa en el desarrollo de la aplicación.


Hablamos de antipatrón cuando desarrolladores y desarrolladoras aplican una solución que consideran efectiva, pero el resultado inmediato y/o a futuro es exactamente el contrario. 


La adopción de ciertos antipatrones pueden aparecer mientras aprendemos programación


Veamos de qué se trata.


Conociendo el lado oscuro








Antes de iniciar, resaltamos que los antipatrones a continuación tienen una fuerte relación con nuestra experiencia como usuarios de apps .Siendo usual que, una vez tomado el rol de desarollado/a, tengamos que revisar nuestras interpretaciones acerca de las características de una "buena aplicación".


Aprende a programar con nuestros Cursos y Carreras de Programación ¡Ingresa ahora!


Sin más que decir, a estudiar el lado oscuro:


Optimización Prematura


Si buscamos que cada proceso y línea de código en nuestro proyecto sea lo más eficiente posible, el tiempo a invertir en el desarrollo de la aplicación sería inadmisible e incosteable, tanto para el cliente como para nosotros mismos. 


Al desarrollar, se resalta la necesidad de centrar los esfuerzos iniciales en la programación de las funcionalidades esenciales. Es decir, que la optimización es una tarea que se realiza cuando comprobamos que existe un problema de rendimiento en la funcionalidad codificada.


Por lo cual, el esfuerzo invertido en predecir problemas mientras se programa con intenciones de perfección puede desembocar en continuas adecuaciones del código fuente, en muchos casos tan excesivas como innecesarias.


 Esto no implica que nos libraremos de optimizar en absoluto. Solo que la optimización que realmente importa (y la que nuestro cliente está dispuesto a costear) es la que afecta positivamente en la experiencia de usuario. Aplicación que no funciona, no se paga: Puede que el usuario sea más paciente con un software de rendimiento cuestionable pero útil. A que el equipo de desarrollo cuente con el tiempo y los recursos para “preparar” el programa ante todos los problemas de performance posibles. Algunos de estos son difíciles de detectar si no existe un volumen de interacciones significativo con la aplicación. Evitando la optimización prematura mientras aprendemos a programar: Codificar la funcionalidad solicitada, manteniendo el código simple (KISS), priorizando el cumplimiento de plazos de entrega.


La optimización se analiza mientras interactuamos con la aplicación en funcionamiento, no desde las instrucciones de código al programar.


Emplear herramientas de perfilado de rendimiento con la intención de obtener mediciones exactas sobre la performance de una script o algoritmo. 


Reinventar la rueda


Podemos percibir algunas aplicaciones como soluciones innovadoras, pero esto no implica necesariamente su codificación desde cero, empleando técnicas “exóticas” de programación. Es decir, que el grado de novedad de una app está determinado por las funcionalidades que provee y no por las características inéditas del código fuente.


De hecho, si pretendemos que cada proyecto se construya sin tomar referencias o recursos de otros proyectos propios o de terceros, el tiempo de desarrollo de la solución sería muy superior al esperado. 


Al emplear plantillas, librerías, frameworks o incluso la adaptación de cierto proyecto de código abierto a las necesidades particulares de nuestros clientes, no solo acotamos los tiempos de desarrollo de la solución, también presuponemos cierto grado de fiabilidad sobre el código incorporado, donde a mayor popularidad de la herramienta o recurso, más certeza tenemos de su funcionamiento y utilidad.


De la misma forma, al programar no lo hacemos “por descubrimiento”. La respuesta a ¿Qué programar? Es el resultado de un análisis previo sobre la funcionalidad esperada, mientras que el ¿Cómo programar? Está condicionado por algoritmos, objetos, métodos y procesos que creemos pertinentes para llegar al objetivo.


Y por “creer” entendemos que dicha convicción es el producto de una experiencia de codificación previa que resuelve la situación y/o el resultado del estudio de patrones y paradigmas de programación, sumados a conocimientos sobre los elementos del lenguaje de programación que contribuyen a clarificar “formas posibles de codificar el script”.  


Lo nuevo no siempre es bueno: Es necesario emplear referencias, metodologías y herramientas efectivas con la intención de focalizar nuestros esfuerzos en la programación de las tareas esenciales del software. La mímica de código (por no decir copia) es un medio para analizar, adecuar y si fuera posible mejorar características de nuestra aplicación. 





Existe una porción significante de toda app que constituye la programación de características comunes a otras aplicaciones: validaciones, animaciones, responsive, gestión de imágenes, etc. La idea no es desarrollar cada componente desde cero, si no codificar una aplicación que permita al usuario hacer algo de valor, independientemente de si el código es completamente inédito.


El principio de “No repetirse”(DRY), también aplica a no repetir la codificación de cierto elemento desarrollado de forma fiable en una librería. Evitando reinventar la rueda mientras aprendemos a programar: Emplear, plantillas, librerías y/o framework populares para el desarrollo de aplicaciones con finalidad comercial.


Reconocer características esenciales del lenguaje de programación empleando, identificando soluciones propuestas a problemas comunes. 


Analizar el funcionamiento de algoritmos de terceros, evaluando el impacto en la solución al introducir modificaciones propias.


Estudiar sobre patrones y paradigmas de programación.


Deuda técnica 


Si bien la deuda técnica no es un anti patrón en sí misma, es un concepto que nos permitirá analizar posibles problemas mientras desarrollamos una aplicación. Como mencionamos en la sección anterior, introducir código y plantillas de terceros en nuestra solución es algo usual, pero no implica que estos recursos sean infalibles sólo porque fueron desarrollados por un equipo o inpiduo más experimentado.


Todo código fuente puede ser “re-programado” manteniendo su funcionalidad (refactorización), con la intención de mejorar ciertas características de la solución: legibilidad de código, reutilización del código, simplificación de código, etc. El problema es que esto no se realiza de forma inmediata, como vimos en la sección de optimización prematura, nuestros esfuerzos iniciales se centran en el desarrollo funcional de la aplicación, en eso que “mostramos a nuestros jefes”


Al ser el desarrollo de software una actividad condicionada por una realidad económica: presupuesto de cliente, recursos y equipamiento disponible, bienestar del equipo de desarrollo, entre otras. Existe una tarea de gestión y priorización de esfuerzos, que puede originar situaciones de omisión voluntaria o involuntaria sobre aspectos a mejorar en la aplicación. 


A esta falta de tiempo o presupuesto para realizar mejoras “no prioritarias” en el código fuente la podemos llamar deuda técnica. Así como en la vida cotidiana a veces debemos contraer una deuda económica para comprar o pagar algo más importante, al desarrollar es posible contraer una deuda técnica al construir una solución de forma apresurada y/o desorganizada.


Esta situación se puede ver maximizada al no contar con un entendimiento significativo de las librerías o código de terceros que incorporamos a nuestro proyecto, lo que desencadena retrasos e inconsistencias al momento de afrontar errores de funcionamiento que impliquen revisar y adecuar el funcionamiento de nuestra aplicación. 





En resumen, lo que buscamos es balance, la deuda técnica suele ser inevitable ya que aparece como consecuencia a la priorización de los esfuerzos en el desarrollo de software sujeto siempre al cumplimiento de plazos de entrega. Por ende, es importante determinar mecanismos y planificar tareas para asegurar la calidad actual y futura de lo que estamos programando.  Evitando la deuda técnica mientras aprendemos a programar: Tener presente las buenas prácticas de programación. Se recomienda utilizar una herramienta de tipo linter (Ejemplo ESLint) y de formateo de código.


Estar al tanto de errores y actualizaciones en las librerías y frameworks utilizados.


Emplear herramientas de versionado y efectuar registros sobre los cambios realizados en el código fuente. Esto permitirá efectuar un seguimiento e incluso restauración de versiones anteriores del proyecto si es necesario.


Martillo de oro


Por otro lado, el anti patrón del martillo de oro o martillo de Maslow es el resultado de la preferencia “por gusto” de cierta tecnología o solución frente a una situación no precisamente favorable para su empleo. 


Considerando el significante tiempo invertido en masterizar un lenguaje, librería o framework, es común que cuando nos posicionamos desde una zona de confort tengamos cierta preferencia a emplear un conjunto de herramientas y/o algoritmos.


No obstante, es importante identificar que gran parte de la tecnología de desarrollo fue construida con una finalidad. Lo que quiere decir, que el software se crea inicialmente con un objetivo. 


Por ejemplo, cuando se creó JavaScript se buscaba sumar interactividad a la web. A la fecha, la tecnología evolucionó de tal forma que podemos programar técnicamente cualquier cosa con el lenguaje: aplicaciones de escritorio, servidores web, VR/AR, etc.


Pero debemos interpretar que “poder desarrollar no implica desarrollar siempre de forma efectiva”: Si bien es posible desarrollar videojuegos con JavaScript plano y/o React, emplear un motor de videojuegos (como Unity) puede ser una mejor elección ante este tipo de proyecto.


En Coderhouse tenemos un Curso de Desarrollo de Videojuegos, un Curso para aprender Javascript y otro de React Js


Esto no quita que existan proyectos donde se pueden desarrollar videojuegos 2D con JS y React, solo que la decisión de “qué tecnología a emplear” debería estar sujeta a las características del proyecto y no solo de la preferencia tecnológica del desarrollador/a.


El mismo criterio podemos tomar para la codificación, el hecho de que anteriormente hayamos programados búsquedas, filtros, clases y eventos de cierta manera no significa que siempre lo vamos a hacer igual. No todos los problemas se resuelven con un martillo. 


Considerando que existe una instancia de análisis previo antes de la fase de desarrollo. El análisis de lo que buscamos construir nos permitirá determinar cuál es la mejor opción que tenemos para la solución actual. Evitando el martillo de oro mientras aprendemos a programar: Indagar sobre las fortalezas, limitaciones y enfoque de desarrollo de la librería y framework empleado.


Identificar la elección de la herramienta de desarrollo como un proceso variable, dependiente más de características particulares del proyecto (tipo de aplicación, plazos de finalización, presupuesto, limitaciones tecnológicas, etc.)


Código espagueti


Este concepto puede identificarse como el anti patrón producido por programar sin tener presente la importancia de la legibilidad y mantenibilidad del código fuente. Esto implica mirar un poco más allá del objetivo funcional del programa, no solo buscamos programar algo que funcione también pretendemos que sea fácil de estudiar y mantener.


Y decimos “fácil de estudiar” porque es importante reconocer que al hacer del desarrollo nuestro oficio, evolucionaremos constantemente como programadoras/es. Por lo cual volver a revisar una aplicación construida por nosotros mismo unos meses o un año después, puede ser todo un desafío si no somos organizados y metódicos a la hora de programar.


Cuando mencionamos código espagueti no solo es importante la organización del código, también que tan fácil es de interpretar al momento de una revisión. Se propone que el código sea auto explicativo con una apropiada inclusión de comentarios para guiar a otros desarrolladores/as (y a nuestro yo del futuro) sobre las características de las funcionalidades desarrolladas. 


Es común realizar revisiones de código de terceros cuando desarrollamos en equipo, por lo cual buscamos minimizar la existencia de un código desorganizado, ambiguo en términos de declaración y poco claro en los pasos o estados del funcionamiento.





Otra característica no menor a la forma de codificar se puede analizar desde el origen del término “lenguajes de programación”, los cuales, si bien nos permiten ordenar a la computadora que hacer, también son un medio para comunicar a miembros de nuestro equipo de desarrollo que “hace nuestro programa”. Y como toda comunicación puede estar condicionada por acuerdos entre los que utilizan el lenguaje.


Por ende, si bien existen normas generales para escribir las instrucciones, es importante reconocer que algunos equipos pueden definir reglas internas para determinar “Cómo se va escribir el código de la aplicación”.


Evitando el código espagueti mientras aprendemos a programar: Establecer sección y espaciados (indentación) que permita reconocer la utilidad y posicionamiento de las instrucciones de forma apropiada.


Emplear funciones con parámetros para simplificar la reutilización de bloques de código y clases para declarar objetos con propiedades y métodos personalizados.


Determinar una separación del código fuente, teniendo presente cuando empleamos cada script.


Conclusión


Como dijimos muchos de los anti-patrones son productos de supuestos de “performance”, “eficacia” y “rapidez” que se originan desde nuestra posición como usuario de aplicación o en búsqueda de mejores soluciones. Pero ahora que tomamos un rol activo en la industria de software debemos reconocer la importancia de :


Programar para otros: Nuestra labor como desarrolladores/as está determinada por las necesidades de nuestros clientes, siendo la programación una tarea condicionada por tiempo y recursos. Buscamos desarrollar lo mejor en el menor tiempo posible.


Programar con otros: El desarrollo de software se sustenta en el conocimiento colectivo, buscamos aprender de otros, compartir y comparar nuestras soluciones para ejercer mejor nuestro oficio. Es importante reconocer que ciertas prácticas de desarrollo deben ser revisadas y actualizadas de vez en cuando, en búsqueda de mejores resultados.


Por eso desde CoderHouse apostamos a que la formación constante en desarrollo y la continua revisión de lo que sabemos es el camino para consolidarnos como mejores programadoras/es. Conoce nuestros Cursos de Programación ¡Te damos 2 clases de prueba!