Hará algo más de cuatro años, hice una entrevista para una empresa en la que trabajaban utilizando Extreme Programming como metodología. En aquel momento, yo no tenía ni idea de lo que era eso, así que me contaron un poco en qué consistía, y fue algo así: “Todas las mañanas tenemos una reunión de pie, para que así sea más corta, donde hablamos de lo que hicimos el día anterior. Luego, nos ponemos entorno a ese tablón lleno de post-its, que representan tareas, y cada pareja, porque aquí programamos en pareja, elige una tarea y trabaja en ella”.
Aquello me sonó a algo extremadamente diferente a todo lo que conocía, y, la verdad, me tiró un poco para atrás, sobre todo el hecho de estar todo el día trabajando con alguien en el mismo ordenador. “¡No podré ponerme música!”, pensé. Eso, sumado al hecho de que las tecnologías que utilizaban no me llamaban en exceso, y que me encontraba bastante cómodo en mi puesto de trabajo, me hicieron rechazar su oferta.
En mi día a día, cuando estoy desarrollando software, cosa que ocurre la mayor parte del tiempo, intento seguir una serie de principios y buenas prácticas de cara a producir código con la máxima calidad. La mayoría conocemos, al menos de oídas, cuales son esos principios, aunque no siempre los apliquemos: DRY, SOLID, etc.
Siglas aparte, y a un nivel algo diferente, con el paso de los años he ido interiorizando una serie de mantras que están presentes en mi cabeza de forma permanente, y creo que me han sido de gran ayuda para mejorar como programador. Últimamente, y gracias al entorno de pair programming en que me muevo, los he empezado a dar aún más importancia, ya que en varias ocasiones me he visto en la tesitura de tener que explicar sus beneficios al que fuera mi compañero en ese momento.
En este post pasaré lista a estos “mantras”, que en general no son más que lecciones aprendidas en determinados libros o video-tutoriales, y que han ido calando en mi subconsciente. Me permitiré la licencia de ponerlos en inglés, ya que así los aprendí y así los utilizo, y los listaré por orden de importancia.
Los patrones, sean de diseño, de arquitectura, etc, son una herramienta fundamental a la hora de desarrollar software. Pero en ocasiones, al mismo nivel de importancia encontramos los antipatrones, que no son más que prácticas equivocadas que a primera vista pueden parecer lo contrario.
Estos antipatrones surgen de la experiencia, y tenerlos presentes puede ser extremadamente útil para evitar perder tiempo innecesario debido a decisiones que otros han demostrado son fallidas. En este post pasaré revista a una serie de antipatrones de arquitectura software, o en otras palabras, antipatrones que aparecen en fases de definición y toma de decisiones para un nuevo producto o proyecto a desarrollar. Todos ellos están descritos más en profundidad en este curso. Utilizaré su nombre original, en inglés, ya que generalmente es complicado encontrar traducciones que les hagan justicia y lleguen a ser acuñadas.
Finalizaremos con este artículo la serie en torno a Concourse. En posts anteriores nos centramos en crear pipelines sencillos para introducir los diferentes conceptos que es necesario conocer a la hora de utilizar esta herramienta de integración continua. Sin embargo, ninguno de esos pipelines se asemejaba demasiado a los que utilizaremos en nuestros proyectos del día a día. Ha llegado la hora de presentar un ejemplo más real.
Seguimos con Concourse. En el anterior post introdujimos la herramienta y los conceptos básicos que hay que conocer necesariamente para escribir un job sencillo. Sin embargo, quedamos lejos de poder implementar un pipeline real, nuestro primer pipeline solo tenía un job y había que lanzarlo de forma manual. Será en este segundo post de la serie donde nos acercaremos mucho más a un uso práctico de Concourse.