El Bruno

Buenas,

en navidades y año nuevo con el Javi éramos los únicos en La Finca trabajando. Nos tocaba la agradable tarea de preparar scripts de despliegue, probarlos en local, después ver como fallan en el entorno de pruebas y ni hablar en PRE y PRO. Pero bueno, como el Javi es nicotinero, yo lo acompañaba a que sacie su vicio y entre una cosa y otra nos pusimos  a hablar del interesante y recurrente tema

¿Cada cuánto es recomendable hacer CheckIn mientras modifico código compartido? (o proteger código en el repositorio)

Pero el tema era bastante más específico, ya que hablamos de lo que sucede si tomamos una gran porción de código y comenzamos a trabajar y mejorar la misma. En este caso, ¿debo proteger mi código al final del proceso de refactoring?¿o hacerlo más frecuentemente cuando aplico voy aplicando pequeños cambios? Veamos algunos ejemplos:

En el primer caso, es bastante frecuente ver cómo una persona toma una porción de código durante un par de días, se dedica a jugar con las mismas, y al cabo de 48 horas decide proteger los cambios que ha realizado. Si está trabajando en un equipo conjunto y ha modificado elementos comunes como por ejemplo la definición de un proyecto, pues es muy probable que tenga que hacer una o más acciones de MERGE. Si además ha modificado clases que estaban siendo utilizadas por otros compañeros, pues el MERGE será más delicado.

Después de presentar este ejemplo, tal vez alguien piense que la solución es proteger más frecuentemente. Supongamos que por cada modificación “leve” que aplicamos en nuestro proceso de refactoring, y realizamos un CheckIn. En este caso, debemos tener muy afinado el funcionamiento del equipo de desarrollo, pues es en ese momento cuando los demás integrantes deberán evaluar si necesitan obtener la última versión de SC y la misma pregunta deberá hacerse la persona que está realizando el refactoring.

Como vemos ninguno de los dos casos es una solución completa para este escenario. Yo desde mi humilde opinión puedo sugerir lo siguiente para este ejemplo:

• Evalúa los cambios que realizas e intenta que los mismos sean significativos para el código. Es decir que no sea una línea de comentario, ni la destrucción y reemplazo total de 20 clases por 7 nuevos proyectos diferentes .
• Siempre debes cumplir con las premisas básicas antes de proteger código > verificar que compile y que se pase la última versión de las pruebas unitarias.
• Si te encuentras frecuentemente con “clases” sobre las que están trabajando 2 personas (o más), evalúa si estás cumpliendo los principios SOLID. Que 2 personas trabajen sobre la misma clases suele ser indicador de que esa clase está asumiendo demasiadas responsabilidades
• Si cumples los principios SOLID, pero todavía te encuentras con 2 personas trabajando sobre la misma clase; pues dale un toque a la persona que reparte las tareas en el equipo ya que seguro que hay algo que no cuadra.
• Comenta este trabajo con tus compañeros. La reunión diaria de “puesta al día” es un momento ideal para comentar este trabajo.
• Finalmente, recuerda que en un equipo se debe respetar el principio de la propiedad compartida del código. Cada cambio que aplicas repercute en el trabajo de tus compañeros y nadie es responsable y “amo” de una única porción de código.

Y para cerrar, el clásico de cada día cuando nos pasan estas cosas … (fuente http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0162fe399bd1970d-pi)

Saludos @ Here

El Bruno

Geek And Poke : http://geekandpoke.typepad.com