Empirismo en antipatrones

Empirismo en antipatrones

Jessica Elizabeth Arvizu Torres #2499028

1. En los primeros cuatrimestres desarrollamos un proyecto para una clase. Incluía servicios web, documentación y desarrollo móvil. En ese entonces caí en el antipatrón de copiar y pegar, ya que no conocía mucho sobre el tema de desarrollo. Muchas de las cosas que fueron implementadas en el proyecto solamente servían para ese proyecto, ya que iban programadas de acuerdo a lo que el proyecto pedía y no fueron creados como soluciones genéricas.

Este mismo proyecto tenía el antipatrón de flujo de la|va y el de ancla de barco, porque al copiar y pegar las cosas, realmente no sabía cuáles funcionaban y cuales no, y dejaba muchísimo código que no utilizaba pero, cuando intentaba borrarlo había errores que no sabía reparar y optaba por dejar todo como estaba, aunque realmente hubiera funciones que no sirvieran para el objetivo del proyecto.

Estos antipatrones pudieron haberse corregido o evitado si en su momento no hubieramos copiado y pegado código, sino que nos debimos haber puesto a leer o entender el código que estabamos utilizando; no tenía tanta experiencia como para realizar las cosas yo sola, así que buscaba soluciones en internet pero tampoco me daba a la tarea de ponerme a entender lo que estaba copiando.

1. En otro de los proyectos en los que participé me tocó estar en el área de FrontEnd, mejorando la interfaz de usuario. Este proyecto ya estaba “terminado” antes de que yo entrara en él, por lo que conocía muy poco la estructura interna de este.

En un módulo de la aplicación, se encontraba el antipatrón de humo y espejos: ese módulo no funcionaba en realidad, pero estaba programado como que hacía lo que pedía. Este mismo módulo tenía el antipatrón de inversión de la abstracción, porque el módulo no cumplía lo que el usuario quería, y al momento de que yo tuve que cambiar la interfaz, algo sucedía que el módulo no funcionaba, y tuvieron que volverlo a programar.

Estos antipatrones pudieron haberse evitado si la persona que realizó la aplicación hubiera tenido más tiempo para programarla, ya que me habían dicho que esa persona realizó todo en un solo día. No le había importado nada la interfaz gráfica y había hecho lo que él entendía. Estos antipatrones se corrigieron hasta el momento de que todos vieron internamente la aplicación, y que estaba programada de una manera que no iba a poder ser mejorada en el futuro o cambiada sin tener que cambiar otra cosa primero.

1. En otro de los proyectos que he participado, un programador aplicó el antipatrón de reinvención de la rueda cuadrada porque “solucionó” un problema que había pero lo hizo de manera rápida, solamente para que pudiera decir que el problema fue solucionado.

Cuando otro programador quiso meterle mano al código, se dio cuenta de que nada lo que había hecho el programador anterior servía, por lo que él tuvo que hacer su componente y el componente del compañero.

Este error se pudo haber evitado si el primer programador se hubiera dado a la tarea de investigar un poco, para ver si lo que estaba haciendo estaba bien hecho o le servía a las demás personas.

...