Hace un par de días me encontraba con mi padre comentando un «cambio de rumbo» que ha dado mi vida en el entorno laboral. Uno de los temas que tocamos fue relativo al hecho de que, recientemente estoy empezando a replantearme algunas «ideas puristas» a la hora de desarrollar software… dicho de otra forma, le doy muchas vueltas a las cosas para intentar que los sistemas que desarrollo sean lo mas estructurados posible, lo mejor comentados posible, lo mejor diseñados posible, lo mas separados en capas posible…. y eso lleva su tiempo, y claro, si lo que uno tiene que hacer es una «web chorra» o un programa, así como muy simplón, el tiempo que tardo en hacer las cosas no siempre es el esperado por el cliente.
Cuando le estaba contando esto a mi progenitor, el me comentó que «en el desarrollo de software, al igual que en cualquier ingeniería, hay que intentar que los diseños y los desarrollos, sean eficaces, pero también eficientes»… sobretodo en la empresa privada con mucha competencia.
Antes que comentar mis pensamientos sobre el tema, os recomiendo que leáis esta entrada de la Wikipedia… la parte que mas me gusta de esa Wiki es la frase que dice: «Ejemplo: matar una mosca de un cañonazo es eficaz (o efectivo: conseguimos el objetivo) pero poco eficiente (se gastan recursos desmesurados para la meta buscada). Pero acabar con su vida con un matamoscas, aparte de ser eficaz es eficiente.»
Ahora, ¿que tienen que ver las definiciones de eficaz y eficiente con el desarrollo del software?, muy simple, un desarrollo eficaz en un desarrollo que cumple con los requisitos del cliente, y un desarrollo eficiente, además, ha consumido «pocos recursos»; dicho de otra forma, hemos necesitado un equipo reducido de personas para hacerlo y lo hemos desarrollado en poco tiempo.
En el mundo del desarrollo de software (como en otras disciplinas, como la arquitectura, la ingeniería de minas, la ingeniería industrial, etc.) tenemos que tender a que nuestros desarrollos sean eficaces, pero también eficientes. Esta máxima cobra especial importancia si nuestros trabajos se realizan dentro de empresas privadas, y mas aun, cuando dichas empresas tienen mucha competencia. El motivo es obvio, cuanta mas gente participe en un proyecto mas coste tiene dicho proyecto, cuantas mas horas se invierten en un proyecto, mas coste tiene.
Después de toda esta exposición llega la hora de hacerse preguntas:
¿Es mas eficiente un desarrollo de un código «cogido con pinzas» (en el que está todo mezclado, la mitad de los datos están en base de datos, y la otra mitad en código, etc) que un desarrollo «»»»»bien hecho»»»»» (con su código bien separado en capas, con sus pruebas unitarias y de integración, con su documentación impoluta… y en inglés, su base de datos diseñada desde una herramienta CASE, su ORM bien puestecito, etc.)?… pues, me guste o no, he de admitir que si, es un desarrollo mas eficiente.
Ahora, ¿cual de los dos desarrollos es mas mantenible?, puede parecernos que la segunda forma de desarrollar sin lugar a dudas es mas mantenible, y seguramente lo sea, pero: 1º Seguirá siendo mucho mas costosa (menos eficiente) y 2º quizás no tardemos mucho menos en mantener el sistema que el otro, puesto que, cada nuevo campo en la tabla, cada nuevo requisito, cada cambio en el diseño, requiere que estemos varias horas manteniendo toda la estructura con tantos elementos alrededor del programa, pero que no son necesarios para que el programa funcione (pruebas, documentación, diagramas, …). Ojo, aquí no estoy discutiendo que los elementos «»prescindibles»» no tengan su valor por ejemplo, asegurar la calidad del producto y protegerlo frente a los cambios (pruebas), o para mejorar la comunicación entre los miembros de un equipo (documentación y diagramas), lo que digo es que, si lo hacemos todo, y todo a la perfección, quizás no vamos a tardar mucho menos en mantener un sistema tan completo (y complejo) que un sistema de tipo «código espagueti», puesto que, además de realizar los cambios en el código (eso será muuuuy rápido), también tenemos que mantener todos los demás elementos (nuevas pruebas unitarias, modificaciones en diagramas, etc.).
Después de estas reflexiones, quiero exponer mis conclusiones personales (que intentaré acatar a partir de ahora):
- Si estás desarrollando un software en tu casa, intenta aplicar todos los principios de ingeniería del software que se te ocurran, separa en capas, documéntalo todo, haz diagramas (mínimo entidad-relación y de clases), investiga y aplica en tus desarrollos DDD, TDD, BDD, etc. Porque acabarás adquiriendo soltura, conocimientos y buenas prácticas. Pero si estás desarrollando un sistema para tu empresa, céntrate en el código por encima de todas las cosas, pero intenta llegar a un punto intermedio entre lo rápido y lo mantenible. Porque el cliente suele querer las cosas «para ayer» y a la empresa le interesa que nuestro desarrollo le cueste menos al cliente que el de la competencia, pero también quiere dar una impresión de que un «pequeño cambio» no costará tanto como rehacer el sistema.
- Si además de centrarte en el código, quieres ir aplicando elementos que harán tu código mas mantenible, empieza por separar el código en capas (porque es fundamental para hacer un sistema mantenible), después quizás deberías decantarte por el trabajo con pruebas unitarias y de integración (porque te ayudarán a mejorar la calidad de tu sistema, y protegerlo de los cambios que vayas realizando) y al final puedes elegir entre comentar el código (sobretodo el de negocio y el que se salga de lo normal) o documentar el sistema para que sea fácil de entender «en conjunto» rápidamente (sobretodo pensando que otra persona lo tiene que entender o que tu mismo lo tienes que mantener pasados unos meses).
Con el tiempo, nuestra forma de desarrollar será eficaz y, también será eficiente, tanto a corto plazo (puesto que tardaremos poco en entregar nuestros desarrollos), como a largo plazo (puesto que tardaremos poco en hacer frente a los cambios requeridos, o osea, lo haremos mas mantenible).
Estas son mis reflexiones, espero algún comentario.