Revisión de código

Question

¿Qué política de revisión de código puede recomendar como la mejor para el proyecto que está gestionando?

Answer 1

no pudo resistir:

alt text http://www.osnews.com/images/comics/wtfm.jpg

Answer 2

Mucho depende de su maquillaje equipo. Personalmente, he tenido éxito haciendo la programación de pares y cambiando sus pares cada dos horas. Si se hace bien, esto puede ser más eficiente que una revisión del código.

Otro método es simplemente obtener algunos miembros del equipo junto con un proyector y revisar el código todos los viernes u otro marco de tiempo.

Answer 3

En general, trato de tenerlos en lugar de no tenerlos ... cada vez que tengo una revisión de código, casi siempre obtengo algunos consejos realmente buenos para modificar algo de una buena manera, o eliminar alguna duplicación que no hice No veo, o incluso alguna optimización de cómo uso mi entorno (shell, IDE, Emacs, etc.).

Un compañero de trabajo sugirió una vez que todos nos juntamos en una sala una vez por semana y revisemos los cambios importantes que hicimos, brevemente. Me imagino que eso ayudará también, pero no puedo imaginar que se reemplace la revisión del código 1 en 1 para los principales checkins (incluso los breves serán beneficiosos).

Answer 4

Aquí está la política de revisión de código que utilizamos en el trabajo: http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem

versión corta: los cambios se desarrollan en las ramas, que son revisadas (y se analiza pruebas de pasada) antes de que se fusionaron. Si el código fusionado causa una regresión, se revierte del enlace troncal.

Answer 5

revisa solo los cambios de código desde el código base y utiliza algunas herramientas gratuitas para comparar archivos.

Answer 6

Tenemos 5 desarrolladores en diferentes niveles en mi organización; como tal, la revisión del código a veces es más una herramienta de enseñanza que una revisión, per se '. Sin embargo, al compartir el código entre los desarrolladores (y mediante el uso diligente del control de la fuente) la calidad del código ha aumentado significativamente.

Yo diría que una buena manera de hacer que los desarrolladores trabajen juntos y aprendan unos de otros es hacer que sea una experiencia de intercambio, no tanto una revisión. Le da un giro diferente y creo que los desarrolladores se vuelven un poco más dispuestos y menos sensibles acerca de su (s) fragmento (s) de código particular. YMMV.

Answer 7

Estoy de acuerdo con el desarrollador de SaaS que la programación de pares produce buenos resultados. Sin embargo, la pregunta también depende de otros factores, como el tamaño del equipo y el modelo de desarrollo, por ejemplo. Por último, el siguiente enlace lo dirigirá a una herramienta web de revisión de código que puede serle útil.

Rietveld

Answer 8

Mi equipo es demasiado pequeño y el código es demasiado para revisar a través de un proceso de revisión formal.

En cambio, lo que he encontrado eficaz es utilizar el sistema de control de versiones para enviar correos electrónicos cuando se envían correos electrónicos. SVN/CVS-> correo electrónico va a todos los miembros del equipo que, parcialmente por curiosidad, revisarán los envíos. Además de esto, las presentaciones de código por parte de los desarrolladores para los módulos principales son eficaces para mostrar parte de su trabajo.

Cada check-in está etiquetado con la identificación del error o la solicitud de función (para el nuevo código), y eso permite algo de rastreo.

participación del último control de calidad significa que sus pruebas del código proporcionará alguna validación.

En cuanto a la eficiencia del código, que ha hecho un poco más como estadísticamente no tenemos el tiempo para revisar los algoritmos. Finalmente, me gustaría vincular nuestros verificadores de carga al proceso y hacer que ejecuten las pruebas de carga automáticas con más frecuencia.

Answer 9

"como el mejor" depende de muchos factores:

1. El producto en sí. ¿Es vital/misión crítica?
2. El costo de la fijación posterior a la publicación. Compare el costo de un parche de software para PC en una docena de máquinas contra el retiro de millones de tarjetas inteligentes con un defecto de código incrustado.

Estos tipos de factores deben impulsar el nivel adecuado de revisión de código. Dependiendo de la necesidad, podrían ser controles informales, revisión basada en listas de verificación, programación de pares o inspecciones intensivas similares a Fagan.

Answer 10

Utilizamos la programación en parejas y que tienden a no hacer la revisión de código con todo el equipo presente, pero las revisiones de arquitectura. También trato de sentarme con un programador y hacer una revisión general del código de las características importantes o cuando están usando una nueva herramienta/tecnología. También documentamos las mejores prácticas y patrones extraídos de estas revisiones en una wiki interna.

Answer 11

Nuestro proceso de revisión de código es muy sencillo. Antes de que se publique una corrección/función, se recomienda encarecidamente que se revise. Las revisiones las hace "la persona a su izquierda" y solo abren la ventana de registro de subversión y verifican los diffs. Hacen sus comentarios al autor original, y anteponen un "+" al mensaje de registro para indicar que ha sido revisado y luego ponen sus iniciales en la parte inferior. Esto facilita el proceso de lanzamiento para identificar compromisos específicos que no se han revisado y podemos dividir los commits sin revisar antes de que se libere el código.

En lugar de tirar personas en una habitación, creemos que es mejor que al menos alguien lo haya visto, ya que dos pares de ojos son mejores que uno.

Answer 12

No se debe registrar ningún código sin al menos una revisión. Disminuirá las cosas al principio hasta que te des cuenta de que tienes más bolas en el aire, pero te salvas de hacer algo estúpido y alguien más está familiarizado con tu código.

/Allan

Answer 13

Nos exigen el uso de herramientas siempre que sea posible, sobre todo para tratar de reducir la sobrecarga de revisiones de código. Con herramientas para aligerar la comprobación de la sintaxis aburrida, el revisor puede concentrarse en los problemas de diseño.

Cruicble by Atlassian es fantástico para hacer revisiones de código "en línea".

Findbugs/PMD/Checkstyle eliminar una gran cantidad de la sintaxis más incómoda comprueba un desarrollador tiene que hacer.

Eclipse/IntelliJ IDEA contienen advertencias en línea increíbles.

Mientras me gustaría ir totalmente ágil, no podemos debido a una miríada de razones por las que no voy a entrar aquí. Sin embargo, lo señalaré en un documento que le dará una idea de algunas de las técnicas "ágiles" que hemos intentado incorporar a un proyecto de "cascada" con lo que creo que es un éxito bastante razonable.

http://www.aswec2008.curtin.edu.au/IndustryReport/Morgan%20-%20Agile.pdf

Answer 14

Nosotros distribuimos el desarrollo, así que sentarse juntos en una habitación es imposible cuando estamos a cientos de millas de distancia. Así que hemos establecido tiempos dos veces por semana cuando revisamos el código, todos conectados a una máquina de escritorio compartida.

Cualquiera puede traer el código para revisar, nadie está exento de revisión, todo el código debe ser revisado antes de ser puesto en el hilo principal. Y todo está abierto para su revisión, desde el software de prueba hasta los casos de prueba hasta el código fuente. Si vale la pena hacerlo, vale la pena hablar con el equipo y vale la pena tener otros ojos mirándolo.

Analizamos y discutimos de todo, desde simples errores hasta la organización de archivos fuente y estándares de codificación (estamos lo suficientemente adelantados en el proyecto como para seguir evolucionando). No es una inspección formal (aunque hacemos eso cuando el equipo decide que es necesario), por lo que está dirigida por el autor. Hacemos comparaciones con versiones anteriores y algunas veces rebotamos de un archivo fuente a un archivo fuente para responder preguntas.

Mientras tanto, hacemos diseño y desarrollo de pares de forma ad hoc. Las parejas evolucionan de día a día y de semana a semana a medida que avanzamos en el proyecto. Nuevamente, debido a que las personas son remotas, se realiza a través de conexiones de escritorio compartidas y similares.

Answer 15

El psp uno

Answer 16

trabajé en un proyecto que requiere otro conjunto de ojos en cualquier código antes de comprometerse. El registro de confirmación debe indicar para quién fue revisado el código.

Answer 17

Hemos integrado el proceso de revisión de código como un paso de flujo de trabajo en Jira. Cuando un desarrollador realiza cambios en la línea principal, marca el problema como arreglado en jira y se lo envía a alguien para que lo revise. Pueden rechazarlo o enviarlo para probarlo.

Siempre hay algo que se puede encontrar mejor cuando se revisa el código. Es mucho mejor revisar el código antes de las pruebas cuando sospechas más del código, para que no comiences a pensar que funciona.

Answer 18

Uso el tronco como una rama "Hecho" (es decir, liberable) e incluyo Revisión de código en la "Definición de Listo". En otras palabras, el código no se puede fusionar en la rama "Hecho", siempre que no se haya revisado.

Answer 19

Mi favorito es agregar [Reviewer: name] a cada comentario de confirmación. De esta manera, se asegura de que haya más de una persona en la empresa que sepa qué se hizo.

Si hay un problema con la confirmación, primero consulte al revisor. Esto asegura que los revisores entiendan completamente el código comprometido.

Answer 20

Rietveld parece interesante, basado en Mondrian, una herramienta web para la revisión de código desarrollado en Google por Guido Van Rossum (de Python fama)

Permite revisiones de código a suceder en cualquier momento y no requiere de cara a cara contacto.

http://code.google.com/p/rietveld/wiki/CodeReviewBackground

demostración aquí
http://codereview.appspot.com/

Answer 21

he visto frustrados por la forma en que las revisiones de código se han hecho en los equipos que he trabajado. A menudo se trata de un trabajo ocasional de dos minutos que es un glorificado ejercicio de tic-tac-caja.De hecho, escribí un blog sobre lo que llamo Drive-By Code Review y enumeré un proceso de 5 puntos que me gustaría ver.

En resumen

1. Explicar contexto del cambio soy de revisión.
2. Muestra tus pruebas unitarias.
3. Muéstrame tu código.
4. Muestrame cero advertencias de StyleCop y cero infracciones de FXCop.
5. Muestrame todo este edificio en el servidor de integración continua.

Answer 22

Todo lo que confirmamos se revisa, generalmente antes de comprometerse. También hacemos integración continua, por lo que incluso si alguien hace algún cambio que piensan que es trivial y rompe la construcción, queda atrapado.

OTOH, trabajo para SmartBear Software, así que por supuesto 'comemos nuestro propio dogfood' y usamos Code Collaborator internamente. Debo admitir que nunca había revisado el código antes de empezar a trabajar aquí, y también que me sería difícil imaginar volver a introducir código sin revisar.

Answer 23

Hemos construido el proceso de código de revisión basado en la herramienta de código de revisión como gerrit y dividir la política en el nivel diferente en diferente fase se recomiendan

1. Desarrolladores de hacer programación par al escribir códigos, que puede evitar un gran error y mejorar el intercambio de conocimientos.
2. La herramienta de revisión de código Gerrit se usa antes de que los códigos ingresen a la rama maestra (principal) y el sistema de integración continua (CI) está habilitado para la verificación, todos los posibles problemas detectados automáticamente son revisados ​​automáticamente en CI (reglas de código).
3. Revisión del código manual basado en web se inicia solo si se pasan los códigos primera verificación (cobertura de prueba de unidad, posible caso de prueba de aceptación), se involucrará a más personas mayores y comunidad de desarrollo de productos.

política de revisión de código debe ser

eficiencia

• , la comprobación automática de la calidad del código tanto como sea posible de IDE a CI.
• revisión del código social, más ojos para los códigos, mejor calidad.

BTW: Gerrit solo se utiliza para git, puede consultar otras herramientas de revisión basadas en web.

Answer 24

Reviewboard es una buena herramienta para que revise los códigos.

Generalmente, hay dos maneras de revisar el código del equipo. Una es la revisión precomprometida, significa que cuando el desarrollador envía el código al servidor, el código se detiene y debe ser revisado por desarrolladores de alto nivel, cuando este hombre dice SÍ, entonces el código puede enviarse al servidor de código.

Otra es la revisión posterior, es decir, después de que los códigos se enviaron al servidor de códigos, algunos desarrolladores de alto nivel pueden seleccionar algún código para revisar, luego modificarlos y volver a enviarlos al servidor de códigos.