Los dogmas en el desarrollo de software

Esta entrada es un alto en el camino, dentro de la serie que estamos realizando sobre el libro Clean Code de Robert C Martin.

La semana pasada publicamos una entrada sobre el uso de los comentarios. En ella explicábamos que siempre que puedas deberías evitar el uso de comentarios.

Argumentábamos que cuando utilizas un comentario para explicar un código que no se entiende con facilidad, no estás mejorando tu código, sino que estás poniendo una piedra en tu camino. Tu código sigue siendo igual de difícil de entender y además ahora te tendrás que ocupar de mantener esos comentarios actualizados. Lo cual no aporta valor a tu proyecto.

Muchas personas nos han escrito tanto por Linkedin, Twitter, Youtube y el grupo privado que tenemos en Telegram para tratar temas del canal.

Nos han indicado diferentes ejemplos en el que era muy difícil eliminar los comentarios o directamente no se podían. No quiero entrar aquí a revisar cada uno de los ejemplos, pero tras revisarlo con el equipo, era evidente que eran buenos ejemplos. En esos casos, los comentarios si ayudaban a mejorar el código.

Es por eso que quiero hablar un poco sobre los dogmas.

Los dogmas en el desarrollo de software

Existen por supuesto muchos dogmas en el mundo del desarrollo de software, seguro que te suenan algunos de estos:

1. Si no haces scrum estricto no haces scrum.
2. No se puede sacar adelante un proyecto sin pruebas automáticas.
3. En 2020 todo el mundo tiene que hacer DDD.

Estas y otras muchas que se te ocurran las hemos escuchado todos cientos de veces.

Poner un hombre en la luna

Corría el año 1957, estados unidos y la unión soviética se encontraban enfrascados en mitad de la guerra fría, cuando los soviéticos pusieron por primera vez un satélite en órbita, el sputnik. Esto supuso un gran varapalo para la sociedad americana, que crearía la NASA. Había comenzado la carrera espacial.

12 años más tarde en cabo cañaveral despega un cohete con tres astronautas y una misión: "poner un hombre en la luna". Los estados unidos tuvieron que hacer un gran esfuerzo en el desarrollo de la tecnología informática, ya que aquel cohete tenía un computador capaz de guiarlo. Ese computador por supuesto ejecutaba software, y ese software fue programado 30 años antes de que se publicara el manifiesto ágil.

Es decir que sin las consideradas mejores prácticas del momento actual, sin el framework de moda, este equipo de programadores fueron capaces de diseñar y programar un software que puso a un hombre en la luna.

La flexibilidad y empatía

Lo mejor es ser capaz de adaptarse a cada situación, este es el único dogma que te tienes que grabar a fuego.

Pensar que sólo hay un camino para hacer las cosas bien es cuando menos una postura algo miope. Si alguien piensa que su metodología / tecnología / framework / loquesea es netamente superior a las todas las demás está evidentemente equivocado.

Te voy a poner un ejemplo personal. La técnica del diseño dirigido por test (TDD) es una técnica que te ayuda a diseñar software escribiendo primero las pruebas y luego el código de producción. Al hacerlo al revés, haciendo primero las pruebas, te ayuda a que pienses en tu diseño desde fuera hacia dentro, en lugar de como lo harías habitualmente, desde dentro hacia afuera.

Yo estuve haciendo TDD durante aproximadamente un año. Después dejé de hacerlo. ¿Por qué? Pues por dos motivos. Primero porque una vez que asimilas bien la metodología, vas a ser capaz de pensar desde fuera hacia dentro sin necesidad de escribir primero el test y segundo porque en muchos proyectos el diseño no es algo crucial.

En mi opinión tu criterio vale más que lo que alguien escribiera en un libro en la punta del mundo hace veinte años.

No dejes de aprender

Que los dogmas no sean realmente dogmas, no es una excusa para no seguir aprendiendo o mejorando. En mi opinión es tu responsabilidad como buen profesional ir mejorando cada vez tus capacidades.

Además es una buena forma de disfrutar de nuestra profesión y por que no decirlo de ganar cada vez más dinero. No se paga igual de bien a alguien que programa en el lenguaje "a pelo" que a un "tope de gama" en la última metodología o framework de moda.

Te propongo algunos consejos para que no dejes de aprender.

Busca un buen proyecto La forma más fácil de seguir mejorando es dedicar ocho horas al día a mejorar, y para ello debes elegir tu puesto de trabajo en función de donde más vayas a aprender. El dinero y otras ventajas deberían pasar a un plano secundario. Da igual que ganes menos dinero el año que viene, lo importante es cuánto dinero vas a ganar el resto de tu vida.

Sigue canales de youtube y podcast de la temática. Una buena forma de seguir aprendiendo es este tipo de contenidos que suelen tener una alta calidad, y no requieren de demasiado esfuerzo, ya que puedes ver este video, mientras que vas en el tren de camino al trabajo o mientras esperas a un amigo.

Asiste a conferencias y meetups. Es una forma fácil de aprender y de conocer gente. Nunca vas a aprender sobre todo, pero si tienes el teléfono del que sabe, también puede servir.

Lee libros En comparación con los anteriores es el que más esfuerzo o disciplina requiere, pero si no quieres que te den gato por liebre lo mejor es acudir a la fuente. Leer un libro al año, puede marcar la diferencia.

No olvides apuntarte a nuestra academia, para recibir todas las semanas un nuevo video sobre desarrollo de software