Esta semana pasada me ha llamado la atención que todavía hay gente desarrollando software sin utilizar control de versiones de código fuente.

Lo que me pareció más curioso es la cantidad de excusas (de malas excusas) que me dieron para intentar evitar algo tan simple, beneficioso y fundamental como es guardar tu código en un sistema que te permita recuperar fácilmente cualquier versión anterior, además de trabajar fácil en equipo y mil cosas más.

Esto ya me ha pasado otras veces, sobre todo cuando he tenido que trabajar con personas que no están acostumbradas al desarrollo de software, en ambientes universitarios o entornos de investigación.

En fin, estas fueron las 7 malas excusas que me dieron para no usar control de versiones de
código fuente
.

No somos un equipo de desarrollo de software

¿Y qué tendrá que ver no ser un equipo de 20 personas desarrollando software? En mi anterior post expliqué cómo conectar el desarrollo de una página web WordPress con Git, y sí, sólo toco yo el código. ¿Por qué no voy a querer poder guardar versiones de mi página?

equipo desarrollo software

No desarrollamos software

La idea que me transmitían era que normalmente no desarrollan software, o mejor dicho, que no desarrollan software que sea usado por alguien. Bueno, aquí tienes un consejo de alguien que lleva unos cuantos años desarrollando software: yo de ti usaría control de versiones.

Y si no desarrollas software en absoluto, también te digo que el control de versiones es muy útil para otros casos, como ya expliqué en mi post sobre cómo publicar tu página web utilizando Github. Al final, como mínimo, es un repositorio donde puedes almacenar cualquier cosa pero con muchísimas más ventajas (trabajo distribuido, versionado, flujos diferentes de desarrollo, …)

fontaneros

No necesitamos versiones

Por supuesto, no utilizar control de versiones te conduce a no saber nada de un workflow de versionado de software, sin control de versiones, ¿cómo haces una release de una versión? ¿cómo resuelves bugs mientras contínuas desarrollando features? ¿cómo refactorizas la API de tu proyecto?

control de versiones

Tengo 3 copias del código en 3 discos duros diferentes

Al final resulta que copiaban copias completas del código fuente en diferentes discos duros. Creo que también tenían una copia en cinta y otra perforando tarjetas (no comments)

cinta control de versiones

No podemos montar un servidor de control de versiones

Resulta que es cierto que en entornos universitarios, no suelen tener medios para contar un servidores para alojar determinadas cosas. Muchas veces tienen sus equipos para trabajar y poco más…

Sería una buena excusa de no ser porque hay cientos de servicios en la nube para alojar código fuente, incluyendo algunos que ofrecen repositorios privados.

Y por otra parte, depende del gestor que utilices ni siquiera necesitas un servidor. Montar un control de versiones con Git en tu propio equipo es tan simple como ejecutar “git init” en cualquier carpeta y tener una red local.

Git logo

Nunca trabajamos en la misma parte del código

Esto en sí, es una consecuencia de no utilizar control de versiones. Al no contar con un mecanismo para mezclar cambios, los miembros del equipo (dos) se ven obligados a trabajar en partes diferentes del código para que así, hacer un merge, sea pasarse los ficheros que han tocado y comprobar manualmente que todo funciona.

control de versiones

Me da igual lo que me digas

Después de 6 excusas, a cada cual menos convincente y más relacionada con una mala gestión del ciclo de vida de un proyecto, saco esta séptima excusa como conclusión.

gnu

No suelo invertir mucho tiempo en intentar ‘convencer’ a nadie, si alguien me dice que un plátano es rosa, diré: “yo lo veo amarillo”. Es sólo mi punto de vista.

Aún así, y quizás debo estar influenciado por mi entorno de trabajo, intento aprender siempre de los que creo que saben un poco más que yo porque sinceramente, es de las pocas maneras que conozco de mejorar en lo que hago.