Desarrollo web: los 10 antipatrones de codificación que debe evitar

El diseño de la arquitectura de un sitio web o una aplicación, o la configuración de un flujo de trabajo de codificación efectivo a menudo nos hacen lidiar con problemas recurrentes. No es necesario que solucionemos estos problemas de diseño de software desde cero, ya que las soluciones en el nivel arquitectónico se pueden reutilizar de la misma manera que los fragmentos de código en el nivel micro .

Los patrones de diseño generalmente son soluciones reutilizables para ciertos escenarios, que pueden ser útiles para resolver problemas comunes y pueden ayudarnos enormemente a optimizar nuestro código.

Si bien los patrones de diseño son excelentes medios para mejorar nuestro proceso de desarrollo mediante el uso de fórmulas bien probadas, a veces también podemos equivocarnos con ellos. Estos se llaman antipatrones.

¿Qué son los antipatrones?

El término "antipatrón" fue acuñado en un libro llamado AntiPatterns en 1998. Se refiere a soluciones reutilizadas que inicialmente parecen útiles, pero que luego resultan más dañinas que beneficiosas.

Esto puede suceder por diferentes razones, por ejemplo, si no usamos los patrones en el contexto, entorno o tiempo correctos (las soluciones que fueron efectivas en el pasado pueden no funcionar siempre en el presente), o en otros casos, el paradigma completo fue malo desde el principio.

Los antipatrones también se denominan con frecuencia patrones de falla . La buena noticia es que es posible reconocerlos y evitarlos .

En este artículo veremos 10 antipatrones de codificación comunes en el desarrollo web que pueden hacernos creer que tenemos un código bien optimizado. (Tenga en cuenta que los antipatrones enumerados en esta publicación no son necesariamente los mismos que puede encontrar en el libro mencionado anteriormente).

1. Optimización prematura

Un buen momento es un factor crucial en la optimización del código. Podemos reproducir fácilmente el antipatrón de la "optimización prematura", si prestamos atención a pequeñas eficiencias y optimizamos para ellos demasiado pronto en el proceso de desarrollo, antes de que sepamos exactamente lo que queremos hacer.

Según la famosa cita de Donald Knuth, "la optimización prematura es la raíz de todos los males", lo que puede ser una exageración, pero aún muestra la gravedad de los problemas que puede causar la optimización prematura.

Si optimizamos el rendimiento antes de configurar una arquitectura efectiva, podemos reducir la legibilidad del código, dificultar la depuración y el mantenimiento, y agregar partes superfluas a nuestro código.

Para evitar una optimización prematura, es una buena idea seguir el principio de programación de YAGNI (No lo va a necesitar), que recomienda "implementar siempre las cosas cuando realmente las necesite, nunca cuando solo prevea que las necesita".

2. Reinventar la rueda

El antipatrón "reinventando la rueda" a veces también se denomina "diseño en el vacío" . Sucede cuando queremos hacer todo por nuestra cuenta y escribir todo desde cero, sin buscar métodos, API o bibliotecas que ya existan.

Reinventar la rueda no es solo una pérdida de tiempo, sino que las soluciones personalizadas, especialmente para las funcionalidades básicas, rara vez son tan buenas como las estándar que ya han sido probadas por muchos desarrolladores y usuarios.

3. Dependencia del infierno

Lo contrario de la antipatina "reinventando la rueda" es otro antipatrón común llamado "infierno de la dependencia" .

Si, en lugar de escribir todo desde cero, utilizamos demasiadas bibliotecas de terceros que dependen de versiones específicas de otras bibliotecas, podemos acceder fácilmente a una situación difícil de manejar cuando queremos actualizar, ya que estas dependencias subsidiarias son en muchos casos incompatibles. el uno al otro .

El infierno de la dependencia se puede resolver utilizando gestores de paquetes que puedan actualizar inteligentemente las dependencias interdependientes . Si el problema nos abruma demasiado, la refacturación también puede ser una buena idea.

4. Código de espagueti

El "código de espagueti" es probablemente el antipatrón de codificación más famoso. Describe una aplicación que es difícil de depurar o modificar debido a la falta de una arquitectura adecuada .

El resultado de un diseño de software deficiente es un grupo de código que es similar en estructura a un plato de espagueti, es decir, enredado y complicado . La legibilidad del código de spaghetti es muy baja, y por lo general es una misión casi imposible de entender cómo funciona exactamente.

El código de spaghetti generalmente proviene de la combinación de diferentes prácticas de codificación incorrecta, como el código que no contiene bloques de condicionales adecuados, que tiene muchas declaraciones goto, excepciones e hilos, que contienen partes que pertenecen a otro lugar, tiene relaciones mínimas entre objetos, tiene funciones o métodos que no pueden ser reutilizados, o no están documentados adecuadamente o no están documentados.

5. Programación por permutación

La "programación por permutación" o la "programación por accidente" ocurre cuando tratamos de encontrar una solución para un problema experimentando sucesivamente con pequeñas modificaciones, probando y evaluando una a una, y finalmente implementando la que funciona al principio.

La programación por permutación puede introducir fácilmente nuevos errores en nuestro código, peor aún, son errores que no necesariamente reconocemos a la vez. En muchos casos, también es imposible prever si la solución funcionará para todos los escenarios posibles o no.

6. Copie y pegue la programación

La "Copiar y pegar programación" se produce cuando no respetamos el principio de codificación No repetir (DRY), y en lugar de crear soluciones genéricas, insertamos fragmentos de código ya existentes en diferentes lugares y luego los editamos para que quepan en el contexto dado.

Esta práctica da como resultado un código que es altamente repetitivo, ya que las partes del código insertado generalmente difieren solo en discrepancias menores.

La programación de copiar y pegar no solo la realizan los desarrolladores principiantes, sino también los programadores experimentados, ya que muchos de ellos son propensos a usar sus propios fragmentos de código preprocesados ​​y probados para tareas específicas, que pueden dar lugar fácilmente a repeticiones involuntarias .

7. Programación de culto a la carga

El nombre de "programación de culto a la carga" proviene de un fenómeno etnográfico específico llamado "culto a la carga". Los cultos a la carga aparecieron en el Pacífico Sur después de la Segunda Guerra Mundial, cuando el contacto forzado con civilizaciones avanzadas llevó a los nativos a pensar que los productos fabricados, como Coca-Cola, televisores y refrigeradores traídos por buques de carga a las islas, fueron creados por seres sobrenaturales métodos; y si realizan ritos mágicos similares a las costumbres de los occidentales, la carga llena de bienes vendrá de nuevo.

Cuando cometemos el antipatrón de la programación de culto de carga, básicamente hacemos lo mismo. Usamos marcos, bibliotecas, soluciones, patrones de diseño, etc. que funcionaron bien para otros, sin entender por qué lo hacemos, o cómo funcionan exactamente dichas tecnologías.

En muchos casos, los desarrolladores simplemente hacen ritualmente lo que está de moda en ese momento sin ningún propósito real . Esta práctica no solo es mala porque hace que nuestra aplicación sea superfluamente hinchada, pero también puede introducir fácilmente nuevos errores en nuestro código.

8. Flujo de Lava

Hablamos del antipatrón de "flujo de lava" cuando tenemos que tratar con código que tiene partes redundantes o de baja calidad que parecen ser parte integral del programa, sin embargo, no entendemos completamente lo que hace o cómo afecta a toda la aplicación . Esto hace que sea riesgoso eliminarlo.

Suele ocurrir con el código heredado, o cuando el código fue escrito por otra persona (generalmente sin la documentación adecuada), o cuando el proyecto se movió demasiado rápido desde el desarrollo hasta la fase de producción.

El nombre del antipattern proviene de su ensamblaje con la lava proveniente de los volcanes, es decir, al principio se mueve de forma rápida y fluida sin tomar demasiadas precauciones, pero luego se solidifica y se vuelve difícil de eliminar.

En teoría, podemos deshacernos de los flujos de lava con extensas pruebas y refactorizaciones, pero en la práctica, la implementación es frecuentemente difícil o incluso imposible . Como los flujos de lava generalmente tienen costos de alto rendimiento, es mejor prevenirlos configurando una arquitectura bien diseñada y un flujo de trabajo sólido desde el comienzo.

9. Hard Coding

"Hard coding" es un antipatrón conocido contra el cual la mayoría de los libros de desarrollo web nos advierten en el prefacio. La codificación difícil es la práctica desafortunada en la que almacenamos datos de configuración o entrada, como una ruta de archivo o un nombre de host remoto, en el código fuente en lugar de obtenerlo de un archivo de configuración, una base de datos, una entrada de usuario u otra fuente externa .

El principal problema del código difícil es que solo funciona correctamente en un entorno determinado, y en cualquier momento las condiciones cambian, tenemos que modificar el código fuente, generalmente en varios lugares separados.

10. Soft Coding

Si hacemos todo lo posible para evitar la trampa de la codificación dura, podemos encontrar fácilmente otro antipatrón llamado "softcoding", que es exactamente lo contrario.

En codificación suave, colocamos las cosas que deberían estar en el código fuente en fuentes externas, por ejemplo, almacenamos la lógica de negocios en la base de datos. La razón más común por la que lo hacemos es el temor de que las reglas comerciales cambien en el futuro, por lo tanto, tendremos que volver a escribir el código.

En casos extremos, un programa de código blando puede volverse tan abstracto e intrincado que sea casi imposible de comprender (especialmente para los nuevos miembros del equipo), y extremadamente difícil de mantener y depurar .