¿Cómo se hacen revisiones de código?

Question

Recientemente me mudé de una empresa con aproximadamente 30 desarrolladores, todos basados ​​en el mismo sitio, a una empresa más pequeña con un total de 6 desarrolladores que trabajan en todo el país.

Anteriormente, cuando realizaba revisiones de código, tenía a la persona sentada a mi lado, o iba a su PC y revisaba el código con ellos.

En mi nueva compañía esto no es factible ya que la gente está por todas partes. Me han pasado un par de miles de líneas de código para revisar y no puedo simplemente decirle a alguien mis pensamientos.

La única forma en que puedo pensar es en escribir un documento de revisión de código. Así que he recurrido a pegar el código en Word y anotarlo usando las pequeñas burbujas de margen que obtienes.

¿hay alguna manera más fácil de hacerlo? Durante mucho tiempo pensé que Visual Studio debería tener un sistema de comentarios meta, que le daría características de esquema similares, y le permite escribir comentarios en un nivel superior.

¿Hay alguna herramienta que haga esto? Si no, ¿cómo hacen las personas para hacer revisiones de códigos distribuidos?

Answer 1

Que le gustaría leer el libro inteligente Bear: Best Kept Secrets of Peer Code Review

Se es libre de (incluyendo el envío si usted está en los EE.UU.) por lo que hay pocas razones para no conseguirlo. Por otro lado, es un gran librito con ejemplos del mundo real sobre la mejor manera de hacer revisiones de códigos de pares, por lo que hay muchas razones para pedirlo.

Answer 2

JIRA tiene la opción de asignar a alguien para revisar el código de su trabajo, él/ella puede luego dar comentarios dentro de JIRA.

Answer 3

Estábamos exactamente en el mismo barco - los desarrolladores de todo el país, no hay tiempo suficiente solapamiento durante el día ... Todos los que trabajan de forma asíncrona ... Así que tuvimos que subir con una herramienta en línea de código de revisión.

Terminamos con un proceso razonablemente ligero: - Para cualquier pieza de código no trivial, una revisión por pares es obligatoria. - Para realizar una revisión, el autor crea una "lista de cambios empaquetada" (verifique su comunidad de control de fuente para tales cosas). Básicamente es un archivo ZIP expandible de un solo archivo de todos los cambios realizados en este pedazo de trabajo. - El autor envía un correo electrónico al revisor con la lista de cambios empaquetada (¡tenga en cuenta que aún no la enviaron!) - El revisor procesa el código de forma asincrónica y lo incluye en un correo electrónico - Si el revisor tiene problemas graves objeciones, el código no puede entrar hasta otra ronda de revisiones; de lo contrario, el autor puede registrarse después de corregir las sugerencias O abrir errores para corregir las sugerencias.

Answer 4

Ojalá hubiera un mejor soporte para este tipo de tareas integradas en Visual Studio. Sin embargo, hay algunos complementos interesantes que pueden ayudar. Si está utilizando Visual Studio Team System eche un vistazo a TeamReview. Le permite generar elementos de trabajo de revisión de código especiales que pueden ser "reproducidos" posteriormente.

TeamReview screenshot http://www.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=TeamReview&DownloadId=32263

Answer 5

Mira la sugerencias de esta pregunta:

https://stackoverflow.com/questions/403/tool-to-aid-code-review

Answer 6

http://www.review-board.org/

vi este proyecto no hace mucho tiempo, tal vez se puede conseguir votado arriba si la gente lo usa .

Answer 7

Si es posible, comience con casos de prueba: haga que la persona lo guíe a través de los casos de prueba. Muestra el diseño y lo que el desarrollador pensaba que resolvería el problema (s). Sumérgete en casos de prueba y mira el código.

Además, eche un vistazo a los informes de cobertura de código generados automáticamente a partir de una compilación. Puede ser una buena métrica en las rutas de prueba.

Ahí es donde comenzaría.

Answer 8

Tenemos desarrolladores en todo el mundo. Usamos Smart Bear's Code Collaborator. Al igual que cualquier herramienta, no es perfecta, pero sin duda hace el trabajo. Está basado en la web y es fácil de aprender.

Answer 9

Hemos tenido cierto éxito utilizando la función de estante de TFS para hacer revisiones de código distribuido. Con el uso de shelvesets, un desarrollador puede "registrar" un conjunto de cambios sin comprometerlos con la sucursal. Otro desarrollador puede desmantelar el conjunto de cambios y revisar los diffs contra la rama comprometida. Una vez que todos los interesados ​​estén contentos con el conjunto de cambios, están comprometidos con la sucursal.

Answer 10

Hay una herramienta: http://www.smartbear.com/codecollab.php

Answer 11

Un proceso muy ligero que hemos utilizado es el uso de Microsoft y Skype SharedView tanto tener sesiones de programación pareja y hacer revisión de código. De acuerdo, no es tan formal como una política de check-in, pero podría ser un buen lugar para comenzar a fin de desarrollar estándares antes de conmemorarlos en una política de check-in.

Answer 12

En la empresa para la que estoy trabajando, los parches generados a través de SVN se envían diariamente en un grupo de noticias. La revisión del código en vivo sigue siendo la manera más eficiente de completar una revisión, sin embargo, dado que estamos trabajando en equipos virtuales con desarrolladores en todo el mundo, en algún momento es imposible que el desarrollador y el revisor hablen entre sí.

Para ayudar a nuestros desarrolladores a realizar las revisiones, hemos creado una lista de verificación de revisión de código (disponible en: http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31).

Nuestro secreto detrás de las revisiones del código: revisión pequeña, revisión a menudo.

Answer 13

Bueno, le diré lo que hace mi empresa, ya que funciona bien para nosotros (aproximadamente 10 desarrolladores más PM personas). YMMV.

Hacemos nuestra gestión de cambios usando Subversion y ClearQuest (se usa para usar ClearCase, buscando deshacerse de CQ). Hacemos nuestros cambios, creamos archivos de parches usando subversion y luego colocamos el parche en el registro CQ y pasamos el CQ. Baja tecnología, pero funciona. Obviamente, puedes modificarlo para que funcione con la aplicación de ticketing que utilices.