Buenas,
el post de Rodrigo Corral “En el software, la calidad, no es opcional” es un post al que hago referencia cada dos por tres como punto de entrada para explicar porqué es importante pensar en software “bien hecho” desde el día cero. Cada vez que realizamos un copy/paste de una porción de código o implementamos una “solución rápida” estamos creando un futuro problema, que a medida que pasa el tiempo, será mucho ás dificil de solucionar. Refactorizar código es importante, yo cada vez que veo código viejo, siempre pienso en mejores formas de implementarlo. Y otra gran herramienta que tenemos a nuestra disposición es la capacidad de realizar Code Review sobre nuestro código. En algunos equipos de desarrollo se describen procesos de Code Review de forma explícita, pero por lo general es una práctica que no se implementa formalemente. Sin embargo cada vez que te juntas con un compañero, a darle una mano para resolver un problema o para ver como puedes sacar adelante un requerimiento, pues estás realizando una actividad de Code Review.
Visual Studio 11 y Team Foundation 11 incluyen una funcionalidad específica para este escenario, en el que además de tener la capacidad de trabajar distribuido, tendremos trazabilidad de las acciones que estamos realizando. Por ejemplo, supongamos que con mi usuario “El Bruno” he terminado de implementar una funcionalidad determinada y quiero que otro developer me ayude a validar si la misma es correcta. Dentro del nuevo Team Explorer, podremos ver en la sección “My Work”, la acción “Request Review”.
Cuando solicitamos un Review, tendremos que definir qué developer lo realizará, y además podremos completar con un comentario, el área de trabajo, etc.
Una vez solicitado, en la sección “My Work” ya podremos ver que tenemos un Request pendiente para Julia Ilyiana de un Code Review.
Cuando Julia acceda a Visual Studio 11 y vea su trabajo para el día de hoy “My Work”, en este panel verá la solicitud de Code Review que le solicitó Bruno. Además es posible filtrar para ver las CR solicitadas y recibidas.
Cuando Julia abre la petición de Bruno, puede ver los datos de la petición. Un detalle importante es que una Code Review puede ser asignada a uno o más reviewers. Por ejemplo, Julia podría enviar sus comentarios al respecto para otro developer con más conocimientos sobre el tema. En la siguientes imágenes vemos como hemos agregado a Brian Keller como un reviewer adicional.
Una vez “revisado” el código, julia puede opinar sobre el mismo y compartir estas opiniones con los participantes del Code Review.
Este comentario puede ser un comentario general sobre los ficheros de código, o inclusive sobre una porción de código específica de una clase.
Internamente un Code Review es un WorkItem, con lo que podemos ver el histórico del mismo para ver como ha evolucionado el mismo.
Finalmente cuando Bruno vea el estado de los reviews, puede ver como han colaborado los demás participantes en el mismo y además,
Bruno ahora puede comentar o compartir nuevamente información del Review en el mismo. Además de ver los datos más específicos que se compartieron en el review.
Finalmente, cuando se cierra un Code Review, podemos consultar los datos como si fuese un WorkItem más. Sin embargo, como la información que nos muestra el Code Review no es muy práctica en el visualizados de WorkItems, podemos acceder a la vista en el Team Explorer desde el propio visor. Cool
Saludos @ Home
El Bruno
PD: por detrás de todo este proceso hay un par de ShelveSets y varios tipos de WorkItems, CodeReview, CodeReview Response, etc.
Hey, I think your website might be having browser compatibility issues.
When I look at your blog in Chrome, it looks fine but when opening in Internet Explorer, it has
some overlapping. I just wanted to give you a quick heads up!
Other then that, excellent blog!
LikeLike