¿Revisión por pares, programación en pares o ambas?[cerrado]

Question

• ¿Participa en revisiones de código por pares o practica programación en pares, o ambas?
• ¿Ha podido demostrar un aumento en la calidad del software utilizando estas prácticas?
• ¿Qué beneficios y desventajas ha observado en el curso de la práctica?
• ¿Qué obstáculos enfrentó para la implementación?

En mi caso, nuestro equipo de desarrollo realizó revisiones por pares de varios artefactos de software diferentes (análisis de requisitos, planes de prueba, código, etc.).La programación entre pares ni siquiera se consideró una opción.

La práctica de revisión por pares fue impulsada desde arriba y los desarrolladores nunca la aceptaron.Teníamos un grupo SQA externo que recopilaba métricas de las actividades, pero las cifras eran bastante inútiles ya que el esfuerzo fue poco entusiasta.Después de años de que esta fuera la forma "oficial" de hacer las cosas, los desarrolladores han llegado a ignorar colectivamente los procedimientos prescritos.

Ahora hay menos visibilidad sobre cuándo se introducen errores en el ciclo de vida.Y no realizar revisiones por pares ha llevado a una mayor especialización en el equipo... donde nadie conoce realmente los requisitos/lógica de los componentes fuera de su propia área especializada del sistema.

Sería valioso conocer sus experiencias con revisiones de pares o programación en pareja, especialmente historias de éxito.

Answer 1

Cuando era joven y tonto, uno de mis primeros trabajos fue crear un analizador para extraer ciertos campos en un archivo pdf largo que se volcaba en texto sin formato.Sabía lo suficiente como para usar alguna forma de expresión regular, pero no lo suficiente sobre expresiones regulares para hacer bien el trabajo.Varios días después terminé la tarea, pero en la revisión por pares me quedé destrozado al saber que podría haberlo hecho mejor y que lo que produje fue basura.Aprendí a hacer análisis léxico solo para demostrar que no era un idiota, pero digamos que el proceso de revisión por pares apestaba.No necesitaba una persona de alto nivel que bailara sobre mis fracasos, necesitaba un mentor y me lo recordé cada vez que hice una revisión por pares.

Me gustan las revisiones de pares cuando controlamos los egos en la puerta.(¡Esto incluye el mío!) Hay una cantidad finita de tiempo en este mundo, y hay mucho que puedes aprender y hacer.A través de una buena revisión por pares, puede ampliar sus conocimientos y hacer más cosas en menos tiempo.Los problemas surgen cuando las cosas se degradan hasta una verificación de sintaxis excesivamente anal.

Tengo algunas reglas debido a esto.No reviso por pares nada que podamos automatizar.Ejecute un corrector ortográfico y embellecedor de código.Si tiene algo como FXCop disponible, ejecútelo, haga lo que dice o tenga una muy buena razón por la que no lo está.Luego podemos ver cómo está elaborado el código, cómo funciona y qué podemos hacer para mejorarlo.De esta manera obtienes una perspectiva diferente sobre cómo resolver un problema y por qué alguien piensa de esa manera.A veces, la otra manera no es realmente mejor, a veces la nueva solución es fantástica y es algo que usarás por el resto de tu vida de programación.Una vez hecha la revisión, eso es todo, no lo usaré como ejemplo en tu contra.Es tuyo aprender lo que quieras de ello.No me las arreglaré con miedo ni con amenazas, eres una persona inteligente y dejaré que lo demuestres.

Answer 2

Intentamos asegurarnos de que ningún código entre en producción sin haber pasado por al menos otro par de ojos.
Por lo general, significa que revisamos el código.Intentamos que el equipo tenga el hábito de que las revisiones sean una parte inherente de la escritura de código.Lo escribes y luego le pides a alguien su opinión.
Además, en proyectos donde tenemos suficiente gente disponible (es cuando las tareas son del tamaño adecuado) intentamos emparejar la programación.
Debo decir que definitivamente hemos visto una ventaja en esto.En primer lugar, es una excelente manera de orientar a los desarrolladores junior en el equipo: cuando revisas su código, puedes mostrarles qué se puede hacer mejor y, al trabajar con ellos, pueden ver mejores formas de hacer las cosas, cómo las personas con experiencia pensar e incluso cómo utilizar mejor el IDE.
Además, mantiene a todo el equipo sincronizado en cuanto a saber cómo se ve el código.
Y, además, simplemente aumenta la alegría y el desarrollo personal de todos: un equipo que es capaz de hablar y razonar sobre código es un mejor equipo, un equipo que sigue aprendiendo y compartiendo.

Algunas cosas a tener en cuenta:

• Asegúrese de que los mayores dejen que los jóvenes también programen cuando formen parejas
• No permita que las personas trabajen en tareas pequeñas, ya que normalmente es una pérdida de tiempo.
• Observe cómo se llevan las parejas (no fuerce a una pareja a unirse)
• Recuerda reorganizar las parejas de vez en cuando.
• No dejes que las reseñas coincidan con el ego, no dejes que la gente aplaste a los demás.

Answer 3

La revisión por pares debe ser OBLIGATORIO.

Puede leer y encontrar numerosos artículos y libros que analizan diferentes formas de abordar esto dentro de equipos de varios tamaños, pero parece que pregunta sobre experiencias.

Personalmente, creo que la revisión por pares debería ser divertida.Se proporciona comida y se mantiene el ambiente jovial.Realmente debería tratarse como un momento en el que los desarrolladores/programadores puedan aprender unos de otros, no como una oportunidad para juzgar (y todos sabemos que cada programa parece nacer con un gen crítico innato).He tendido a apreciar o ayudar a organizar las revisiones para que estén abiertas 1/3 o 1/4 del tiempo.Con esto me refiero a cuando el grupo se reúne y una persona presenta un proyecto en el que está trabajando o incluso revisando y que ni siquiera está relacionado con el proyecto actual (sé que esto es difícil con los plazos, pero inténtalo).

Los creativos suelen reunirse para mostrar pinturas, diseños y artistas que les interesan actualmente para ayudar a facilitar la inspiración.De manera realista, la inspiración debería ser el concepto principal que espera fomentar en una revisión.En segundo lugar, las personas simplemente notan cosas que hacen sus compañeros desarrolladores y que NO habían notado antes.“Oh, vaya, ¿conseguiste hacer eso en una sola línea de código?Fresco." Inspirarse y motivar a los desarrolladores sobre lo que hacen, en qué están trabajando y cómo lo hacen pagará más dividendos que usar la revisión por pares para establecer el orden y el rango.

Finalmente, viene la parte de “revisión”, pero es un hecho inevitable.Sus mejores desarrolladores verán un código deficiente y, después de suficientes revisiones, es hora de que el codificador deficiente dé un paso adelante o lo olvide.

Si mantienes las cosas positivas y organizadas, suele ser una gran experiencia.

Casi me olvido de tocar la programación en pareja.Esto es más difícil de configurar.Obviamente no puedes tener a dos de tus programadores más débiles trabajando juntos o bien podrías disponer un millón de monos con un millón de máquinas de escribir.Intenta poner a una persona más fuerte con una más débil y ofrece incentivos a ambos en privado.Alguien que sea más débil debería saber que la mejora podría ser recompensada (si requiere tal incentivo) y el programador más fuerte debería saber que los verdaderos líderes comienzan como buenos mentores.Sin embargo, asegúrese de que el desarrollador más débil esté escribiendo.No al revés o se convierte en una presentación y "bostezo"Es posible que alguien no gane nada con la experiencia.

Answer 4

He realizado un montón de coaching ágil y, para ayudar a las personas a superar el "estigma" de la programación en pareja, lo llamamos "revisión de código y diseño en tiempo real".La gente parece entender mejor el concepto si lo expresas en esos términos.

Answer 5

La única experiencia directamente relacionada que tengo con cualquiera de ellos es la de revisiones de diseño por pares (hace mucho tiempo).Y apestaron.Si lees la literatura, estaba claro que rompían varias reglas de las buenas críticas (saltar sobre las personas, centrarse en la ortografía, no tener resultados claros, etc.).etc.) pero era todo lo que sabíamos.

PERO Desde entonces he estado involucrado en muchas revisiones de código fuera de línea.

Dependiendo del proyecto, se les ha ordenado antes de registrarse en la sucursal "en vivo" o en algún momento aleatorio después.En 3 de cada 4 proyectos han sido adoptados, aunque al principio como un mal necesario, pero luego como un aporte valioso.

El beneficio de cualquier revisión funcional debería ser hacer que todos escriban mejor código y brindar tutoría incluso a los mejores programadores (sea honesto, ¿sus programadores destacados realmente escriben código legible?) Una vez que pueda persuadir al personal menos experimentado para que diga que no lo hacen. entiendes algo, estás lejos.Algunos de los mejores se quejarán, pero los mejores pensarán en lo que han escrito y cambiarán los nombres o el diseño de las variables, y tal vez incluso agregarán un comentario.

El cuarto proyecto utiliza un esquema impuesto de revisión "en un momento aleatorio" y los líderes técnicos aún no lo han incluido (¿equipo roto?)

---

Las dos prácticas que usted describe son enfoques formales.No funcionan bien para todas las personalidades y grupos.

Pruebe algo que crea que su equipo realmente puede hacer y luego vea si se puede mejorar.

Una vez que hayas tenido ese par de ojos extra en tu código, no querrás mirar atrás.

Answer 6

• Sí, nuestra empresa utiliza revisiones de códigos de pares.Las llevamos a cabo como revisiones over-the-shoulder e invitamos al evaluador del equipo a participar en la reunión para comprender mejor los cambios.

• La revisión del código tiene beneficios claros, como lo han demostrado varios estudios.Para nuestra empresa, fue evidente que la calidad del código aumentó a medida que disminuyó la cantidad de llamadas de soporte y también disminuyó la cantidad de errores reportados.NOTA:Algunos de los beneficios aquí fueron el resultado de implementar Scrum y abandonar Waterfall.Más sobre Scrum a continuación.

• Los beneficios de la revisión de código pueden ser un producto más estable, un código más fácil de mantener según se aplica a los estándares de estructura y codificación, y permite a los desarrolladores centrarse más en nuevas funciones en lugar de "extinguir errores" y otros problemas de producción.Realmente no hay ningún inconveniente si las revisiones del código se realizan "correctamente".Más información sobre el “camino correcto” a continuación.

• Algunos de los obstáculos a superar al implementar revisiones de código son la idea de que el “hermano mayor” me está observando y la idea de que no tener un código perfecto significa tortura y dolor.A veces es difícil lograr que los desarrolladores confíen entre sí, especialmente cuando se trata de actitudes de “orden jerárquico” o de “más santo que tú” y poner tu arduo trabajo bajo un microscopio.La confianza es la clave para resolver estos problemas.Un desarrollador debe confiar en que no será castigado por sus pares ni por la gerencia por errores en el código.Le pasa a todo el mundo.Tome nota del problema, resuélvalo y siga adelante.

MeléUno de los beneficios de utilizar la metodología Scrum es que el ciclo de desarrollo (“sprint”) es corto.El marco de tiempo del "sprint" está determinado por lo que funciona mejor para su organización y necesitará algo de prueba y error, pero en realidad no debería durar más de cuatro semanas.El beneficio es que requiere que los desarrolladores se comuniquen diariamente y comuniquen los problemas desde el principio del proyecto.Esto fue adoptado inicialmente por nuestro departamento de desarrollo y se ha extendido a todas las áreas de nuestra empresa ya que los beneficios de scrum son de gran alcance.Para más información, ver: http://en.wikipedia.org/wiki/SCRUM o http://www.scrumalliance.org/ .Como las iteraciones de desarrollo son más pequeñas, el proceso de revisión de código revisa fragmentos de código más pequeños, lo que hace que sea más probable que la revisión encuentre problemas que horas o días de revisiones formales.

"Manera correcta"Las revisiones de código realizadas de la “manera correcta” son completamente subjetivas.Sin embargo, personalmente creo que deberían ser revisiones informales y por encima del hombro.Todos los participantes en una revisión deben evitar atacar personalmente a la persona que se revisa con declaraciones como "¿Por qué lo hiciste de esa manera?" o "¿Qué estabas pensando?" etc.Este tipo de comentarios disminuyen la confianza entre pares, lo que genera animosidad y horas de discusión sobre la mejor manera de codificar una solución.Tenga en cuenta que los desarrolladores no piensan ni codifican exactamente igual y que existen muchas soluciones a un problema.
Sólo una pequeña aclaración sobre las revisiones generales;Estos se pueden realizar compartiendo escritorio remoto (elija el tipo aquí) o en persona.Sin embargo, no deberían limitarse únicamente a los desarrolladores.Por lo general, invitamos a todo nuestro equipo scrum, que consta de dos desarrolladores por equipo, un evaluador, una persona de documentación y un propietario del producto.Todos los que no son desarrolladores están ahí para comprender mejor los cambios o las nuevas funciones que se realizan.Son libres de hacer preguntas o proporcionar comentarios, pero no de tomar decisiones de codificación ni hacer comentarios.Esto ha sido efectivo ya que se harán ciertas preguntas que pueden cambiar la dirección del proyecto, ya que los requisitos iniciales pueden haber omitido un escenario, pero de eso se trata la metodología ágil: del cambio.

SugerenciaRecomiendo encarecidamente investigar las revisiones de código y scrum antes de exigirlas.Crea las reglas básicas para cada uno e impleméntalas como parte de tu cultura para lograr un producto de mejor calidad.Debe convertirse en parte de su cultura para que sea parte de un proceso natural e integrado en todos los niveles, ya que es un cambio de paradigma de mala calidad, incumplimiento de plazos y frustración a productos de mejor calidad, menos frustración y más entregas a tiempo. .

Answer 7

Un análisis comparativo después de haber pasado a las revisiones de relaciones públicas en github desde la programación en pareja.

La atención se centra en enumerar paso a paso lo que nuestros equipos siguen ahora en el proceso de revisión de relaciones públicas.

"Revisiones de código frente a programación en pares" https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926