7 antipatrones del desarrollo de software y como prevenirlos

La única forma que un proyecto software tenga éxito, es que este posea primero, calidad interna y luego calidad externa.

¿Pero qué es la calidad interna?

La calidad interna se refiere a todos los posibles problemas que tienes o puedes tener que no son visibles por el usuario final, pero que pueden tener un profundo impacto en la mantenibilidad de los sistemas que estemos construyendo. Cosas como consistencia, test coverage, legibilidad, refactoring.

Mientras que la calidad externa es lo que es percibido por los usuarios del los sistemas que construimos, un sistema lento, con interfaces de usuario no intuitivas o diseño feo son ejemplos de mala calidad externa.

Ahora es cuando esto se pone interesante, si un producto posee buena calidad interna puede ser que este no posea buena calidad externa, pero si este no posee calidad interna será prácticamente imposible que el producto que estás construyendo tenga buena calidad externa por la simple razón de que es difícil construir algo de calidad sobre cimientos podridos.

Antes de continuar, puedes leer este post o ver y escuchar esta información en formato de video en nuestro canal de Youtube, te dejamos el link por si prefieres este formato. 😃 👍

Hola mundo y bienvenidos a este post, a veces nosotros pensamos que podemos alcanzar nuestra meta si tomamos atajos en nuestro código, y con esto no me refiero a atajos de teclado, me refiero a las malas prácticas, al copy paste, a eso que tú sabes que está mal, o que quizás no lo sabías en su momento, pero más adelante te empieza a dar dolores de cabeza porque no sabías que eso te iba a generar problemas más adelante.

A este concepto se le conoce como deuda técnica, pero también existen otros problemas que no nos permitirán a avanzar a nuestro máximo potencial. Y para que tú no cometas los mismos errores que cometí yo… porque sí… también cometí estos errores en algún momento de mi vida, hoy veremos 7 anti-patrones en desarrollo de software.

7. Monster commits o monster PR:

Un monster commit es un cambio que se trata de pasar a la rama de master, pero este posee muchas funcionalidades en él o una gran funcionalidad que podría haber sido dividida en pequeñas funcionalidades.

Un pull request es una propuesta que puede ser incluida en tu repositorio, pero antes que eso es una conversación, es una instancia perfecta para aprender, sugerir mejoras al diseño y también buscar y prevenir potenciales errores que se puedan incluir.

Cuando un pull request es muy grande, hace que estas conversaciones y la revisión de este sea más difícil y puede hacer que el pull request se encuentre en revisión por más del tiempo necesario. Además de que, al estar modificando más código, el riesgo a introducir un bug o mala práctica a producción es mayor.

Si aún no te suena conocido este tema o quieres mejorar en el uso de la herramienta Git, te recomendamos tomar nuestro curso Git: sin fronteras

6. Lava flow:

Codigo de investigación o funcionalidades incompletas por algun motivo llega a produccion,. Esto puede ocurrir por diversas razones, pero la primera es cuando estas siempre contra el reloj pero luego te piden dejar eso botado y comenzar con otra funcionalidad.

Este problema empieza a generar código muerto o peor aún, código que solo realiza procesamiento, pero todo ese procesamiento y consultas que hizo, no llega a puerto. Esto se soluciona destinando más tiempo al equipo de desarrollo para que pueda terminar las funcionalidades, y el código que sea de investigación, dejarlo siempre en una rama, este nunca debe pasar a master.

5. Tester-driven development:

Esto es donde nuevos requerimientos son definidos en la etapa de pruebas.

El nombre de este antipatron es una ironía al patrón de diseño test driven development, donde en este último son los tests los que indican las funcionalidades y código a implementar, mientras que en Tester-driven development se le entrega el poder al QA para que este pueda ir agregando requerimientos con base en lo que él va descubriendo o le parece mejor en la fase de pruebas.

Esto lo que hace es que los proyectos después teniendo plazos ridículos de entrega, esto se soluciona planificando las pruebas antes de comenzar con el desarrollo.

4. Apropscalypse:

Cuando a un componente o función posee muchas propiedades o argumentos.

Las propiedades de un componente o los argumentos de una función alteran el comportamiento de este. El problema que se genera cuando tenemos funciones o componentes con múltiples propiedades es que este puede extenderse y terminar siendo un componente muy grande o difícil de razonar.

const fn = (user, product, owner, style, isDisabled, shouldContainPass, salt, ...rest) => {
}

Esto se soluciona creando funciones pequeñas y componentes pequeños.

3. Cargo cult programming:

El término Cargo Cult Programmer puede aplicar cuando desarrolladores con poca o sin experiencia copia código de un lado a otro, sin necesariamente entender lo que este código realiza. ¡Sí, te estoy hablando en especial a ti! copy/pasteador de stackoverflow. No te sientas mal, yo también lo hice y todos lo hicimos en algún momento.

Este término también se aplica cuando se sigue ciegamente un patrón o estándar de código sin entender la razón que existe detrás de ese estándar o ese patrón. Esto se soluciona dando un paso atrás y analizando por qué estamos implementando A o B y si este lo soluciona, aunque siempre debes seguir los lineamientos de código y patrones de la empresa, si es que esta los tiene.

2. Spaghetti code:

Spaghetti code es un término peyorativo para referirse a código con falta de estructura y que este es difícil de mantener.

También se utiliza cuando en POO, los métodos de las clases son excesivamente largos y desordenados, dando la sensación de código en estilo de procedimiento. Otra forma de identificar Spaghetti code es sencillamente viendo el código e intentar de identificar si este tiene una estructura fácil de seguir, si no, lo más probable es que sea Spaghetti code, sin embargo nunca le digas a otro desarrollador que su código parece una cena italiana. Lo mejor es ayudarlo a que él le dé una estructura a su código, de manera que este parezca más ordenado.

1. Premature optimization:

Optimizar antes que sea necesario. Las optimizaciones que se realizan al código son por lo general complejas y deben ser planificadas. Sin embargo, estas disminuyen la legibilidad y mantenibilidad. Por lo que no debería considerarse agregar optimizaciones a tu código, a menos que sea necesario.

Donald Knuth, quien es considerado informalmente el Premio Nobel de las Ciencias de la Computación, menciona que debiésemos olvidarnos de pequeñas optimizaciones, ya que el 97% del tiempo la optimización temprana esa la raíz de todos los males, pero que, sin embargo, no debemos dejar pasar por alto la optimización en ese crítico 3%.

Por lo que una forma más apropiada para saber cuándo realizar una optimización y cuándo no es al final del ciclo de desarrollo, cuándo se empiezan a realizar las pruebas de estres.

Ya vimos los antipatrones, pero si quieres conocer el otro lado, es decir, «patrones de diseño y como implementarlos» , te dejaremos el link al post: Los 6 patrones de diseño más utilizados en la industria y si quieres otro post mas por si te interesa saber ¿Cómo escribir código como un programador senior? con consejos que debes de tomar en cuenta para mejorar.

Y esto ha sido todo de este post, si te ha encantado, ¡golpea al botón de me gusta!, dejanos un comentario, y visita nuestra Academia Hola Mundo, donde encontrarás todos los cursos para formarte como un desarrollador o desarrolladora.

Y para no perderte nada, no olvides suscribirte a este blog, seguirnos en todas las redes como Youtube, Twitter e Instagram, y por último, te invitamos a escuchar nuestra música «Hola Beats«, diseñada para ayudarte a concentrarte y acompañarte en tu aprendizaje o trabajo, la puedes encontrar en Spotify, Apple Music, Amazon Music, Youtube Music y Deezer.

¡Hasta la próxima!, y chao mundo