Aquí comienza mi camino hacia una programación robusta, barata y de calidad.
Lo de barata lo digo porque cometer errores y darte cuenta cuando ya tienes el proyecto casi terminado, sale bien caro.
Cada cuál tiene su propio concepto de lo caro. Para mí, tener que romper todo lo que había hecho, rebanarme los sesos buscando el error y para que todo vuelva a encajar, me roba días de vida. Y eso, para mí, es caro.🥹🤧
TDD es una metodología de desarrollo que se basa en definir los casos de usos y el resultado que debe obtenerse. En el test se indica lo que se debe obtener y luego se desarrolla el código que supere ese test.
Parto desde cero. ¿Por qué? Pues porque en el ciclo formativo, el tiempo que se dedicó a hacer test, si no recuerdo mal, fueron como unos 10 minutos.
El profesor puso un ejemplo en la pantalla, lo ejecutó y listo. A seguir con el temario.
De hecho, el libro que me compré para tener esa asignatura documentada, dice < «Siendo realistas, es prácticamente imposible realizar pruebas exhaustivas a un programa…»>< «..y es que las pruebas generalmente son demasiado costosas.»>
Pero analizando mi experiencia haciendo los proyectos para clase. Mi manera de programar una suma de dos números es la siguiente:
- 🤔Debo recibir dos números
- Cada número irá a una variable.
- Hay otra variable que almacena el resultados.
- La variable resultado almacena el return de un método suma.
- Le tengo que pasar como argumentos, los dos números al método suma.
- El método debe sumar las dos variables y devolver el resultados.
- Imprimo en pantalla la variable resultado.
Lo hago y compilo a ver si funciona.
Este es un caso extremadamente sencillo pero en otros, si no funciona, me vuelvo loca buscando el fallo.
Menos mal, que ya he aprendido a usar el Debugger. Soy consciente de que todavía puedo sacarle mejor partido pero por lo menos ya no le dedico tanto tiempo a imprimir en pantalla lo que almacenó una variable o a hacer Toas para confirmar la ejecución correcta de cada método.
A lo que voy es que , si sumo el tiempo que dedico a escribir el código, confirmar la ejecución imprimiendo en pantalla, tratar de compilar una y otra vez y buscar el error cometido entre las líneas… pues igual y todo, es mejor escribir los test desde el principio.
Así que, como cualquier excursión que se tercie. Me preparo la mochila para el camino 🌳🌷🌞.
Empiezo el camino bien acompañada.
De momento sólo he leído una quinta parte del libro de código sostenible pero ya con eso, ha sido suficiente para fijarme bastante más en lo que escribo. Ya no solo al nombrar las variables. Sino al estructurar una clase. Me gusta la idea de que leer el código pueda ser una experiencia cercana a cuando lees un libro. Yo iría más allá. Debería ser como un storytelling.
Estoy desmenuzando un poco más los métodos después de eso. Utilizo más return y pongo mejores nombres. Más largos, pero creo que mejores.
Lo que pasa que ahora, cuando veo tutoriales en YouTube, me duelen los ojos cuando veo que la persona que explica nombra algo como: sc, txprim, dj, etc.
Claro que ahora le quito un poco de culpa a mi ignorancia y se la pongo a su semántica cuando tengo que ver el vídeo 5-6 veces para entender lo que pretende hacer el método que está escribiendo 😁.
De momento, me he descargado IntelliJ IDEA. Que siempre viene bien cambiar y aprender a usar otro IDE que no sea Netbeans o Android Studio.