Ayer, en una conversación telefónica, en la busca de nuevo contrato, me sorprendieron con algo que no me esperaba porque por mi experiencia la mayoría de las personas no se para demasiado a leer tu CV. Más concretamente me comentaban que les había chocado un artículo con el nombre "The Dangers of Design Patterns".
Los peligros de los patrones de diseño es un artículo que escribí hace casi ya seis años y que sigue todavía vivo gracias a javaHispano. La verdad es que a diferencia con otros artículos que he escrito, y que van caducando con los años, creo que a medida que pasa el tiempo este artículo es más y más válido.
Parafraseando una de las partes del artículo, y pidiendo perdón por adelantado por "quotearme" a mi mismo lo que me resulta algo pedante:
Las empresas no buscan arte sino pragmatismo.
La sobreingeniería creo que es algo en lo que muchos hemos caído. Al menos a mi, mirando hacia atrás, me es fácil recordar ocasiones en las que he pecado de diseño exagerado y utilizado abstracciones y patrones que no eran necesarios, simplemente por la razón de que la aplicación no necesitaba ninguna extensibilidad, no se iba a integrar realmente con ningún sistema externo, no iba a funcionar como un framework sobre el que se construirían nuevas aplicaciones, y en resumen no entraba dentro de esos casos donde sí que es realmente importante aprovechar toda la potencia creativa que nos ofrecen los patrones de diseño. Eran simplemente aplicaciones que había que crear rápido y en las que está bien aprovechar los patrones más útiles, pero en las que quizás el encadenar 10 patrones seguidos puede complicar bastante las cosas, especialmente cuando llegan programadores junior a mantener la aplicación.
Personalmente creo que el encontrarse con desarrolladores que practican sobreingeniería no es algo malo. Creo que muestra una cosa: interés. Me encanta encontrarme con desarrolladores excitados con la creación de nuevas obras de arte en el software porque indica una cualidad muy importante que la mayor parte de la gente que se dedica a esta profesión carece: pasión por el software. Definitivamente prefiero encontrarme con alguien que practique sobreingeniería que con alguien al que le importe un comino lo que está escribiendo.
Mirando hacia atrás en la época del artículo es interesante ver también como con el paso del tiempo han ido apareciendo frameworks como Spring que nos protegen de complicar nuestros diseños con un uso inadecuado de los patrones de diseño. Spring te ofrece montones de patrones de diseño que están ahí listos para utilizar y lo que es más importante que están correctamente programados y con la complejidad justa y necesaria. Patrones como Singleton, Observer, Proxy u otros como DAO o Dependency Injection y otros muchos están ahí listos para utilizar con su complejidad adecuada, porque aunque a mucha gente patrones como Singleton le podían parecer supersencillos a la hora de la verdad resulta que no era tan fácil implementarlos correctamente. Punto para Spring a este respecto.
Otro punto importante que se me viene a la mente es la importancia de disponer de un buen arquitecto en la empresa. El arquitecto, o los programadores senior, deben ser los encargados de poner ese punto justo de coherencia y sentido común en el desarrollo de las aplicaciones, ya sea a través de diseños ajustados, de revisiones de código, reuniones de desarrollo o cualquier otro método, pero siempre desde un punto de vista constructivo y aportando el valor de la experiencia.
Es muy interesante ver como el desarrollo de software ha evolucionado durante estos últimos años. Palabras como ágil y pragmatismo se han vuelto bastante comunes en el desarrollo de software. Pero ojo que ninguna de ellas significa no utilizar patrones sino utilizarlos en su justa medida, como la sal. Me gustó recordar este artículo ayer.
PS: Que curioso que buscando en Google he descubierto una crítica a mi artículo publicada nada más y nada menos que en el 2003. Me ha parecido muy interesante leerla y tiene también muy buenos puntos, aunque creo que fue una respuesta ligada más al título del artículo (probablemente mal escogido) que al contenido donde se carga continuamente contra la sobreingeniería, el no estudiar profundamente los patrones existentes y los que van apareciendo y el no analizar como aplicarlos adecuadamente. Todas las opiniones tienen valor, pero está claro que los patrones desde el punto de vista de un curso de ingeniería del software, se apliquen como se apliquen, se combinen como se combinen, siempre van a ser buenos :)
comments
2 Respuestas a "Los peligros de los patrones de diseño"14:45
Así que el amigo Nelson también te toca a tí las narices... je,je, hay que ver como le gusta meterse en camisa de once varas...
Nelson Medinilla fue mi tutor en mi proyecto fin de carrera y fue mi mentor en el mundo de la orientación a objetos 'con sentido'. He tenido muchas conversaciones y discusiones con él y dialécticamente es muy superior a mi. Sin embargo, siempre le ha gustado mi manera de ver la realidad del software y aplicarla en la empresa. He tenido el orgullo de dar una charla a sus alumnos de Ingeniería del Software, y he tenido todavía más suerte todavía por haber podido llevarme a varios becarios a Amplía Soluciones (los mejores becarios sin duda, los más inquietos).
A finales de los noventa era un auténtico outsider dentro de la Facultad de Informática, y puso todo el alma en mi proyecto porque era 'rompedor'. Creo que el tiempo ha ido poniéndole en una posición más en el establishment de la universidad (porque es un adelantado y el tiempo hace su trabajo).
Si quieres que te diga la verdad sobre los patrones, a mi me la sudan. No son necesarios para hacer buen software. Son necesario para COMUNICARSE con el resto de los miembros de un equipo de desarrollo o de otros equipos de desarrollo. Antes de conocer los patrones de diseño ya usaba el patrón Observador en C++, por ejemplo, aunque no lo llamaba 'Observador'. Y así con alguno más. Bueno, leyendo sobre ellos aprendes y encuentras un camino más ràpido para aplicarlos, lo cual está bien. Pero en mi opinión el verdadero valor de los patrones es que se puede expresar algo tan abstracto como el software mediante la comunicación oral y escrita tradicional. Nada más (¡y nada menos!)
15:29
Diego, ya es casualidad :)
En realidad no me ha molestado el artículo, sobre todo porque lo he leído ¡después de cuatro años! Si llego a leerlo hace cuatro años sí que me habría encabritado :)
Estoy totalmente de acuerdo con lo que comentas sobre su valor comunicativo. La herencia que han dejado es que todos pensemos en lo mismo cuando alguien habla de un Singleton, un Proxy o un Decorator. Casi nada.
Yendo un poco más allá, me he encontrado con que uno de los casos donde el uso de patrones es realmente importante es a la hora de exponer un API hacia el exterior. La capacidad semántica que nos ofrecen los patrones nos da una herramienta herramienta para crear APIs descriptivas que faciliten la integración entre sistemas lo que a la hora de la verdad se traduce en menos días de despliegue y menos dinero gastado.
Publicar un comentario