Sin diseño

Ando ahora liado, empezando un nuevo proyecto en el trabajo, algo ambicioso porque pretendo hacer algo que sirva para varios proyectos.

El tema del diseño me desborda y puedo pasarme pensando en UML y papeles un montón de tiempo para al final posiblemente llegar a un diseño más general y más complicado de la cuenta. También estoy bastante seguro de que ese diseño luego no sirve para nada o, al menos, cuanto más código se vaya haciendo, menos se parece al diseño.

Así que he decidido no hacer grandes diseños. Voy a tratar de seguir algunas de las filosofías de las metodologías ágiles, programación extrema y demás.

Trataré de ponerme hitos (historias de usuario, casos de uso o cómo queramos llamarlos) cortos y trataré de con un diseño mínimo, resolver esos hitos de la forma más rápida y directa posible en el código. Eso sí, pensando en rehacer/modificar el código ya hecho a menudo, según se vayan añadiendo hitos, trataré también de hacer clases de test unitario, con JUnit o similar.

Desde luego, será más divertido que el pasarse pensando en el diseño varios días, semanas o meses, con la duda continua de si se te olvida algo o no, si será lo suficientemente general o no.

Me siguen quedando las dudas de si haciéndolo de esta manera obtendré algo lo suficientemente general para varios proyectos, pero al menos esa preocupación no será el agobio de pensar en abstracto, sino agobio de cosas por (re)hacer en el código. Si el rehacer código se hace desde el principio, poco a poco según se vayan planteando las necesidades con los nuevos hitos, espero que tampoco será demasiado gravoso.

De todas formas, esto es lo que siempre acabamos haciendo, ya que los diseños que se hacen al principio no se siguen ni siquiera el primer día que se empiza a programar.

Ya iré contando la experiencia....

Diseño del software

La verdad es que cada vez estoy más desilusionado con el diseño de software, el uml, metodologías de desarrollo y todo lo demás.

Es cierto que se necesita pensar antes de ponerse a codificar, tener claro que se quiere hacer, pensar posibles soluciones y elegir la mejor. Lo que cada vez me parece perder más el tiempo es escribir todo eso en papel antes de codificar, hacer diagramas uml, de clases, de secuencia, etc.

Ojo, sí es conveniente de vez en cuando hacer un diagrama, pero yo creo que basta con uno informal y con poco nivel de detalle, lo suficiente para que nos entendamos los programadores.

Lo que no veo en absoluto es meterse a un diseño detallado, metiéndose a nivel de clases y métodos. El porqué es sencillo. Vamos a perder mucho tiempo y en cuanto llevemos un par de días tirando código, van a empezar a salir todas las cosas que no pensamos en el diseño y al final el código no se va a parecer en nada al diseño. Hasta que no hacemos el código, es bastante imposible prever todos los detalles, el diseño detallado sirve más bien de poco.

También el cliente en general suele ayudar bastante a que hacer diseño detallado sea una pérdida de tiempo. Habitualmente el cliente no sabe lo que quiere y cambia de opinión sobre la marcha. Bastan un par de cambios de idea elegidos adecuadamente para que el diseño detallado (y el no tan detallado) se vaya a la porra.

Lo que veo más útil con mis compañeros de trabajo es repartirnos el trabajo y dejar claras las interfaces entre nosotros, bien sean métodos de las clases, mensajes de sockets o como sea que se comunique el sofware que hacemos. A veces basta con decir los métodos o mensajes y que se espera que haga la clase cuando recibe el mensaje o la llamada al método. Otras veces es necesario un diagrama de secuencia para definir una interacción en el tiempo algo más compleja. Una vez hecho esto, que nos facilitará la integración, basta con que cada uno programe a su bola su trozo de código.

Cada vez veo más útil el tema de refactorización de código. Al igual que es imposible diseñar con detalle, también es imposible hacer bien el código a la primera. Es importante tomarse con frecuencia pequeños periodos de tiempo para arreglar el código ya hecho, alternando código nuevo con arreglos de código existente. Además, los IDEs actuales, como eclipse, vienen con montones de opciones de refactorización de código. Basta seleccionar un trozo de código para separarlo en un método aparte, para llevarse un atributo o un método de una clase a su clase padre, etc.

En resumen, que la forma que veo más útil de desarrollo de software es pensar un poco y hacer los diagramas justos para que todos los programadores sepamos que se espera de nuestro código y cómo interactua con el de los demás. Luego cada uno piensa su código y se pone a hacerlo. Es importante arreglar el código sobre la marcha según se vaya embarullando.

Me queda un tema que todavía no tengo claro, que es el de cómo conseguir que el código de una persona sea reutilizado por otra. No sirve poner documentación del código accesible ni comentar. La gente simplemente no busca ahí cuando necesita hacer algo, salvo que sea algo realmente complicado. Aunque todavía no hemos llegado a ello, cada vez me estoy conenciendo más de que la forma mejor para conseguir esto va a ser la programación en parejas típica de la programación extrema. Quizás también las reuniones diarias de unos minutos entre varios programadores para contarse qué están haciendo, qué problemas tienen, qué podrían hacer en común para ambos.