source software open project-management agile code-review

project management - software - Revisión de código



collaboration software (24)

Exigimos el uso de herramientas siempre que sea posible, principalmente para tratar de reducir los gastos generales de las revisiones de códigos. 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 eliminan muchas de las pruebas de sintaxis difíciles que un desarrollador tiene que hacer.

Eclipse / IntelliJ IDEa contiene increíbles advertencias en línea.

Aunque me gustaría ser completamente ágil, no podemos debido a una gran cantidad 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 tratado de 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

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

"como el mejor" depende de tantos factores:

  1. El producto en sí ¿Es vital / misión crítica?
  2. El costo de la reparació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.

Este tipo de factores debería impulsar el nivel apropiado de revisión del 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.

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

Versión corta: los cambios se desarrollan en las sucursales, que se revisan (y se revisan para ver si se pasan las pruebas) antes de fusionarse. Si el código fusionado causa una regresión, se revierte del enlace troncal.

En general, trate 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 vi, o incluso alguna optimización en 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 a la semana y revisemos los cambios principales que hicimos, brevemente. Me imagino que eso ayudará también, pero no puedo imaginar que se reemplace la revisión del código de 1 en 1 para los controles principales (incluso los breves resultarán beneficiosos).

Estoy de acuerdo con el Desarrollador 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

Hacemos desarrollo distribuido, por lo que sentarse juntos en una habitación es imposible cuando estamos a cientos de kilómetros 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 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 que estos sigan 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, emparejamos el diseño y el desarrollo 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.

Mucho depende del maquillaje de tu 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 juntar a algunos miembros del equipo con un proyector y revisar el código todos los viernes u otro período de tiempo.

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.

/Alano

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 arrojar personas a una habitación, creemos que es mejor que al menos alguien lo haya visto, ya que dos pares de ojos son mejores que uno.

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.

Diría que una buena forma de lograr que los desarrolladores trabajen juntos y aprendan unos de otros es convertirla en 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.

Usamos la programación de pares y tendemos a no hacer una revisión del código con todo el equipo presente, sino revisiones de la 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.

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

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

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 encuentra que se puede hacer mejor cuando se revisa el código. Es mucho mejor revisar el código antes de probar cuando sospechas más del código, para que no comiences a pensar que funciona.

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 usar 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 se etiqueta con la identificación del error o la solicitud de función (para el nuevo código), y eso permite algo de rastreo.

Por último, la participación de QA significa que su prueba del código proporcionará cierta validación.

En cuanto a la eficiencia del código, eso se hace un poco más estadísticamente ya que 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.

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

Mi favorito es agregar [Reviewer: name] a cada comentario de compromiso. 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 debe preguntar al revisor. Esto asegura que los revisores entiendan completamente el código comprometido.

Me he sentido frustrado por la manera en que se han realizado las revisiones de los códigos en los equipos en los que he trabajado. A menudo es un trabajo casual de dos minutos que es un ejercicio de tic-tac-box glorificado. 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. Explica el contexto del cambio que estoy revisando.
  2. Muéstrame tus pruebas unitarias.
  3. Muéstrame tu código.
  4. Mostrarme cero alertas de StyleCop y cero violaciones de FXCop.
  5. Muéstrame todo este edificio en el servidor de integración continua.

Todo lo que comprometemos se revisa, generalmente antes de que se cometa. 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 nuestra propia comida para perros'' 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.

Creamos el proceso de revisión de código basado en la herramienta de revisión de código como gerrit y dividimos la política en diferentes niveles en diferentes fases

  1. A los desarrolladores se les recomienda hacer programación de pares al escribir códigos, 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 lleguen a la rama maestra (principal) y el sistema de integración continua (CI) se habilita para la verificación, todos los posibles problemas detectados automáticamente se revisan automáticamente en CI (reglas de código).
  3. La revisión del código manual basada en la web se inicia solo si se pasan los primeros códigos de verificación (cobertura de pruebas unitarias, posible caso de prueba de aceptación), se involucrará a más personas mayores y a la comunidad de desarrollo de productos.

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

  • eficiencia, la verificació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.

Por cierto: Gerrit se usa solo para git, puedes consultar otras herramientas de revisión basadas en la web.

Reviewboard es una buena herramienta para revisar los códigos.

En general, hay dos formas de revisar el código del equipo. Una es la revisión previa al compromiso, 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Í, luego el código puede enviarse al servidor de códigos.

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 algunos códigos para revisarlos, luego modificarlos y volver a enviarlos al servidor de códigos.