Desarrollo web Los 10 antipatrones de codificación que debes 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 con frecuencia nos hacen enfrentar problemas recurrentes. No necesariamente tenemos que resolver estos problemas de diseño de software desde cero, ya que Las soluciones en el nivel arquitectónico pueden ser reutilizadas. de la misma forma como Fragmentos de código en el nivel micro.
Los patrones de diseño son generalmente soluciones reutilizables Para ciertos escenarios, eso puede son útiles para resolver problemas comunes, Y nos puede ayudar 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 ellas. Estos se llaman antipatrones..
¿Qué son las antipatrinas??
El termino “antipattern” fue acuñado en un libro llamado AntiPatterns en 1998. Se refiere a Soluciones reutilizadas que inicialmente parecen útiles., pero luego resulta hacer mas mal que bien.
Esto puede suceder por diferentes motivos, por ejemplo, si no usamos los patrones en el contexto, entorno o tiempo correctos (las soluciones que fueron efectivas en el pasado no siempre funcionan en el presente) o, en otros casos, todo el paradigma. fue malo desde el principio.
Los antipatrones también son llamados frecuentemente. patrones de fracaso. La buena noticia es que es Es posible reconocerlos y evitarlos..
En esta publicación, veremos 10 antipatrones de codificación comunes en el desarrollo web que pueden engañarnos y pensar que tenemos un código bien optimizado. (Tenga en cuenta que los antipatrones enumerados en esta publicación no son necesariamente los mismos que pueden encontrar en el libro mencionado anteriormente).
1. Optimización prematura
La buena sincronización es un factor crucial en la optimización del código. Podemos reproducir fácilmente el antipattern de “optimización prematura”, Si prestamos atención a las pequeñas eficiencias y las optimizamos 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 temprana es la raíz de todo mal“, lo que puede ser una exageración, pero aún muestra cómo los problemas serios de optimización prematura pueden causar más tarde.
Si optimizamos el rendimiento antes de configurar una arquitectura efectiva, podemos menor legibilidad del código, hacer depuración y mantenimiento más difícil, y añadir partes superfluas a nuestro código.
Para evitar una optimización prematura, es una buena idea seguir el principio de programación YAGNI (No lo vas a necesitar), que aconseja “siempre implemente cosas cuando realmente las necesite, nunca cuando simplemente prevea que las necesita.”
2. Reinventar la rueda.
los “reinventando la rueda” antipattern a veces también se conoce como “diseñando en un vacío”. Sucede cuando queremos hacemos todo por nosotros mismos y escribe todo desde cero, Sin buscar métodos, API o bibliotecas ya existentes..
Reinventar la rueda no es solo una cosa que perder tiempo, sino Las soluciones personalizadas, especialmente para funcionalidades básicas, rara vez son tan buenas como las estándar que ya han sido probados por muchos desarrolladores y usuarios.
3. Infierno de la dependencia
Lo contrario de la “reinventando la rueda” antipattern es otro antipattern común llamado “infierno de dependencia”.
Si, en lugar de escribir todo desde cero, utilizamos demasiadas bibliotecas de terceros que dependen de versiones específicas de otras bibliotecas, Podemos fácilmente enfrentar una situación difícil de manejar cuando queremos actualizar, ya que estas dependencias subsidiarias son en muchos casos incompatibles entre si.
La dependencia del infierno se puede resolver mediante el uso de administradores de paquetes que pueden actualizar inteligentemente las dependencias interdependientes. Si el problema nos abruma demasiado, la refactorización también puede ser una buena idea..
4. Código de espagueti
“Código de espagueti” Es probablemente el antipattern codificador 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 montón de código que tiene una estructura similar a un plato de espaguetis, es decir,. enredado y enrevesado. La legibilidad del código de espagueti es muy baja, y generalmente es una misión casi imposible entender cómo funciona exactamente..
Código de espagueti generalmente proviene de la combinación de diferentes malas prácticas de codificación, como el código que no contiene bloques condicionales adecuados, tener muchas declaraciones de goto, excepciones y subprocesos, que contienen partes que pertenecen a otro lugar, tiene relaciones mínimas entre objetos, tiene funciones o métodos que no se pueden reutilizar, o no están documentados correctamente o en absoluto.
5. Programación por permutación.
“Programación por permutación.” o “programación por accidente” sucede cuando intentamos encontrar una solución para un problema experimentando sucesivamente con pequeñas modificaciones, probándolas y evaluándolas una por una, y finalmente implementando la que funciona al principio.
Programación por permutación puede fácilmente introducir 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 anticipar si la solución funcionará para todos los escenarios posibles, o no.
6. Copiar y pegar la programación.
“Copiar y pegar la programación.” ocurre cuando no seguimos el principio de codificación No repetirte (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 se ajusten al contexto dado.
Esta práctica resulta en un código que es altamente repetitivo, Como las partes de código insertadas usualmente difieren solo en pequeñas discrepancias.
Copiar y pegar la programación no solo la cometen los desarrolladores novatos, sino también los programadores experimentados, ya que muchos de ellos son propensos a utilizar sus propios fragmentos de código pre-escritos y bien probados para tareas específicas, que puede conducir fácilmente a repeticiones involuntarias.
7. Programación cargo-culto
El nombre de “programación de carga-culto” proviene de un fenómeno etnográfico específico llamado “culto de carga”. Los cultos de 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 manufacturados, como Coca-Cola, televisores y refrigeradores traídos por los buques de carga a las islas, fueron creados por elementos sobrenaturales. metodos y si realizan ritos mágicos similares a las costumbres de los occidentales, la carga llena de mercancías volverá a aparecer..
Cuando cometemos el antipattern de la programación de carga de culto, básicamente hacemos lo mismo. Utilizamos marcos, bibliotecas, soluciones, patrones de diseño, etc. que funcionaron bien para otros., sin entender porque lo hacemos, o cómo funcionan exactamente dichas tecnologías.
En muchos casos los desarrolladores solo Haz ritualmente lo que es la cadera en ese momento sin ningún propósito real. Esta práctica no solo es mala porque hace que nuestra aplicación esté superflua, sino que también puede introducir fácilmente nuevos errores en nuestro código..
8. Flujo de lava
Hablamos de la “flujo de lava” antipatrón cuando necesitamos lidiar con el código que tiene partes redundantes o de baja calidad ese parece ser integral Al programa, sin embargo, no entendemos completamente qué hace o cómo afecta a toda la aplicación. Esto hace que sea arriesgado quitarlo..
Suele pasar con código legado, o cuando el el código fue escrito por otra persona (generalmente sin la documentación adecuada), o cuando el proyecto se movió demasiado rápido desde la fase de desarrollo a la fase de producción.
El nombre de antipattern proviene de su parecido con la lava que proviene de los volcanes, es decir, al principio se mueve rápida y fluidamente 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 pruebas extensas y refactorización, pero en la practica, La implementación es frecuentemente difícil o incluso imposible.. Como los flujos de lava suelen tener altos costos de rendimiento, es mejor prevenirlos configurando una arquitectura bien diseñada y un flujo de trabajo sólido desde el principio.
9. Codificación dura
“Código difícil” es un antipattern bien conocido contra el cual la mayoría de los libros de desarrollo web nos advierten directamente en el prefacio. La codificación dura es la desafortunada práctica en la que Almacenamos datos de configuración o de 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 con el código duro es que Solo funciona correctamente en un entorno determinado., y en en cualquier momento las condiciones cambian, necesitamos modificar El código fuente, usualmente en múltiples lugares separados..
10. Codificación suave
Si nos esforzamos mucho para evitar la trampa de la codificación difícil, podemos encontrarnos fácilmente en otro antipattern llamado “codificación suave”, cual es su opuesto exacto.
En codificación suave, Ponemos cosas que deberían estar en el código fuente en fuentes externas., por ejemplo almacenamos lógica de negocios en la base de datos. La razón más común por la que lo hacemos es el temor a que las reglas de negocios cambien en el futuro, por lo tanto, tendremos que volver a escribir el código.
En casos extremos, un programa codificado suave puede volverse tan abstracto y complicado que es casi imposible comprenderlo (especialmente para los nuevos miembros del equipo), y extremadamente Difícil de mantener y depurar.
