Parte 1 - E pluribus unum
____________________________________________________________________________
Un requisito fundamental para el bienestar y una buena calidad de vida de un equipo de desarrollo es el uso correcto de las herramientas de control de versiones. Hay muchas, cada una con su filosofía distinta. La más conocida y nuestra favorita es GIT. ¿Pero, cuál es el mejor uso que podemos dar a GIT?
La expresión E pluribus unum significa “de muchos, uno” y creo que es la mejor forma de describir la particularidad de GIT respecto a otros sistemas como SVN. Su objetivo principal no es la mera conservación del código, sino la colaboración. Bien utilizado, GIT es una poderosa herramienta para fomentar las buenas prácticas, una mejor calidad del código y ayudar en el crecimiento de los desarrolladores.
El primer paso consiste en añadir en el flujo de trabajo una nueva tarea: el pull request (o solicitud de extracción). Este hábito puede ser aplicado con independencia de la estructura de ramas y las versiones que se están utilizando en GIT. El desarrollador que quiera mezclar su código con el resto, es decir hacer un “merge” de su código en la rama principal, simplemente tiene que enviar un pull request a los demás miembros del equipo. Dicho en otras palabras el pull request es una petición formal de revisión del trabajo de un desarrollador por parte del resto del equipo. Éstos, con la ayuda de una interfaz visual (como BitBucket de Atlassian), podrán revisar su código, comentarlo y aprobarlo (o rechazarlo si es el caso).
Para saber más: https://www.atlassian.com/git/tutorials/making-a-pull-request
El pull request permite a todos los miembros de un proyecto saber qué y cómo se ha hecho cada parte. Además, la revisión mutua permite a los desarrolladores comentar y proponer mejoras en todos los aspectos del código, desde los nombres de las variables y el formato hasta la implementación concreta de un algoritmo o de un patrón de diseño.
Una revisión de código bien hecha no requiere de mucho tiempo pero conlleva homogeneidad en el estilo, precisión en la nomenclatura de clases, métodos y variables y sobretodo evita que muchos errores pasen inadvertidos. Eso hace que todos los desarrolladores aprendan algo cada día, unos de otros, beneficiándose todos.
Esta tarea podría ser muy larga y difícil si el código enviado a pull request es mucho y contiene muchos cambios. Por eso lo ideal sería que cada nueva funcionalidad se implemente en una nueva rama para que esté claro el objetivo del desarrollo. Esta técnica se llama “feature branch” (o rama de características) y también es aplicable a cualquier estructura de ramas utilizada en un repositorio GIT.
El flujo de trabajo basado en características añade un nuevo valor a GIT y lo transforma en documentación de implementación ya que permite saber no solo cuándo, cómo y quién hizo una determinada elección, sino por qué. Esto ayuda a todo el equipo a mantener una visión global del producto y una mayor atención sobre sus evoluciones.
La separación en ramas de cada nueva característica de un producto aporta una nueva necesidad, la de conocer el contenido del pull request sin tener que leer todo el código. El nombre de la rama debería ser suficientemente claro como para explicar la razón de su existencia, pero no puede contar qué hay en su interior. Aquí entra en juego una característica muy subestimada del GIT (y de los demás sistemas de control de versiones): el mensaje del “commit” (o confirmación).
Muchos desarrolladores se limitan a escribir mensajes anodinos como “error solucionado, refactorización, método cambiado,…” como si fuera solamente una obligación burocrática. Pero no es así. Los mensajes de los commits son una fuente de información valiosísima ya que cuentan la historia de ese particular desarrollo permitiendo a los no técnicos saber qué se ha hecho (volveremos sobre este punto en uno de los próximos artículos).
Obviamente no es siempre tan sencillo mantener todo en orden a la primera, y por esta razón GIT nos ayuda proporcionándonos una serie de comandos avanzados que nos permiten cambiar la historia. Funciones como “modificar, reajustar, recoger, soltar, dividir, aplastar, etc.” nos permiten cambiar de lugar un commit en la línea temporal, fusionar dos (o más), dividir uno en varios, sacarlo de una rama para ponerlo en otra, etc.
Para saber más: https://www.atlassian.com/git/tutorials/rewriting-history
Llegados a este punto tendremos un equipo de desarrolladores capaz de colaborar, un repositorio de código ordenado y, con poco esfuerzo, una mejor calidad, más eficiencia y eficacia en la escritura del código y un equipo en continuo crecimiento personal.
Esta es la grandeza de una herramienta como GIT. Cuanto más grande sea el grupo de trabajo, más pronto se verán los efectos de su uso profesional. De hecho GIT nació justamente para resolver esta necesidad para equipos formados por muchas personas (kenel de Linux). - Y el mismo GIT ahora está siendo desarrollado por un grupo de 280 programadores-.
Para saber más: