Git y las malas costumbres

Querido < 75% bot ó spider que captura contenido para google, otro buscador o alguna empresa que hace sus pininos en bigdata OR 20% usuarios reales que llegaron aquí por equivocación OR 5% usuarios interesados en leerme (¿Hola mamá!) >

En este artículo describo los peores manejos que he visto de Git, en base a mi experiencia, después de años de usarlo y de usar otros tantos Sistemas de Control de Versiones.

Primero un screenshot:

git hace 2 años

Hace casi dos años quería escribir un artículo que hablara de las ventajas de Git. Ahora entiendo que abordarlo en ese entonces no me hacía sentir cómodo porque tenía una visión poco amplia de su uso. Durante los últimos 3 años estuve trabajando en proyectos que no necesitaban a muchos desarrolladores involucrados y en los que sí, se utilizaba SVN por costumbre.

En mi caminar por este medio he conocido ya a un par de villamelones que evangelizan implacablemente sobre el uso de este famoso sistema de control de versiones, pero ya conviviendo profesionalmente con ellos ha sido un fiasco descubrir que muchos nunca han intentado revertir algún cambio en el código, de hecho la mayoría no entiende la relación entre los ambientes de desarrollo y el sistema de control de versiones.

La mayoría de estos falaces seres con los que me he topado utilizan Git sólo por una especie de romanticismo hipster/vintage en contra de la modernidad. Ya saben, amor a las terminales de fondo negro con leras verdes y uxfobia; pero pocos lo utilizan con el fin correcto, que es controlar las versiones del software.

No digo que Git no tenga un montón de características útiles al momento de desarrollar, instalar, mover, publicar, revertir, etc. Lo importante que trato de decir es que: La gran meta del desarrollo de software debe de centrarse en el resultado final, el cual no tiene que ver con código, el cual no se entiende desde el punto de vista del desarrollador; debe centrarse en un fin útil, un fin que se enfoca en un usuario. Un usuario que tiene una necesidad genuina que se resuelve con software. Un usuario que puede no tener conocimientos amplios sobre computación. Un usuario al que hay que adaptarse y obedecer humildemente, tal vez no en los cómos pero sí en los porqués

Como siempre he dicho: Las cosas se miden por el resultado. Y si el resultado es un usuario/cliente enojado porque el producto no cumple con sus expectativas, entonces no importa si el Git está perfectamente comentado, versionado, organizado, almientado y los desarrolladores que lo operan son expertos en su manejo. Lo que importa se ha perdido en un mar abstracción hedonista. Lo que importa es el propósito del software.

Porque, aceptémoslo, programar da placer. ¿Qué programador no se ha perdido horas en su código?¿Qué desarrollador no ha disfrutado esta sensación casi orgásmica que da ver vivir sus instrucciones? ¿Quién, que programe, no se ha ofendido porque critican su sintaxis? Desarrollar software, construir un sistema, resolver problemas, dar instrucciones precisas que son seguidas al pié de la letra son actividades que provocan placer.

Es por eso hay por ahí un montón programadores que actúan como si fueran dios porque son capaces de crear sistemas independientes. Tiranos que exigen al usuario que se especialice en un software difícil de entender, para el cual se requieren capacidades muy específicas. Soberbias criaturas que se burlan de sus iguales sin no escriben en su mismo idioma. Estos especímenes nos dan el ejemplo de lo que NO se debe de hacer con Git.

Los 4 NO’s de Git

  1. Git no es un protocolo de transferencia para publicar a entornos remotos. No es “como ftp con terminal” como alguna vez escuche. Utilizar git sólo para hacer deploy a un servidor es como quemar una casa para acabar con la plaga. Me he topado con proyectos donde más de la mitad de los commits son para publicar, esto hace que se pierda la filosofía del versionamiento ordenado y responsable.
  2. Git no te ayuda a crear una rama para ti solito (Branch para los angloparlantes) y así evitar que otros mensos se entrometan en la genialidad de tu código. Está bien hacer branches para resolver problemas inciertos, pero esos branches deben de ser temporales. A los demás desarrolladores no les gusta tener un montón de ramas inútiles con nombres extraños, las mayoría de las cuales no funciona. Así que lo mejor es guardarse esos branches para uno mismo, en su repositorio local, borrarlos cuando no los necesites y no hacer push; Es mejor colaborar y comunicarse (De preferencia verbalmente y cara a cara) y hacer a un lado a ese pequeño egomaniaco que todos llevamos dentro que te dice que ese código es tu creación única e irrepetible.
  3. Git no es un almacén de archivos binarios. Aunque git puede guardar archivos binarios sin problemas, pdfs, swfs, documentos comprimidos, etc. No es para nada una práctica recomendable. Primero que nada git no versiona las líneas de los archivos binarios, así que guarda una copia completa con cada cambio. Algunos de aquellos seres salidos de ultratumba que hemos ya mencionado argumentarán que, cito: “No tengo problemas de almacenamiento, tengo tanto disco duro en mi repositorio que nunca se me va a acabar”. Y con eso se pierde una de los paradigmas más importantes de Git (3 palabras): Repositorio No Centralizado. Los demás desarrolladores también bajan el repositorio y hacen uso de él ¿Porqué tendrían que estar esperando hasta horas para descargar grandes cantidades de datos sólo porque alguien decidió incluir binarios? Además se pierden ventajas como: Publicar en servidores pequeños, portar el repositorio fácilmente y dar seguimiento a los cambios de lo que importa: el código. Para almacenar binarios hay otras maneras diversas.
  4. Git no es una terminal. Acepto que yo soy uno de esos amantes a la antigua que siempre tengo abierta una terminal. Porque se utilizarla y hay tareas (no todas) que yo puedo realizar más rápido desde ahí. Pero esto no significa que por usar una terminal soy mejor persona. Igual y no se operar una Terex RT130 y eso no me hace una peor persona. Aunque todavía no hay muy buenos programas gráficos para manejar Git, la mayoría cumplen perfectamente con su propósito. Muchas personas (sobre todo esos entes ultratúmbicos y siniestros egomaniacos) siguen exigiendo a los demás usuarios que utilicen la terminal, a veces creo que es sólo por el placer de minimizarlos porque no saben utilizarla y así saciar su síndrome de Asperger. Lo importante al utilizar cualquier sistema de control de versiones, en este caso Git, son los conceptos,  los más importantes o básicos pueden manejarse perfectamente sin tocar la terminal y no es necesario complicar los proyectos generando curvas de aprendizaje innecesarias.

Hasta ahora estas son las prácticas malvadas más puntuales que se me ocurren en el corto periodo de atención que puedo dedicarle a escribir un artículo. Si se me ocurren más NOs los pondré en la lista en otro post. De hecho hay mucho que poner sobre git en otro post, pero no me gustaría repetir lo que muchos otros ya han plasmado tan perfectamente.

En conclusión. Git puede ser una excelente herramienta. Pero como todas las herramientas no hay que olvidar el fin que persigue y que, sin dicho fin, la herramienta pierde su razón de ser. El fin es y siempre será: Hacer mejor software. Y la calidad de un software se mide por las cantidad de satisfacción que genera en el usuario (Máquina o persona) que lo maneja y por las necesidades que satisface.

Felices commits

 

Comments are closed.