Esto es un teatrillo, ficción pura a la que nunca me he enfrentado ¡seguro que el mundo real no es así!. ?
Últimamente, estoy metiendo muchas horas al apasionante mundo del diseño del Software. Tengo la fortuna de trabajar con gente muy capacitada, de los que aprendo mucho.
Aprender, ser exigente y crítico. Remangarse y meterse en el barro hasta el cuello, no creo que exista otra forma de que las cosas salgan en tiempo y forma.
#IAmLearning
Lunes, un día más en el exigente mundo del desarrollo de software, he llegado al puesto de trabajo. Tras el Daily, hoy toca agregar unos nuevos casos de uso (unas historias de usuario) a un proyecto que tiene 1 años de antigüedad y que hace un mes que no se toca, pero que tiene su criticidad.
¡Vamos allá! Descargas el código, le echas un ojo y ¡uyuyuyuy! (primer WTF) Aquí hay chicha, 35 clases y algunas cargaditas, solo un controlador y no termino de entender cómo está estructurado todo esto.
Voy a ver si tenemos documentación, una vista de águila de las clases con sus relaciones, un diagrama de estados y secuencias me ahorraría bastante tiempo. ¡Eh! (WTF #2), vaya no hay, ¡es verdad! Se me había olvidado, somos ágiles y nuestro código es nuestra documentación.
¡Madre mía! Vamos a ver que se puede hacer, me han asignado dos días y tengo que empezar ya, o ni de coña sale esto (WTF #3). ¡A programar!
¡Ummmmm! Creo que para agregar uno de los nuevos casos de uso, voy a tener que tocar bastantes clases, y dos dependencias externa. Bueno, ¡vamos a por ello! (WTF #4)
¡Agggggg! Tocar esas clases está rompiendo funcionalidad anterior y creo que también es posible que haya muchas dependencia en otros proyectos que no esté viendo y se pueden romper. (WTF #5)
Pues nada, paso, vamos a repetir código, lo apañamos como sea y que lo solucione el que tenga más tiempo, con mis dos días, esto no da para más. (WTF #6)
¡Buaaa! Al lío que ya había, le acabo de meter otro montón de código. Vaya bola de pelos, ¡pobre del gatito que se la trage! (WTF #7)
Creo que esto va a ser imposible de reutilizar. ¡Cachis!. (WTF #8). esto no puede ser, vamos a hablarlo en el Daily. Arreglar esto, implica volver a reescribir todo el código casi de cero, el diseño no está preparado para todo esto. (WTF #9)
Daily, como siempre, muy útil, tengo el contacto del último compañero que modificó el código.Voy a hablar con él, a ver qué podemos hacer con esto.
La reunión
2h de reunión, pero ya hemos aclarado las cosas, me encanta Scrum. Bueno, la estrategia va a ser la siguiente, como este codigo puede que no se vuelva a tocar (lo mismo se dijo la última vez), no tocamos nada que podamos romper, pero eso sí, importantisimo:
- Hacemos los test unitarios para que salga el check, después de codificar el caso de uso (WTF #10).
- Lo pasamos por Sonarqube, la herramienta que mide la calidad y seguridad de nuestro código, y así nos aseguramos que el código tiene la calidad que se merece.
- Y el compi me ha dicho, que él me hace el code review del pull request teniendo en cuenta todo esto. Genial! (WTF #11)
- También, hemos comentado, que aún así, los dos días previstos van a pasar a ser 6, tres veces más, ya que tengo que entender y recrear algunas clases más de las esperadas. (WTF #12)
Work done!
¡Hale!, pues ya está hecho. Muy orgulloso de esto no estoy, pero hemos resuelto la papeleta. Los test unitarios pasan.
Vamos a ver que dice Sonarqube. ¡Ummmm!… 1 problema de seguridad y 8 smell code entre otros; codigo duplicado, algo de complejidad ciclomática por allí, mucho peso en clases y otras tontadicas que solucionar. ?
¡Nada que no se pueda arreglar con mucha creatividaddddd! (WTF #13).
Bueno, dos horitas después, el informe del sonarqube ya aparece bastante limpio, solo hay una historia, que no tengo muy claro que es, pero que no debe ser importante… ¡Hablo con el compañero y que deshabilite la comprobación! (WTF #14).
¡Y ya está! Trabajo hecho, código de calidad, eso dice Sonarqube y encima seguro. ¡Ultra combo! ?
Hago pull request, el compi me hace el code review en 1 minuto y a pruebas. (WTF #15). Todo bien, nos vamos a preproducción y en unos días a producción.
¡Todo el mundo feliz! eso sí, podré del siguiente que tenga que poner más funcionalidad. (WTF #16)
Conclusiones
La calidad del código es bastante dependiente del diseño y la arquitectura. Hacer mal estas dos anteriores nos lleva a código que será un problema en el corto o medio plazo, y a largo seguramente se tendrá que volver crear. Tarde o temprano nos encontraremos con un nuevo caso de uso y ya no da más de sí.
La relación tiempo y dinero para entregar una funcionalidad se disparan, debido a la mala calidad.
Los analizadores de calidad del código ayudan, pero son estaticos, verifican que el código cumple muchas de las buenas prácticas y principios del ‘Clean Code’, del ‘Smell code’ y métricas asociadas, te da una idea de lo que puede haber detrás de ese código. Pero difícilmente van un paso más allá, validando si el diseño de la implementación facilitará el la incorporación de nuevas funcionalidades o casos de uso con velocidad y sin dolor. Del uso de patrones y de una buena arquitectura.
En el próximo POST, hablaré de los principios del diseño, recomiendo los best seller y mi opinión sobre algunos de ellos. (Aún no he podido leerlos todos, pero si muchos que los más interesantes)
¡A darle caña! ?