Un anti-patrón es una solución repetitiva incorporada o aprendida para la cual se demostró que lejos de resultar una buena solución para un problema (como aparentaría en un principio) genera mas problemas que los que soluciona. Mientras que el concepto se popularizo como anti-patrón de diseño con orígenes en el libro Design Patterns, el concepto de anti-patron se utiliza en variedad de escenarios como en la programación (ej: el infame Codigo spaghetti), project managament (ej: Groupthink)
Anti-Patrones como Patrones Legacy
Algunos (¡y muchos!) anti-patrones como Waterfall model (Desarrollo de software en cascada), son practicas o patrones generalmente aceptados y enseñados en viejas épocas y que ahora al quedar obsoletos fueron reemplazados por otras practicas mas eficaces (Desarrollo iterativo, metodologías agiles, etc...) . A pesar de eso viejas practicas quedan en el knowhow colectivo y lo importante es saber reconocerlos como anti-patrones y no como una practica que haya que fomentar (y también saber cuales son las practicas que son convenientes por estos tiempos).
Anti-Patrones en Control de versiones
Como se había mencionado anteriormente, el concepto de anti-patrón se extendió rápidamente a variedad de entornos, siendo uno de ellos el mundo de las versiones (o como algunos le dicen, SCM), un área del desarrollo de software que crece mas lentamente que otras (el porque de esto seguramente lo tratare en algún que otro post).
A pesar de no haberse desarrollado mucho, SCM (o abreviado CM) fue un ciencia/brujería/técnica que paso por varias fases a lo largo de su historia pasando por herramientas que solo servían para trabajar individualmente, sistemas de control de versiones concurrentes para equipos (CVS :P), sistemas centralizados mas avanzados para dar mejor soporte a ramas aunque no sea lo suficientemente bueno (ej: SVN), sistemas distribuidos (ej: Mercurial) (para información detallada vean este excelente articulo acerca de la historia del source control).
Esta historia es la que habilita la posibilidad de que determinadas buenas practicas muy comunes y que resultaban satisfactorias ayer sobrevivan mas allá de su obsoletización para convertirse en anti-patrones hoy.
Esta historia es la que habilita la posibilidad de que determinadas buenas practicas muy comunes y que resultaban satisfactorias ayer sobrevivan mas allá de su obsoletización para convertirse en anti-patrones hoy.
Los Patches que se usaban antes
Una de las practicas que fue muy utilizada durante un tiempo fueron los patches, sobretodo en los entornos de desarrollo open source, en épocas donde la internet estaba en pañales y cosas como codeplex, github, googlecode no existían ni en la imaginación (es mas, muchas de esas compañías ni siquiera existían), cuando alguien realizaba una contribución a un proyecto lo que generalmente este hacia era generar un patch (que no es mas que un .tar.gz o .zip del diff entre determinadas versiones y/o el contenido de esas versiones) y posteriormente se lo hacia llegar, era común mandarlos por email firmados, adjuntarlos en foros, BBS, etc... En definitiva, no existía el concepto de "commitear a un repo en la nube".
El "Make a zip" que se usa ahora
El "Make a zip" que se usa ahora
Posteriormente exploto la internet, llegaron los servicios, se estabilizaron y herramientas como SVN pudieron cobrar mas protagonismo, yo por ejemplo usaba el servicio de http://www.assembla.com/, que por esos momentos ofrecia SVN (estamos hablando del 2006 aprox.).
Sin embargo, existía cierta "cosa" por la cual "commitear al repo" no era tan frecuente, estaba (y esta) vigente Continuous Integration, una excelente herramienta para llevar a cabo proyectos integros aprovechando al máximo un versionador, pero que inadvertidamente dejaba varios asuntos de lado.
Uno de esos asuntos es el intercambio de código "unmanaged", es decir, código que no debería ser parte de la mainline en ese momento, pero que lo seria en el futuro o que tiene que por diversas razones tiene que "estar en algún lugar".
Noten que hasta el momento no use la palabra con B.
Entonces, generalmente es fácil caer en este razonamiento: "Si ahora se esta usando un repositorio para compartir una mainline, y eso es fabuloso, entonces como envió el código que no tengo que commitear por H o por B razon ? Uso lo que ya conozco, y hago un patch para poder enviar el contenido" ( o en otras palabras, hacer un zip ) lo cual parece que es algo bueno porque era una practica normal y promovida en las viejas épocas, y al trabajar con sistemas de control de versiones centralizado como el mas popular de esa generacion (svn) incluso yo creo que trabajar con codigo "unmanaged" de esa forma es mas practico que hacer branches la mayoria de las veces.
Pero la practica de realizar patches, en DVCS's como Mercurial o Git solo existe como una practica legacy, un anti-pattern (aunque siempre habrá excepciones, pero deben ser las menos y muy poco frecuente). En herramientas distribuidas de versionamiento, las soluciones alternativas al problema del código "unmanaged" están a mano y es mas facilitada por la herramienta que ofrece alternativas mas practicas que el uso de patches, mails con código o archivos zip y por supuesto mas practicas que las soluciones ofrecidas por herramientas de generaciones anteriores.
Intercambiar código con otros desarrolladores solamente a travez del repositorio y usar otros métodos solo para los que por alguna razón no puedan, no deseen, o no sepan como acceder al repositorio.
