Home Tecnología Un código versionado es un código sano

Un código versionado es un código sano

0
Un código versionado es un código sano

Sin importar en qué lenguaje de programación estemos desarrollando, siempre es de suma importancia mantener un código sano y funcional. Pero, ¿qué significa “sano” y cómo lograrlo?

Existen dos maneras en las cuales se puede trabajar un proyecto: mantener un único archivo donde se tenga concentrada toda la información y que sea el que se vaya actualizando continuamente, o ir generando distintas versiones de ese archivo, con distintos nombres, donde cada una tenga un nivel diferente de avance. A esta última se le llama “versionamiento”, y es la opción más adecuada para desarrollar software, ya que permite tener un registro histórico de todos los cambios realizados al código de manera que, en caso de que ocurra algún problema, rápidamente se pueda regresar a una versión previa al error donde todo siga funcionando.

Todos tuvimos alguna vez ese proyecto el cual hemos ido guardando poco a poco y con distintos nombres cada vez que sentimos que logramos un avance importante, en el que terminamos teniendo una incontable cantidad de archivos con todas las variantes posibles de “Versión Final”, “Versión Final Final”, “Versión Final Este es el bueno”, y similares. El problema es que esto no es muy fácil de mantener ya que, a menos que utilicemos un sistema o una metodología estructurada para ir nombrando cada nueva versión, sería muy confuso poder saber en qué archivo existe el nivel de avance que estamos buscando. Si a esto le agregamos que lo más probable es que estemos trabajando en un proyecto en equipo, las cosas comienzan a salirse de control, pues ahora hay que mantener ordenadas las distintas versiones que cada integrante vaya generando, las cuales pueden estar tan dispersas o concentradas como nos podamos imaginar y van a contener un nivel de avances, cambios y adaptaciones casi imposible de sincronizar. Normalmente, se requiere cambiar de una versión a otra cuando se presenta algún error o problema en la versión actual. En caso de que el último cambio incluido provoque que lo que se tenía previamente comience a fallar o simplemente deje de funcionar, para evitar que el problema se haga mayor, simplemente se regresa a una versión previa donde se puede confirmar que todo funcionaba correctamente, y a partir de ahí continuar trabajando. 

Un ejemplo muy claro es el siguiente:

Dentro de una empresa, un grupo de compañeros deciden crear una carpeta en la nube donde cada uno irá cargando sus aportaciones al proyecto al que fueron asignados. Esto suena a una gran idea, ya que de esta manera tendrán consolidado en un solo lugar el avance de todos los integrantes. Sin embargo, después de una semana de trabajo, uno de ellos ha guardado 5 archivos y otro lleva 3 debido a que han trabajado versionando sus avances, pero el último sólo tiene un archivo en el que ha ido actualizando sus avances. Cuando quieren juntar todo en una versión consolidada, se dan cuenta que ninguna de sus aportaciones individuales es compatible con el resto, porque mientras el primer amigo resolvía un problema de una manera, otro ya había asumido que ese problema lo había resuelto de otra forma que no empata con lo que hizo originalmente, por lo que hay que retrabajar con una de sus versiones previas y adaptarla para que el proyecto pueda funcionar en conjunto. Cuando logran emparejar sus versiones y quieren añadir la de su tercer compañero, notan que de nuevo no son compatibles pues al tener un único archivo, no hay manera de saber en qué momento modificó su contenido de tal manera que dejó de ser compatible, por lo que tendrá que rehacer su parte casi por completo.

En el caso de desarrollo de software, por mucho que todos los involucrados estén trabajando en el mismo código, ¡pasa lo mismo! Imaginemos que cada desarrollador tiene una copia del código en su computadora y únicamente trabaja sobre ella. Nunca se enterarían de los avances, problemas y soluciones que el resto del equipo estén teniendo, y peor aún, es muy probable que se encuentren con los mismos problemas y los resuelva de manera diferente, provocando que la versión del código que cada quien tiene sea incompatible con el resto, lo que desataría un grave problema para todo el proyecto.

Es aquí donde son de utilidad los repositorios de código, como lo es GitHub. Estas herramientas funcionan principalmente como una carpeta en la nube a la cual todos los desarrolladores que estén trabajando en un mismo código tienen acceso y la cual permite tener un control sumamente estricto de las modificaciones que se hacen al código que se encuentra ahí. En resumidas cuentas, funciona de la siguiente manera:

Cada vez que un nuevo desarrollador se une al proyecto, se le da acceso al repositorio del equipo, de donde podrá descargar su copia local (en su computadora) del código existente en esa “nube”, al que se le conoce como “código fuente”. Ya con esa copia local, podrá comenzar a trabajar en cambios, mejoras y cualquier modificación necesaria o requerida. En cuanto tenga sus cambios listos para enviar a la versión “oficial” del código (aquella que se encuentra en la nube), los envía por medio del mismo repositorio para que puedan unirse al código oficial y este se actualice automáticamente a una nueva versión. Para la siguiente ocasión, en la que el resto de los desarrolladores actualicen sus versiones locales con la versión oficial, ya podrán ver los nuevos cambios que el nuevo programador envió, por lo que todos estarán trabajando con el mismo código, garantizando su compatibilidad.

Pero espera, la cosa no termina ahí. Además del manejo de versiones, otra de las principales ventajas de los repositorios es que también se pueden generar versiones “espejo” del código principal, llamadas ramas. Estas ramas son versiones paralelas del código fuente, las cuales se crean desde el repositorio a fin de hacer modificaciones en ese código fuente sin afectarlo directamente. Desde mi computadora, yo puedo migrar de la rama principal (rama master), que es donde vive el código productivo (el que siempre se está ejecutando y gracias al cual funciona el producto) a una rama que alguien más o yo mismo creé previamente y, de esta manera, trabajar localmente en esa versión paralela del código. Una vez que se termine el cambio en el que estaba trabajando, se pruebe y valide su correcto funcionamiento, se puede enviar ese cambio al repositorio por medio de una pull request. Ésta sería el equivalente a solicitar un permiso para unir ese cambio a la rama principal y así actualizar el código productivo con la nueva función. Otro desarrollador debe revisar la solicitud y, en caso de aprobarla, se terminará de unir esa rama a la versión oficial del código, siempre y cuando no haya problemas de incompatibilidad, pues de haberlos se deben resolver antes de hacer la unión.

Las ramas están pensadas para ser usadas sólo temporalmente. Una rama se crea para trabajar en algún cambio en específico. Una vez que se termine y su contenido sea aprobado y unido al código oficial, la rama se cierra, por lo que ya no se podrán enviar nuevos cambios desde ella, sólo podrá ser usada como referencia para conocer lo que se trabajó ahí.

Todo este juego entre ramas, versiones y cambios permite que podamos proteger el código oficial y que sólo se añadan las modificaciones pertinentes, además de que permite que todos los desarrolladores involucrados, sin importar dónde estén, tengan acceso a la versión más reciente del código en cualquier momento, por lo que todos cuentan con la versión de código más estable y actualizada. En caso de haber un error, las ramas sirven como un histórico de cambios y versiones pasadas, por lo que únicamente se debe elegir la última versión sana del código, convertirla de nuevo en la versión oficial y así eliminar el problema  y nuevamente desarrollar la siguiente parte del código a partir de esa versión estable. 

No es una práctica a prueba de balas, pues también requiere de disciplina por parte de todos los involucrados para mantener sus versiones locales actualizadas y al día con la del repositorio, además de tener cuidado de no aprobar cambios que puedan tener algún error. Sin embargo, definitivamente es la manera más popular y eficaz de mantener un código protegido, eficiente y sano hoy en día.

 

Aldo Vega

Ingeniero en Sistemas Digitales y Robótica

 

#InformaTEEB #Blog #Tecnología #Versionamiento #CódigoSano #Ramas #GitHub #blogTEEB

LEAVE A REPLY

Please enter your comment!
Please enter your name here