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.

Editor de textos

Estoy haciendo en plan de muestra para la página web un pequeño editor de textos en java. Simplemente una caja de texto para escribir y opciones de menú para salvar fichero, cargar fichero y buscar una cadena de caracteres en el texto escrito.

Recuerdo hace muchos, muchos, muchos años, en los tiempos del basica (o gwbasic) que también hice en varias ocasiones un editor de textos. ¡Vaya diferencia!

Antes, con el basica, me preocupaba yo de todo. Controlar la posicion x,y del cursor, capturar las teclas para escribirlas, capturar las teclas de borrado para borrar, las flechas para moverme, etc, etc. Manejaba arrays y arrays de caracteres y variables con posiciones dentro de esos arrays y me dedicaba a mover arrays de caracteres de un sitio a otro.

Ahora, con java, no hay que preocuparse de cómo hacer las cosas. El problema principal con java es pelearse con la API, para encontrar el método o la clase que hace lo que tú quieres hacer, porque es seguro 100% que hay un método o una clase que hace lo que quieres hacer, pero no sabes cómo se llama. Es más, hay más métodos y clases que hacen más cosas que las que posiblemente quieras hacer o te imagines siquiera que puedes querer hacer en toda tu vida.

Antes querías hacer poca cosa y con eso ya tenías trabajo para varios días, haciéndolo. Ahora quieres hacer muchas cosas y tienes trabajo para varios días, buscando quién lo hace.