Muéstrame el código

Muéstrame el código

10:41 0 Comments

En un equipo de desarrollo siempre hay ocasiones en la que alguien tiene que echar un vistazo al código de otro programador. Puede ser algo esporádico (desde peer deskcheck) a algo formal (una inspección de código en toda regla), como se describe en Peer Reviews in Software.
En posts anteriores se ha explicado cómo Plastic SCM, con su manejo de ramas, ayuda a que exista aislamiento entre los programadores, imprescindible para que tengan la estabilidad necesaria para trabajar sin interrupciones. Hoy, sin embargo, veremos cómo puede ayudar a que haya comunicación fluida.
Bien, pero dejando a un lado el por qué es bueno o necesario o símplemente inevitable hacerlo... ¿cómo se hace? Hay una respuesta muy sencilla: alguien viene, se sienta en tu ordenador, y comienza a leer el código. Pero esa no es siempre la mejor opción, quizá dos personas deben mirarlo a la vez, o símplemente mientras tú haces algo quieres que un compañero mire el código. En ese caso, ¿cómo lo haces?
Opción A: haces un zip y se lo mandas por correo a tu colega, o se lo dejas en un lugar en la red para que pueda descargarlo. El lo descomprime y le echa un vistazo, compila, prueba... de todo. No está mal. Es una opción. Claro, ¿y si quiere hacer un cambio sobre lo tuyo? Uhm... ¿No se supone que tienes un fantástico control de versiones precisamente para evitar este tipo de problemas? ¿Por qué no lo usas entonces? La respuesta puede ser la siguiente: dependiendo del SCM que tengas, puede que no sea muy buena idea crear demasiadas ramas. Entonces el modo de trabajo de los programadores es: check out, hacer cambios, probarlos, check in. Es decir, sólo se hace check in cuando todo está perfectamente terminado. En ese momento los cambios pasan a estar disponibles para los demás programadores, a través del control de versiones... ¡¡pero no antes!! Mientras no se haga check in, los ficheros modificados sólo están en el disco del programador.
Bien, pasemos ahora a la opción B. ¿No sería mejor usar el control de versiones para este tipo de cosas? Sí, pero para eso se necesita un SCM capaz de manejar correctamente las ramas. Plastic puede hacerlo, y de hecho el modo natural de trabajar sería crear una rama por cada desarrollador, o incluso una rama por cada tarea. (Leer el post sobre cambios de tarea). Con esa situación, el programador que quiere compartir su código símplemente haría check in de sus ficheros. Pasarían de estar en su disco a estar en el servidor, pero no en la línea principal sino en su rama.

Entonces, como muestra la figura, los dos programadores tienen sus workspaces, con sus selectores asociados. Los selectores indican exactamente qué debe descargarse del repositorio al workspace, de acuerdo a unas reglas. Supongamos que cada uno de los programadores tiene su propia rama: el primero una rama llamada developerA y el segundo una rama developerB. El selector del primer programador (el que quiere pasar su código al otro) sería:

  rep "default"
    br "/main/developerA" label "baseline100"
    co "/main/developerA"

Entonces, ¿qué tiene que hacer el segundo programador?
Símplemente fijar el mismo selector para que su workspace contenga lo mismo que el de su compañero. Como decía, nada de zips... Y si durante la revisión encuentra un problema sólo tiene que hacer checkout, y todo funcionará (y por supuesto el sistema sabrá que fue él quien hizo el cambio, aunque la rama fuera propiedad del otro programador).
¿No es más sencillo? Sí, y aumenta la productividad y es menos propenso a fallos y... un sinfín de ventajas... :-)