Usar la metodología TDD con Criterio

Cuando aplicamos la metodología TDD (Test-Driven Development) a menudo caemos en los dos extremos, al comienzo del proyecto aplicamos TDD a casi todas nuestras clases y métodos. Luego, a medida que se acerca la fecha de entrega nos damos cuenta que estamos atrasados, nos abrumamos y dejamos de lado el TDD.

Como casi todo (o todo!!!) en la vida, la clave es el equilibrio, buscar el punto medio, y este punto medio nos lo da nuestro criterio.

¿Qué criterios aplicar?

Leyendo el blog de http://calenlegaspi.blogspot.com/ coincido con el, para encontrar el punto medio podemos hacernos las siguientes preguntas.

1.- ¿Que tan probable es que este escenario(clases y métodos) presente incidencias?

2.- ¿Qué tan critico es este escenario?

3.- Las clases son complejas, requiero retroalimentación

¿Que tan probable es que este escenario(clases y métodos) presente incidencias?

Obviamente, no deberíamos probar cosas tan simples como los getters y setters, referencias nulas, números positivos, etc. Estás validaciones se dan por hecho.

Si en una primera o en una segunda revisión (si señor, hay que hacer revisiones) del código del escenario te asegura que funcionará, entonces no necesitas una prueba unitaria.

Muy importante, tu puedes incrementar la cantidad de código que no necesiten de pruebas unitarias, esto lo consigues usando librerías de terceros de alta reputación, es código ya probado y con un madurez importante.

Es por eso que más pruebas no necesariamente significa una mejor calidad del software. De hecho, se obtiene más calidad de software si re-usas código probado a implementar tu propio código.

Las clases son complejas, requiero retroalimentación
Aplicar TDD me permite recibir retroalimentación de como trabajaría mi clase en tiempo de ejecución, que tan fácil y cómodo será su uso o integración y validar que la clase o clases cumplan con la funcionalidad esperada.

Consejos para ser un mejor programador

En mi trayecto como desarrollador de software he ido mejorando, aprendiendo de mis errores, aprendiendo de otros programadores. Cuando vivo una experiencia que me marca, lo anoto para después repasarlo. Siempre con el espíritu de crecer profesionalmente.

Tengo tantas ideas, principios y hábitos, algunos en mi mente, otros escrito en alguna hoja guardada entre las paginas de algún libro. En esta entrada pretendo ir organizando estas ideas para compartirlas, recibir retro alimentación o consejos adicionales.

Esta entrada complementa a la entrada ¿Como ser el mejor programador?

1.- Aprende a leer la documentación

Si eres programador del lenguaje Java, generalmente las clases de las APIs más usadas están documentadas en Javadoc, Javadoc es un estandard de Java para documentar. Lo mas relevante de Javadoc es comprender como usar una clase. Cada método tiene una breve descripción, los parámetros que recibe, el objeto que retorna, las posibles excepciones y las reglas más relevantes de uso. Muchas veces usamos una clase sin leer su documentación, violamos algunas reglas de uso y esto genera errores en tiempo de ejecución. Corregir los errores en tiempo de ejecución es muy costoso por eso es mejor invertir un poco de tiempo en leer la documentación de las clases.

2.- Conoce tu herramienta

¿Netbeans o Eclipse? No importa cual sea tu IDE favorito, invierte tiempo en conocer tu IDE. Siempre pregúntate ¿Como puedo optimizar esta tarea?

3.- TDD y depuración de código

Aplica TDD cuando consideres necesario y depura tu código fuente. Aplicar TDD me permite recibir retroalimentación de como trabajaría mi clase en tiempo de ejecución, que tan fácil y cómodo será su uso o integración y validar que la clase o clases cumplan con la funcionalidad esperada. Mas sobre TDD en esta entrada Usar TDD con Criterio

4.- Enfoque, que tu mente esté en el presente.

Es común programar en automático, muchas veces no estamos enfocados al 100% en el código que estamos escribiendo. ¿Te imaginas lo que pasaría si un cirujano está distraído mientras realiza una operación? Bueno... pues hay similitud con nuestro trabajo, una condición o validación errónea puede llevar a que nuestro sistema tenga comportamientos no esperados. (complementar con el punto anterior)

5.- Prudencia y Comunicación

Cuando modificamos código existente debemos tener mucho cuidado con los cambios que introducimos, si dudamos de los cambios que deseamos aplicar es mejor consultar con el resto del equipo. No hay que guardarnos nada, conocer la opinión de otros nos ayuda a corregir o justificar nuestras decisiones.

6.- Buscar la solución más simple

Resolver un problema es un arte, es muy buena practica tener más de una solución y buscar la solución más simple. No porque sea la más simple será la menos eficiente, de hecho, encontrar la solución más simple requiere ingenio, destreza y esfuerzo mental. El tiempo usado en encontrar la solución más simple es una inversión, la solución será menos propensa a errores, fácil de modificar y fácil de depurar.

7.- Pedir Ayuda y saber pedir ayuda
Trabajamos en equipo, tenemos compañeros, apoyémonos en ellos. Muchas veces no preguntamos por no quedar como tontos y esto lo único que hace es afectar nuestra paz mental. Nadie debería juzgarte o criticarte por preguntar. Sin embargo, debes saber pedir ayuda, ordena tus ideas, usa herramientas de comunicación para expresar tus dudas, herramientas como diagramas, dibujos, tablas etc,. Debes ayudar a que los demás comprendan tus dudas para que así puedan ayudarte. Tampoco es que los demás sean más inteligentes o quizás... muchas veces es porque tienen más experiencia, llevan mas tiempo en este arte del desarrollo de software y tu debes aprovechar estos conocimientos.

8.- No Re Inventes la Rueda, Re usa código

Está bien que para practicar programes cosas