Software Mantenible

Actualmente, el software de dialapplet no es fácilmente mantenible por:

1. Falta de guía de estilos.
2. Falta de diagramas de clases de la aplicación.
3. Falta de diagramas entidad-relación de la base de datos.
4. Falta de implementación de patrones de diseño.
5. Falta de javadoc de la aplicación.
6. Falta de diagrama de flujo del funcionamiento del aplicativo.
7. Falta de comentarios ‘de calidad’ en el código.
8. Falta de pruebas automatizadas.

Soluciones de un novel:
1. Se está ‘creando’ una guía de estilos teniendo como base la guía de estilos para C++ de
google.
Guías de estilos en la wiki interna
Guía de estilos Google
2. Los diagramas de clases se pueden sacar mediante técnicas de ingeniería inversa,
buscando algún software como BoUML.
3. Los diagramas de Entidad-Relación también se pueden obtener mediante ingeniería
inversa, estoy buscando algún software fácil de usar.
4. Con la implementación de patrones de diseño, conseguimos una estructura escalable y
mantenible, pero para eso necesitamos los diagramas de clases.
5. La creación de un javadoc es muy fácil, con programas como DOXIGEN, además este
soporta lenguajes como C++ y PHP
 6. Con los diagramas de flujo podemos ser más independientes a la hora de entender
como funciona el aplicativo, y que cosas podemos cambiar sin que afecten a otras ‘más
importantes’. Esto está en la cabeza de los ‘senior’ de la empresa, y debería de estar
‘publico’ para todos los trabajadores, ya que así todo se resume a revisar la información
de un documento, y todos trabajamos alineados con un criterio común.
7. Para crear un javadoc decente, el código debe estar comentado. Pero además, también
ayuda a no tener que estar más tiempo investigando que hace el código, que ha
solucionar el problema. Obviamente, tenemos compañeros senior muy buenos en esta
labor, pero lo que necesitamos es que el código sea entendible por todos no solo para
algunos.
8. No nos olvidemos de las pruebas, ya que estas son las que nos aseguran que todo lo que
hemos hecho no ha fastidiado lo que teníamos bien y que funcionaba. Y para ello
debemos de tener un sistema muy robusto que compruebe, mediante test automáticos
(con pruebas de integración y de regresión), e independientes a las pruebas que ha
hecho el desarrollador (pruebas unitarias y de integración).
Tipos de pruebas software

Es verdad que hay una wiki a la que poder echar un vistazo de vez en cuando, pero no es
suficiente, para desarrollar ‘clean code’.

Creo que estaremos de acuerdo en que esto es lo ideal y que no se consigue de hoy para
mañana, si no que sería necesario un plan a largo plazo que priorice que, como y cuando
hacerlo.

Obviamente esto NO es ‘gratis’, hace falta dotar de recursos y estudiar que alternativas serían
las que más se adaptan a nuestro modelo de negocio. Pero lo más difícil de conseguir es el
cambio de chip de todo el personal. Debemos tener en cuenta que desarrollamos software de
manera ‘artesanal’, y con la actual envergadura de la aplicación, debemos ‘industrializarnos’,
por que si no, cada vez será más difícil arreglar algo sin romper lo anterior. Y no solo eso, si no
que además, contratar a nuevos ‘juniors’ o gente en prácticas (entre los que me incluyo) solo
conseguirá generar más ruido.

Al menos esta es la visión de una persona que entra totalmente novel a tocar el código de la
aplicación.

PD: seguro que se me olvidan muchas más cosas, pero creo que esto es un buen inicio.