El código importa

Tal y como ha explicado Jake en el post anterior, un buen diseño de cualquier aplicación es necesario. Por diseño debe entenderse siempre diseño interno, lo que acaba viendo el usuario puede encargarse, sin menosprecio, a cualquier diseñador gráfico que sepa que es un CSS y que el flash no es esa gran herramienta que para webs maravillosas.

Esta tarea de diseño suele encargarse a grandes Jefes de proyecto, para que luego sus lacayos, llamémosles becarios, lleven a cabo sus más maléficos planes. Sin embargo, esa gran persona encargada de poner los cimientos, de crear una estructura, decidir cómo hacer las cosas, va y coge el Word y te hace 4 cajas. Como maestro del wordart que es, te pinta cuatro cajas representado lo de siempre, lo que todo desarrollador deber saber: Vistas + Dominio + Persistencia + BD.

Mientras tanto, sigue maquinando con el cliente como tiene que ser la aplicación, rellenando miles de papeles, firmando contratos, garantías, actas... "Cualquier cosa que marque una metodología pesada como RUP nos llevará al éxito", deben pensar. Y eso no se puede negar, pero lo habitual es que entre tanto diseño, se olvida la figura del técnico, del ingeniero de software, del picateclas que le sacará las castañas del fuego.

Cuando su diseño llega a las manos de los desarrolladores, normalmente estos cogen las cajas y empiezan a crear monstruos. Y lo más grave de todo, no piensan en quien vendrá después o con quien tienen en su equipo. En quien cogerá semejante trozo-de-mierda para su mantenimiento y acto seguido hará las maletas para irse a la fin del mundo.

Esto es culpa tanto del Jefe de proyecto / diseñador, y el propio programador. Hacer un código elegante implica hacer buen código, código eficiente y efectivo. Todos los frameworks, libros, jefes y demás, se llenan la boca afirmando que su código es reutilizable. Eso no es más que una gran mentira si el código que implementa tu aplicación no se revisa y no se tiene en cuenta.

El código debe ser revisado por otros, pulirse y rehacerse, es decir hacer refactoring. La típica frase de "si funciona no lo toques" no debería ser vuestra pan de cada día. Sin lugar a dudas las metodologías ágiles como eXtreme Programming te llevan a crear una aplicación de calidad en poco tiempo. Te obligan a testear (ave JUnit) cada parte de tu software, reescribir tu código y en definitiva, mejorar tu software.

Los grupos de trabajo jerárquicos con el gran Jefe de proyectos en la cima, con sus expertos haciendo las mil maravillas, deben pasar a la historia. Hay que apostar por grupos colaborativos donde todos dependen de los demás y todos hacen de todo. Hay que dedicar más tiempo al diseño y a una buena implementación. Seguramente al principio se avanzará más lentamente, pero la curva de desarrollo aumentará de tal manera que compensará el esfuerzo inicial. Los que crean que es mejor hacer que simplemente todo funcione de cualquier manera, ya tardan en seguir a nuestro enviado al fin del mundo.