03 June 2007

Práctica de Peer Reviews

Hay dos temas que motivan este escrito. El primero es la experiencia de haber pasado por varios peer reviews en los últimos días, donde me sentí en cada una de esas sesiones aplicando repetitivamente las mismas prácticas. Fueron efectivas y lo han sido desde hace algún tiempo, así que considero vale la pena identificar cuáles son y compartirlas. La segunda motivación nace de una pregunta que he realizado en varias oportunidades a mis alumnos de Ingeniería de Software de la USB; ¿si comparan el código que ustedes están produciendo actualmente con el de un equipo de desarrolladores con amplia experiencia produciendo software de calidad mundial, en qué se diferenciaría?. Creo que ambos temas están muy relacionados y son claves en la calidad técnica del software.

El ojo de un experto en su área de experticia, busca de forma natural las anomalías o carencias que pueda tener el producto en cuestión. ¿Cuáles son esas anomalías o carencias que se deben identificar en el código fuente y que deben saltar a la vista del ojo experto en una inspección de código?.

La revisión que suelo aplicar va en dos bloques. El primero relacionado con la correcta y clara definición de lineamientos de diseño y de arquitectura y por supuesto su cumplimiento. El segundo se enfoca en el cumplimiento de la funcionalidad establecida y la búsqueda de defectos.

Bloque de lineamientos de arquitectura

El diseño de la arquitectura de un sistema debe abarcar una serie de aspectos básicos que garanticen uniformidad en la implementación del sistema. Particularmente en las revisiones me fijo en los siguientes; Capas, Asignación de responsabilidades, Uso de patrones, Componentización de alto nivel, Manejo de excepciones y Generación de trazas para auditoría. Claro que hay otros, pero si se cumplen éstos seguramente tendremos una arquitectura bastante sólida.

Una secuencia de acciones para realizar la revisión en base a estos parámetros podría ser la siguiente:

  • Buscar que en el documento de arquitectura estén claramente definidas las capas del sistema. Si la solución está compuesta por varios sistemas, aplica la secuencia a cada una.
  • Debe establecerse para cada capa quiénes son los responsables en recibir las comunicaciones, en comunicarse con otras capas y cuál es el lenguaje que hablarán las capas entre si (tipos de datos simples, objetos de negocio, etc.).
  • Las responsabilidades en cada nivel de la arquitectura lógica deben estar claras y ser consistentes. Quién valida parámetros de otra capa, quién crea objetos de negocio, quién interactúa con cada ente externo, quién interactúa con el repositorio, quién contiene la lógica de reglas de negocio, son algunas de las muchas preguntas que siempre es útil hacerse y cuyas respuestas deben estar claras.
  • Qué patrones se están usando y por qué?. Qué piezas o componentes considera las más complejas? qué patrones usan éstas?, si no usan ninguno hay alguno que podría ayudar?.
  • Siempre debemos poder mostrar una vista de componentes y debe estar claro cómo interactúan entre ellos, sus interfaces y responsabilidades.
  • Debe en el documento de arquitectura o su equivalente estar un diagrama de clases de las excepciones a utilizar y estar definido cómo y cuándo se utilizarán, también debe estar definido de quién es la responsabilidad de capturarla en cada caso. Cuáles son posibles extender y cuáles no.
  • Quién ha tenido la experiencia de tener que mantener un sistema en producción ha aprendido la utilidad de las trazas de auditoría de primera mano. Debe estar claro cuál es la estrategia a seguir en las trazas, en qué puntos deben generarse siempre, en cuáles es opcional, cuántos niveles se utilizarán y qué tipo de mensajes van en cada uno.
  • Para validar posteriormente que todo lo anterior que está en la documentación se cumpla efectivamente en la implementación, se seleccionan un par de funcionalidades (casos de uso), y se revisan siguiendo su código fuente tal como lo haría durante su ejecución, desde las capas superiores a las inferiores.
Para todos los puntos anteriores las respuestas deben estar en la documentación, sino están y alguien debe explicarlo entonces está incompleta. Cada respuesta que alguien da debe anotarse y luego incorporarse al documento correspondiente. Es una buena forma de identificar los puntos de mejora de la documentación.

De contar con la disponibilidad de tiempo suficiente, podrían tomar en cuenta otros aspectos como Paquetes, Idioma del código fuente (es común y poco deseable el spanglish) y Uniformidad en los nombres.

Este primer bloque de prácticas se aplica cuando se realizan las primeras inspecciones de un proyecto. En sucesivas sesiones, cuando ya se ha garantizado que la arquitectura y los lineamientos de diseño están suficientemente maduros, la actividad puede enfocarse sólo en el segundo bloque.

Bloque de búsqueda de defectos

En el segundo bloque se revisa un conjunto de casos de uso o funcionalidades seleccionadas, el objetivo es verificar que la implementación efectivamente cumple con los requerimientos establecidos y tratar de identificar potenciales defectos.

La revisión al igual que en el bloque anterior es recomendable hacerla siguiendo el código fuente tal como se ejecutaría, línea a línea.

Durante estas revisiones tenga siempre en mente los lineamientos validados en el primer bloque, siempre es posible encontrar puntos donde no se cumple lo establecido y es pertinente alertar para que sea corregido.

Qué relación tiene lo anterior con la pregunta inicial sobre la diferencia del código fuente de un grupo de estudiantes con el de un equipo de desarrollo experto?, creo que los puntos del primer bloque son los principales diferenciales, ya que son continuamente reforzados por la experiencia.

Peer Reviews es todo un tema y existe amplia bibliografía al respecto, Peer Reviews in Software de Karl Wiegers es una muy buena opción para adquirir una base metodológica en el tema.


2 comments:

Unknown said...

Pedro está muy interesante tu artículo. Escribí algunos comentarios sobre temas relacionados que ya hemos conversado aquí.

Unknown said...

Epa Peter.

Excelente tu iniciativa de este blog, es bueno inclusive para a aquellos que nos somos "computistas" pero que nos apasiona la tecnología.

Saludos,

Yisus.