qa - programacion - ¿Revisiones pares o programación de pares, o ambas?
pair programming wikipedia (7)
Cuando era joven y necio, uno de mis primeros trabajos fue construir un analizador sintáctico para extraer ciertos campos en un largo archivo PDF que se volcó en un 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 más tarde terminé la tarea, pero en la revisión por pares me sentí abrumado al saber que podría haberlo hecho mejor y que lo que produje fue basura. Aprendí cómo hacer un análisis léxico solo para demostrar que no era un idiota, pero digamos que el proceso de revisión por pares fue desagradable. No necesitaba una persona mayor para bailar sobre mis fallas, necesitaba un mentor y me lo recordé cada vez que hice una revisión por pares.
Me gustan las evaluaciones por pares cuando revisamos los egos en la puerta. (¡Esto incluye el mío!). Hay una cantidad finita de tiempo en este mundo, y solo tanto que puedes aprender y hacer. A través de una buena revisión por pares, puede ampliar su conocimiento y hacer más en menos tiempo. Los problemas surgen cuando las cosas se degradan en la comprobación de la sintaxis anal.
Tengo algunas reglas debido a esto. No reviso por pares nada que podamos automatizar. Ejecuta un corrector ortográfico y un embellecedor de código. Si tiene algo como FXCop disponible, ejecútelo, haga lo que dice, o tenga una buena razón por la cual no lo es. Luego podemos ver cómo se elabora el código, cómo funciona y qué podemos hacer para mejorarlo. De esta forma, obtienes una perspectiva diferente sobre cómo resolver un problema y por qué alguien piensa de esa manera. A veces, la otra vía no es realmente mejor, a veces la nueva solución es fantástica y algo que usarás para el resto de tu vida de programación. Una vez que finalice la revisión, eso es todo, no la estoy usando como ejemplo en su contra. Es tuyo para aprender lo que quieras de él. No manejaré por miedo o amenaza, eres una persona inteligente y voy a dejar que lo demuestres.
- ¿Participas en revisiones por pares de código o practicas programación de pares, o ambas?
- ¿Ha podido demostrar un aumento en la calidad del software utilizando estas prácticas?
- ¿Qué beneficios y desventajas has observado en el transcurso de la práctica?
- ¿Qué obstáculos para la implementación enfrentaste?
En mi caso, nuestro equipo de desarrollo buscó revisiones por pares de varios artefactos de software diferentes (análisis de requisitos, planes de prueba, código, etc.). La programación de pares ni siquiera se consideró como una opción.
La práctica de revisión por pares fue presionada desde la cima, y los desarrolladores nunca la aceptaron. Tuvimos un grupo externo de SQA que reunió las métricas de las actividades, pero los números no tenían ningún valor ya que el esfuerzo fue poco entusiasta. Después de años de que esta sea la forma "oficial" de hacer las cosas, los desarrolladores han llegado a ignorar colectivamente los procedimientos prescritos.
Ahora hay menos visibilidad cuando los errores se interponen en el ciclo de vida. Y no hacer las revisiones por pares ha llevado a una mayor especialización en el equipo ... donde nadie sabe realmente los requisitos / lógica de los componentes fuera de su propia área especializada del sistema.
Sería valioso conocer sus experiencias con revisiones por pares o programación de pares, especialmente historias de éxito.
He hecho un montón de entrenamiento ágil, y para ayudar a la gente a superar el "estigma" de la programación de pares, lo llamamos "código en tiempo real y revisión de diseño". La gente parece entender mejor el concepto, lo pones en esos términos.
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. Tratamos de que sea un hábito en el equipo que las revisiones sean una parte inherente de la escritura de código. Lo escribes y luego le pides una opinión a alguien.
Además, en los proyectos en los que tenemos suficientes personas disponibles (cuando las tareas son del tamaño correcto) tratamos de emparejar la programación.
Debo decir que definitivamente hemos visto una ventaja en esto. En primer lugar, es una excelente forma de orientar a los desarrolladores junior en el equipo: cuando revisas su código, puedes mostrarles qué se puede hacer mejor y, al combinarlos, pueden ver mejores maneras de hacer las cosas, cómo las personas con experiencia pensar e incluso cómo usar el IDE mejor.
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 el código es un mejor equipo, un equipo que sigue aprendiendo y compartiendo.
Algunas cosas para tener en cuenta:
- Asegúrate de que las personas mayores también permitan el programa juniors al emparejarse
- No permita que las personas se apareen en tareas pequeñas, generalmente desperdicia tiempo
- Mira cómo se llevan las parejas (no fuerces a un par)
- Recuerde volver a barajar los pares de vez en cuando
- No dejes que las críticas sean una coincidencia del ego: no dejes que la gente aplaste a los demás
La única experiencia directamente relacionada que tengo con cualquiera de ellos es de revisiones de diseño por pares (hace mucho tiempo). Y ellos apestaron. Si leía la literatura, estaba claro que rompió varias reglas de buenas críticas (saltando sobre las personas, se centró en la ortografía, no hubo resultados claros, etc.) pero era todo lo que sabíamos.
PERO desde entonces he estado involucrado en muchas revisiones de códigos 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 posterior. En 3 de 4 proyectos, han sido acogidos, reconocidamente como un mal necesario inicialmente, pero más tarde como un valioso aporte.
El beneficio de cualquier revisión de trabajo debería ser hacer que todo el mundo escriba un código mejor e incluso la mejor mentora de codificadores (sea honesto, ¿sus programadores realmente escriben código legible?) Una vez que puede persuadir al personal menos experimentado para que diga que no lo hacen entiende algo, estás lejos. Algunos de los mejores videos sonarán pero los mejores realmente pensarán en lo que han escrito y realmente cambiarán el nombre de las variables o el diseño, y tal vez incluso agregarán un comentario.
El 4to proyecto usa un esquema impuesto que revisa ''en un momento aleatorio'' y las pistas técnicas aún no han llegado (¿equipo roto?)
Las dos prácticas que describes son enfoques formales. No funcionan bien para todas las personalidades y grupos.
Pruebe algo que cree que su equipo realmente puede hacer y luego vea si se puede mejorar.
Una vez que haya tenido ese conjunto de ojos extra en su código, no querrá mirar hacia atrás
La revisión por pares debe ser OBLIGATORIA .
Puede leer y encontrar numerosos artículos y libros que discuten diferentes formas de abordar esto en equipos de varios tamaños, pero parece que está indagando sobre experiencias.
Personalmente, creo que la revisión por pares debe ser divertida. Comida provista y mantener el ambiente jovial. Realmente debe tratarse como un momento donde los desarrolladores / programadores pueden aprender unos de otros sin la oportunidad de juzgar (y todos sabemos cómo cada programa parece haber nacido con un gen de juicio innato). He tendido a apreciar o ayudar a organizar las revisiones para que sean 1/3 o 1/4 del tiempo como abiertas. Con eso me refiero a cuando el grupo se reúne y una persona presenta un proyecto que está trabajando o incluso revisado, que ni siquiera está relacionado con el proyecto actual (sé que esto es difícil con los plazos, pero lo intento).
Generalmente, los creativos se reúnen para mostrar las pinturas, los diseños y los artistas en los que se encuentran actualmente a fin de 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. Secundario a eso, las personas simplemente notan cosas que sus compañeros desarrolladores hacen y que NO han notado antes. "Oh wow, ¿así que lograste hacer eso en una sola línea de código? Genial. "Conseguir que los desarrolladores se inspiren y motiven sobre lo que hacen, en lo que están trabajando y cómo lo hacen, les dará más dividendos que usar la revisión por pares para establecer el orden jerárquico y el rango.
Finalmente, llega la parte de "revisión", pero es un hecho inevitable. Sus mejores desarrolladores verán código deficiente y después de suficientes revisiones es hora de que el pobre codificador acelere o se olvide de él.
Si mantiene las cosas positivas y organizadas, generalmente es una gran experiencia.
Casi olvidé tocar la programación de pares. Esto es más difícil de configurar. Obviamente no puedes tener a dos de tus programadores más débiles trabajando juntos o podrías organizar un millón de monos con un millón de máquinas de escribir. Trate de poner a una persona más fuerte con un jugador débil y ofrezca incentivos a ambos en privado. Alguien que es más débil debería saber que la mejora podría ser recompensada (si requieren tal incentivo) y el programador más fuerte debería saber que los verdaderos líderes comienzan como buenos mentores. Sin embargo, asegúrate de que el desarrollador más débil escriba. No viceversa, o se convierte en una presentación y alguien " bosteza " puede que alguien no gane nada con la experiencia.
• Sí, nuestra empresa utiliza revisiones de códigos de pares. Los llevamos a cabo como revisiones Over-the-Shoulder e invitamos al probador del equipo a participar en la reunión para obtener una mejor comprensión de los cambios.
• Existen beneficios definidos para la revisión del código, como varios estudios han podido demostrar. Para nuestra empresa, fue evidente que la calidad del código aumentó a medida que disminuyó el número de llamadas de soporte y también disminuyó el número 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 del código pueden ser un producto más estable, un código más fácil de mantener ya que se aplica a estándares de estructura y codificación, y permite a los desarrolladores enfocarse más en las nuevas características que en los errores de extinción de incendios y otros problemas de producción. Realmente no hay inconvenientes si las revisiones de código se llevan a cabo "a la derecha". Más sobre el "camino correcto" a continuación.
• Algunos de los obstáculos que debo superar al implementar revisiones de códigos son la idea de que el "hermano mayor" me está mirando y la idea de que no tener un código perfecto significa tortura y dolor. Conseguir que los desarrolladores confíen entre ellos es difícil a veces, especialmente cuando se trata de actitudes de "picoteo" o "más santo que tú" y de poner su trabajo duro bajo el microscopio. La confianza es la clave para resolver estos problemas. Un desarrollador debe confiar en que no serán castigados por sus compañeros o la administración por errores en el código. Le pasa a todo el mundo. Tome nota del problema, resuelva y continúe.
Scrum Uno de los beneficios de usar la metodología de Scrum es que un 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á un poco de prueba y error, pero en realidad no debería ser 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 compañía ya que los beneficios del scrum son de gran alcance. Para obtener más información, consulte: 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 del código revisa trozos de código más pequeños, haciendo que la revisión tenga más probabilidades de encontrar problemas que horas o días de revisiones formales.
Las revisiones del código "correcto" hechas de la "manera correcta" son completamente subjetivas. Sin embargo, personalmente creo que deberían ser informales, revisiones sobre el hombro. Todos los participantes en una revisión deben evitar atacar personalmente a la persona que se revisa con afirmaciones tales como "¿por qué lo hiciste de esa manera?" O "¿qué estabas pensando?", Etc. Estos tipos de comentarios disminuyen la confianza entre pares, a la animosidad, horas de discutir sobre la mejor / correcta forma de codificar una solución. Tenga en cuenta que los desarrolladores no piensan ni codifican exactamente lo mismo, y hay muchas soluciones para un problema.
Solo un poco de aclaración sobre las revisiones sobre el hombro; esto se puede realizar mediante el uso compartido remoto del escritorio (elija el sabor aquí), o en persona. Sin embargo, no deben limitarse solo a los desarrolladores. Normalmente invitamos a todo nuestro equipo scrum, que consta de dos desarrolladores por equipo, un probador, una persona de documentación y un propietario de producto. Todos los no desarrolladores están allí para obtener una mejor comprensión de los cambios o la nueva funcionalidad que se está realizando. Son libres de hacer preguntas o proporcionar comentarios, pero no para tomar decisiones de codificación o comentarios. Esto ha sido efectivo ya que se realizarán ciertas preguntas que pueden cambiar la dirección del proyecto ya que los requisitos iniciales pueden haber pasado por alto un escenario, pero de eso se trata el cambio ágil.
Sugerencia Recomiendo encarecidamente investigar las revisiones de scrum y código, antes de ordenarlas. Cree las reglas básicas para cada una e impleméntelas como parte de su 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 calidad deficiente, incumplimiento de plazos y frustración a productos de mejor calidad, menos frustración y más entregas a tiempo. .
Un análisis comparativo después de haber pasado a las revisiones de PR en github de la programación de pares.
El foco está 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 vs Programación de pares" https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926