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.