Antipatrones (o antimarranadas)

Patrones de diseño de Software hay y muchos, en el artículo de la wiki son todos los que están, pero no están todos los que son, la lista es en realidad mucho más larga.
Ya que estamos de Vacaciones, hay tiempo de ponerse filosófico, el post de hoy trata sobre antipatrones de diseño, y no sobre patrones. La reflexión que hago es que tan importante o más es saber como no se deben hacer las cosas, que saber un patrón en concreto. Por poner un ejemplo, con el patrón singleton podremos resolver un problema de sección crítica en un lenguaje orientado a objetos, pero también podremos resolverlo de otras formas en un lenguaje funcional. Es decir que un patrón es una solución a un problema, pero no la única.

Sin embargo si hay un consenso universal sobre los antipatrones, que traducido a lenguaje llano quiere decir "No hagas marranadas". Si entras en un nuevo proyecto que utiliza el patrón X podrás adaptarte a gusto, sin embargo si tienes el legado de un programa que hace uso de antipatrones vas a odiar al programador que lo hizo y las horas que pasas con el mismo; esto es algo que a muchos programadores nos ha pasado alguna vez, y creo que también coincidiremos en esta sensación.

Cito algunos de los antipatrones más comunes, con los que casi todos nos hemos topado:

Botón mágico   Incrustar la lógica de la aplicación en el clic de un botón. Un secreto inconfesable de la mayoría de los principiantes.

Código espagueti Otro secreto inconfesable de los principiantes. En los años 90, cuando aun no existian frameworks web, era algo inevitable.

Cadenas mágicas Cadenas de texto "inteligentes" que determinan el flujo del programa, definen sesiones etc. Es un pecado cometido incluso por los generadores de código, por ejemplo el propio visual studio 2012 lo hace con el scaffolding y con los links a las vistas. Esto puede dar lugar a muchos errores tontos por errores tipográficos. Deben substituirse por constantes.

Programación por excepción y Ocultación de errores   Programar la lógica a base de Try/Catch, y para asegurarse, en caso de que falle algo imprevisto, no mostrar ningún mensaje de error. Así el programador cree que se lava las manos.

DRY (Don't Repeat Yourself): Copiar/Pegar código en un programa. Muy típico.

Reinventar la rueda: Aveces a los programadores nos gusta más inventar nuevas soluciones a un problema, que buscar si ya existe una solución para ese problema. Terrible error muy antiproductivo.