Estos días atrás, en varias reuniones con mi jefa, ha salido varias veces el mismo tema. El problema es que los dos o tres del departamento que tienen fama de saber mucho java, mucha orientación a objetos, mucho de patrones de diseño y de ser los que mejor programan, hacen un código que los compañeros no entienden fácilmente. Y efectivamente es así. El código que hacen esas personas también tiene fama de ser muy dificil de seguir, mantener o modificar por otras personas que no sean ellos mismos.
Hay otros compañeros, sin embargo, que no saben tanto de orientación a objetos o de patrones de diseño, pero su código es más simple y más fácil de entender, pero muchísimo menos reutilizable.
¿Cual es el motivo?. Le he estado dando vueltas y me hace la impresión que es algo similar a lo que comenté en el post anterior de que programar es como escribir.
Quitando a los que comenten faltas de ortografía, hay quien se centra en el problema concreto que tiene y con un código "lineal", con un mínimo de orientación a objetos y un mínimo de patrones de diseño, resuelve eficientemente el problema, de una forma rápida. Ese código funciona bien, se hacen unas pocas clases sencillas, pero grandes y, por ello, es fácil de entender: va todo seguido y no hay que rebuscar entre varias clases, interfaces y polimorfismos variados para ver qué hace. Está todo ahí y se ve. Pero esas clases sólo sirven para eso y no se pueden usar en más sitios. Esto sería el equivalente a escribir en prosa con una prosa eficiente.
Otros, menos prácticos pero con más conocimientos, para resolver el mismo problema, montan toda una estructura de clases e interfaces. Posiblemente el diseño de estas clases es mucho más orientado a objetos y más elegante desde ese punto de vista que en el caso anterior. Algunas de esas clases son lo suficientemente generales como para usarlas en otros sitios. Sin embargo, tardan más en hacer el código y hay menos gente capaz de entenderlo sin leerse previamente un buen manual del diseño del mismo, incluso aunque sean gente con profundos conocimientos de OO y patrones. Esto sería el equivalente a escribir poesía, donde se da especial importancia al cómo se cuentan las cosas.
Llega el tiempo de hacer modificaciones por la misma persona que ha hecho el código. En general, cualquier modificación se hace más rápido en el segundo caso, en el de la orientación a objetos, si hay un buen diseño. Sin embargo, hay veces que esta modificación cuesta mucho más en este segundo caso. ¿Por qué? Nuevamente por el tema de darle demasiada importancia a la forma. A veces la modificación que se pide se hace fácilmente añadiendo una dependencia de una cosa totalmente extraña a nuestro diseño (un dato que no tiene nada que ver, una clase que es muy especifica del proyecto, etc). Para la primera persona en cuya cabeza está el resolver el problema lo antes posible, añadir esa dependencia no le cuesta nada, la pone y ya está. Sin embargo, para la segunda persona, añadir esa dependencia le supone un trauma de concepto. Se niega a ponerla puesto que ese dato no pega nada ahí y tiene que rehacer el diseño para contemplar esta nueva posibilidad de una forma elegante con el conjunto. Lo que a la primera persona le puede costar diez minutos "ñapear", a la segunda le puede costar un par de días.
Y al final llega la gran cuestión. ¿eficacia o elegancia?. ¿No estará justificado ñapear de vez en cuando para conseguir un código más simple en apariencia o cumplir plazos?. Supongo que como siempre, en el punto medio está la virtud. No hacer ñapas sangrantes, pero tampoco ser demasiado puristas con la orientación a objetos. Y me hace la impresión que esto es lo que ha llevado a los gurus a una de las bases de las metodologías ágiles y a cosas como el TDD. Si nos fijamos, en estas metodologías suelen ser comunes cosas como "resuelve tu problema lo más rápido y de la forma más sencilla posible", no hagas cosas generales "por si en un futuro las usas". Hay que centrarse en y resolver el problema de ahora. El del futuro hay que resolverlo cuando se presente haciendo refactoring si es necesario. El diseño se debe ir haciendo justo antes de programar y sólo para resolver el problema concreto del momento.
Cada vez estoy más convencido de que aprender un lenguaje de programación es fácil, pero aprender a programar puede llevar toda una vida.
Te encuentro toda la razón, cuando tienes un area comercial presionandote para producir lo mejor es tener a mano clases simples y reutilizables.
Pero siendo amante de la programación es dificil programar asi ya que el trabajo se transforma en algo monótono y repetitivo.
Yo estaría más del lado de la «elegancia» a la hora de programar, aunque con matices, puesto que sí es cierto que siguiendo los protocolos y las formas te puedes perder. Por eso no me gustan nada las interfaces, aunque reconozco que son necesarias para cierto tipo de programación (por ejemplo si se tiene pensado usar plugins que adapten funcionalidades según ciertos requisitos). Sin embargo no creo que seguir un patrón OO haga que pierdas tiempo, aunque todo depende desde el punto de vista que se mire (si ves todo el proyecto, o sólo quieres pasar el trago actual lo más rápido posible). De todas formas, pillar el truco de seguir un soft OO es cuestión de práctica y la la larga se hace mucho más fácil de leer que algo procedural.
Hola:
Un patrón OO es bueno para la reutilización posterior, pero desde luego, en el momento de hacerlo tardas más que si lo haces sin él. El problema es saber si realmente luego vas a reutilizar eso en algún sitio o se va a quedar en nada. En el primer caso, has perdido un poco el tiempo al principio, pero lo recuperas después. En el segundo caso, símplemente has perdido el tiempo y «ofuscado» un poco el código.
Se bueno.