¿Cuánto tiempo pasas haciendo revisiones de códigos de pares?¿Cuánto tiempo pasó haciendo revisiones de códigos de pares?
¿Lo revisa todo?
Estoy tratando de presionar para obtener más revisiones de código donde trabajo en este momento y estoy tratando de tener una idea de lo que sucede en el resto del mundo.
Mi opinión es que debe revisar a un alto nivel al principio del desarrollo, centrándose en el diseño y la arquitectura, y revisar en un nivel inferior al final del desarrollo, centrándose en las eficiencias y la técnica.
Ver también
Mientras que sería bueno para codificar revisar todo, es difícil de llevar a la gente a poner en el tiempo adecuado (especialmente los nuevos en las revisiones de código formales) . Comience con revisiones informales (sobre las revisiones de hombro, revisión de registros, códigos de pares, ...) Luego agregue más revisiones formales en bloques de código importantes.
En mi lugar anterior, tuvimos un pedazo de tiempo dedicado al código revisando todo el nuevo código. Fue un asunto formal y normalmente teníamos algunos críticos que miraban cada pieza. Seguimos algunas métricas, algo así como 250 líneas revisadas por hora y dividimos las cosas en fragmentos que duraron aproximadamente dos horas. Podría ser un asunto largo y prolongado para ciertos fragmentos de código. Tenía una aplicación que tenía alrededor de 18 KB de LOC y, por lo tanto, pueden imaginarse las horas dedicadas a analizarlo.
En retrospectiva, no estoy convencido de que las semanas de revisión hayan sido siempre bien invertidas. En ese momento, no realizamos pruebas unitarias y pasamos MUCHO tiempo jugueteando con los diagramas UML en Rational Rose. No estoy convencido de que hacer eso valga la pena tampoco.
En mi tienda, tenemos un proceso de revisión de código menos formal, pero HAGO MUCHA pruebas internamente y probablemente tenga 3 veces más líneas de código de prueba que el código de producción. Esa es la parte de la ecuación, al menos para mí, que parece ser la mejor inversión para el dinero. Tener un montón de pruebas que verifiquen que las cosas funcionen como es anunciado es esencial, creo. Pero, es una filosofía que algunas personas no creen.
Estamos en el código que cada uno escribe con bastante regularidad, pero no tenemos revisiones formales del código. Creo que es algo cultural y honestamente creo que el código que escribimos en mi tienda es un código más limpio y más correcto que las cosas que escribimos en mi lugar anterior, a pesar de la falta de un proceso de revisión formal. Puede ser el calibre del desarrollador que tenemos aquí. Aquí hacemos las cosas de manera diferente y parece funcionar bien.
Con eso dicho, sin embargo, si va a hacer revisiones de código. Tiempo de presupuesto para ellos. No los convierta en una idea de último momento o intente incluirlos en algún horario. Los desarrolladores podrían hacer una observación bastante superficial del código si están presionados por el tiempo y sobrecargados tratando de lograr un "trabajo real". Cuando no contamos con el presupuesto adecuado, terminamos obteniendo poca utilidad de ellos.
Sólo mis pensamientos.
1.) Las revisiones de código deben planificarse y acomodarse en el programa.
2.) Descripción general del código/Vista previa es lo que hacemos. es decir, el autor del código explica en primer lugar la funcionalidad del código que desea revisar. Nivel de algoritmo Esto da una buena idea y antecedentes para el revisor y obtiene varias perspectivas hacia el código durante la revisión del código actual: perspectiva de funcionalidad, optimización (tiempo de ejecución/memoria) perspectiva, portabilidad, legibilidad
3.) En uno reunirse solo 2 horas de código debe ser revisado. Encontramos esto por prueba y error de que 2 horas es un tipo de caso límite (no a menos, no demasiado) manteniendo la calidad de las revisiones/comentarios de revisión
4.) Envíe el código a los evaluadores 2-3 días in avance, en función de la complejidad/LOC del código, después de que se haya realizado la vista previa.
5.) Los revisores lo revisan sin conexión y vienen a la reunión con sus comentarios.
6.) En reunión autor escucha a cada comentario opinión, acepta/rechaza con el motivo asociado
Este proceso me ha servido bien hasta ahora.
-AD