100 Days of Code - Días 11 a 20

  • Time to read 3 minutes
100 Days Of Code - Dias 11 a 15

Día 11 - 04/04/20

Hoy ha sido un día de pensar. Quiero que todo lo que haga a partir de ahora, sea lo más reutilizable y escalable como sea posible. He iniciado el diseño de las capas de servicio y repositorio del servicio web que utilizaré para explotar el juego.

Dentro del diseño, he considerado la inclusión de una capa de persistencia, de forma que la aplicación pueda ser multi-jugador y multi-juego. En la implementación final utilizaré una base de datos, pero por el momento voy a simular dicha capa mediante un repositorio que internamente implemente un diccionario. Poco a poco.

Día 12 - 05/04/20

He desarrollado todos los tests unitarios necesarios para asegurar el correcto funcionamiento de la capa de repositorio. Me ha llevado más tiempo del que creía, porque he querido pararme a pensar bien qué datos necesito pasarle al repositorio y el comportamiento que debe tener en función del resultado de la acción ejecutada: ¿qué ocurre si el elemento a borrar no existe? ¿arrojo una excepción? ¿lo ignoro? (Una pista: la decisión final ha sido arrojar una excepción, que trataré en capas superiores).

Día 13 - 09/04/20

He implementado una clase base de repositorio que utilizaré como mock de la base de datos. Contiene todos los métodos que posteriormente utilizaré en el acceso real a base de datos, solo que se utilizará un HashSet para almacenar la información. Los métodos del repositorio base son los que simularán las acciones del SGBD.

Además, la clase base es genérica, de forma que la puedo reutilizar para las distintas entidades que manejo en la aplicación. He aprovechado para refactorizar levemente la entidad Player para añadirle un Id, y así adaptarla a mis posteriores necesidades cuando conecte con base de datos.

Días 14-15-16-17 - 10-11-12-13/04/20

Han sido días duros y largos de refactorización y revisión de código. El primer día decidí hacer un análisis del código con cobertura, y encontré bastantes errores. Tenía código smell y un % demasiado bajo de cobertura. Tras mucho retocar y corregir código, finalmente descubrí que la librería que utilizo para obtener la cobertura tiene un bug, que ya he reportado.

La parte positiva de todo esto es que he aprendido muchísimo sobre todo lo que concierne al análisis de código estático. He aprendido a diseñar código más testable, y a configurar SonarQube y herramientas de análisis de cobertura. No he podido avanzar mucho en cuanto al desarrollo, pero he podido dar un toque de calidad al código.

He observado también la increíble importancia de seguir las normas de buenas prácticas, y especialmente los principios SOLID (de los que ya he hablado en algún momento). Además, el análisis de la cobertura de código me ha mostrado la cantidad de código que, a pesar de usar TDD, me ha quedado sin probar. Tendré que prestar más atención a esta cuestión en el futuro.

Día 18 - 14/04/20

Tras dedicar unos días a la revisión, optimización y refactorización de código, he decidido avanzar en el desarrollo del proyecto. He implementado los repositorios necesarios para tener un CRUD completo de TicTacToe y de Player. Gracias a la clase base que creé anteriormente, este desarrollo ha sido enormemente rápido.

Día 19 - 16/04/20

El día de hoy no ha sido tan productivo como hubiese esperado. He tenido que darle un par de vueltas en mi cabeza para ver cómo encarar las capas de servicio y controlador. Finalmente lo voy a resumir todo en 2-3 métodos, que me cubrirán prácticamente todas las casuísticas y funcionalidades que necesito. También he aprovechado para revisar las posibilidades que ofrece Github, más allá de ser un mero servidor Git.

Día 20 -17/04/20

Una vez resuelto el bug de la librería que utilizo para el cálculo de cobertura de código, he decidido seguir refactorizando código y creando tests unitarios con dos objetivos principales: no seguir avanzando con deuda técnica pendiente, y aumentar el % de cobertura, ahora que por fin tengo datos fiables.

Como parte del SDLC, he estado investigando el funcionamiento de Github Actions, y he creado una acción para que me ejecute todos los tests unitarios del proyecto cada vez que hago push de código en mi rama de Develop. Poco a poco voy descubriendo nuevas funcionalidades y herramientas que me ayudarán en mi día a día.

Listado de Commits en Github
Dia Commit
11 https://github.com/ramoncarrascom/BoringGames/tree/a91d82
12 https://github.com/ramoncarrascom/BoringGames/tree/fd8ce3
13 https://github.com/ramoncarrascom/BoringGames/tree/897dcd
14-15-16-17 https://github.com/ramoncarrascom/BoringGames/tree/5390fb
18 https://github.com/ramoncarrascom/BoringGames/tree/6a271
19 https://github.com/ramoncarrascom/BoringGames/tree/49a35
20 https://github.com/ramoncarrascom/BoringGames/tree/0c8186