Deja de ser un hombre débil

Recuerdo que ella me dijo -"Ya no quiero estar contigo, quiero a un hombre a mi lado, no a un niño, no quiero un hombre débil como tu". Yo tenía en ese entonces unos 19 años, y no comprendí lo de ser un hombre débil.

La vida se encargó de hacerme fuerte a golpes, me hubiese gustado haber tenido una charla con mi padre y que me dijese lo peligroso y  hostil que es el mundo. Un mundo en el que si no tienes carácter los demás te pisotearan.

No es mi culpa no haber forjado mi carácter, la ausencia de mi padre y el entorno donde crecí me convirtieron en un hombre débil, pero tenemos el poder de cambiar, de crecer y desarrollarnos, de forjar nuestro carácter para ser un hombre fuerte.

En esta entrada voy a compartir una lista de principios y hábitos que he desarrollado para dejar de ser ese hombre débil y forjar mi carácter.

Primero estás TU, segundo tu Familia luego el resto

No tengas miedo a decir lo que piensas

Si no estás cómodo con tu situación, cámbiala.

Aprende a decir NO con criterio

Practica artes marciales

Levanta pesas, cuida tu salud, haz deporte

Desarrolla tu filosofía de Vida

Ten metas y objetivos en tu vida

Desarrolla tu auto critica sana

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?

¿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.