¿Qué tan importante es la retroalimentación positiva en las revisiones de código?

Mejore la calidad y la moral utilizando las revisiones de código de pares
enlace

Cosas que todos deberían hacer: Revisión de código
enlace

Ambos artículos establecen que uno de los propósitos de la revisión del código es compartir el conocimiento sobre las buenas técnicas de desarrollo, no solo encontrar errores.

Así que diría que es muy importante. ¿Quién quiere ir a una reunión y solo ser criticado?

Cuando hago revisiones de código, tiendo a tener solo un monólogo en ejecución, así que estoy entendiendo lo que estoy leyendo y habrá un montón de "Ok, veo lo que eso hace ... Bueno, se conecta a esto y lo llama, está bien ... y esa pieza depende de los dos bien ".

Creo que de esta manera no es "¡oo la la esto es tan bueno!", podría ser un código aburrido perfectamente trivial, pero escuchar a otra persona realmente analizar y mostrar comprensión de lo que escribiste es una forma de retroalimentación positiva en y por sí misma, la respuesta es "Este código tiene sentido", cuando me topo con partes que no entiendo, pido una explicación y cuando las entiendo exclama "Ah, lo tengo".

Creo que la simple transferencia de comprensión es un elogio para otro ingeniero porque todos queremos que otros comprendan nuestro código, y da una forma de validación implícita.

Dicho esto, si ves partes del código que son buenas o características positivas (incluso un código trivial aburrido puede ser bueno si es la forma mínima de sí mismo) Definitivamente tiendo a establecer esas características, de nuevo no las atribuyo. como "¡Wow genial!" por mucho que "veo que esto es una implementación mínima" o "Ok, este complejo algoritmo tiene muchos comentarios", se centran en los atributos del código, no tanto en su bondad o maldad inherentes.

Cada vez que atribuye "bondad" o "maldad" al código en una revisión de código para evitar que el ingeniero se sienta menospreciado o sostenido en un pedestal, no diga que algo es bueno o malo, sino que hable a través de la causa y efecto de su código.

"Ok, esta parte tiene sentido, ah, aquí hay un número mágico, el siguiente ingeniero podría no entender bien el significado de ese valor"

"Veo que tienes un contenedor DI aquí, está bien, así que tendrás un acoplamiento suelto con ese repositorio"

"Ah, aquí hay un diccionario estático, si varios subprocesos están tocando ese diccionario, podríamos encontrarnos en algunas condiciones de carrera"

Note, no estoy diciendo que nada sea bueno o malo, pero si el ingeniero debe cambiarlo o no lo entenderá el ingeniero cuyo código se está revisando. Obviamente, tiene que terminar la revisión del código con un sí o un no, pero acumular estas afirmaciones a lo largo del curso suavizará el no, ya que la explicación ya se ha hecho en forma de declaraciones de causa y efecto cuando les dice "Me gustaría esos números mágicos arreglados antes de verificar esto en ".

Si vi algo en una revisión de código que realmente me gustó y estaba por encima y más allá del código "lo suficientemente bueno", daría una respuesta positiva.

En general, creo que si alguien escribe un código de pieza que realmente te hace decir "Wow, ¡esto es realmente bueno!" entonces sí, la retroalimentación positiva es importante: le hace saber al autor que lo que hicieron fue disfrutado por otros, y deberían intentar hacerlo de nuevo. Sin embargo, tiene que ser más que seguir las pautas y las prácticas estándar. Otorgar elogios porque alguien tuvo una sangría agradable o agregar comentarios repetitivos podría establecer el listón bastante bajo.

Esto no es tanto una cuestión de programación como una cuestión de gestión e interacciones humanas. Los comentarios positivos en las revisiones de códigos son exactamente tan importantes como los comentarios positivos en cualquier tipo de revisión.

La necesidad o no de esto (y la medida en que se requiere) es una función de la disposición y la composición emocional de la persona con la que está hablando. Algunas personas responden a la corrección mucho más eficazmente cuando se combina con elogios. Otros consideran que los elogios no son sinceros cuando se entregan con corrección.

La fórmula general a veces se llama "Sandwich de comentarios": lo bueno es lo primero, lo malo lo segundo, lo bueno lo último. La idea es mantener el tono general positivo y, al mismo tiempo, asegurarse de que se recibe la retroalimentación negativa. Esto puede ayudar a prevenir el estrés cuando se anticipa una revisión, y ayudar a prevenir la angustia auto absorbida después. Ambos son muy importantes con respecto a la productividad y la calidad. Esto no es sólo una tontería emocional muy delicada; Es el comportamiento humano 101.

Una vez más, debe conocer a la persona con la que está trabajando y comprender a qué responde. Tratar con las personas es de lo que se trata la administración, y los buenos gerentes saben cómo hacer que las personas respondan.

Creo que los comentarios positivos son muy importantes y provienen principalmente de una dinámica personal, realpolitik. Todos nos sentamos y escribimos código por horas, días, semanas, meses, y la mayoría de nosotros nos enorgullecemos de lo que hacemos. Las revisiones de código son una oportunidad para mostrar eso.

Si va a una revisión de código y el mejor resultado que puede esperar es "sin comentarios" (es decir, no hay un balance de comentarios positivos), la reunión podría titularse fácilmente en perspectiva "Descubra qué tan mal lo piensa la gente Chupar". En consecuencia, los desarrolladores empezarán a sentirse molestos por las revisiones de códigos, o incluso temerán, y eso es claramente un detrimento para el equipo. Los desarrolladores "olvidarán" que revisen su código o desarrollarán una indefensión aprendida y simplemente les preguntarán a sus críticos constantes qué hacer con todo lo posible para evitar ser atacados en estas reuniones.

Es bueno decir que, en teoría, lo más lógico es arreglar lo malo y pedir a todos que dejen las emociones en la puerta, pero son precisamente actitudes como esa las que son responsables de que los desarrolladores de representantes se identifiquen como interpersonales. tono sordo. Dejando de lado las teorías, somos seres humanos y a los humanos les gusta recibir una palmada en la espalda de vez en cuando, incluso una nominal. Eso importa.

Es más importante si estás haciendo revisiones de equipo o de lado a lado. En una revisión escrita, ninguna noticia es una buena noticia. El objetivo es poner el código en producción. Cuando sea tu código, deberías sentirte bien contigo mismo.

La revisión de código se debe utilizar como una fuente de información para ayudar con la tutoría y la gestión del equipo. Hay muchas oportunidades para dar comentarios positivos sin saturar la base de datos de revisión de código. Se pueden sacar ejemplos para compartir con otros.

Hay mucho más para revisar al desarrollador que no sea su código. El tiempo de revisión del código de secuestro puede ser contraproducente para obtener una aplicación por la puerta. Establezca un tiempo específico para ayudar al desarrollador fuera de las revisiones de código, pero eso no significa que deba excluir las opiniones de revisión de código.

La única forma en que puedo pensar en dónde proporcionar comentarios positivos sobre el código podría ser contraproducente si no tienes cuidado de evitar el "cumplido de revés". La mayoría de la gente está familiarizada con esto ... se expresa con frases como "Gran trabajo, pero ..."

Si todos vienen a la reunión con la actitud de que esto no es una revisión personal del programador, sino un esfuerzo por mejorar la práctica de codificación para la calidad de todo el sistema, todos los comentarios son "buenos" comentarios. La retroalimentación que resalta las formas de mejorar la práctica de codificación se vuelve tan importante como la retroalimentación, destacando un nuevo método útil para manejar un problema.

Por lo menos, si uno no va a esa longitud, se debe enfatizar que el esfuerzo por hacer un ciclo de "buena retroalimentación, mala retroalimentación, buena retroalimentación, mala retroalimentación" dentro del proceso de revisión solo llegará. a través con la misma sensación de revés de revés. No intente forzar una buena retroalimentación, intente reforzar un buen esfuerzo y apóyese en los conocimientos.

Frases de las que he aprendido más a lo largo de los años:

• "Ese es un enfoque interesante. ¿Qué sucede si tenemos que acomodar [algún otro caso de uso]?"
• "¡Buen intento! ¿Sabías que ya contamos con un método para hacerlo? Tal vez deberíamos hacer una evaluación comparativa para ver qué enfoque es más eficiente".

El flujo de trabajo que más me gustó con las revisiones de código fue este:

1. Dev envía el parche en la lista de correo / herramienta en línea.
2. Todas las personas que necesitan atención miran el parche, sugieren mejoras.
3. Dev vuelve al # 1
4. Si no es necesario mejorar, la gente dice "Buen trabajo, por favor, comprométase". < - COMENTARIOS POSITIVOS. Todo el código que se acepta es bueno. Cuanto menos gente tenga que decirte que cambies las cosas, mejor lo estás haciendo.
5. Dev se compromete, pasa al siguiente elemento.

Por lo general, lo que sucedería es que los nuevos desarrolladores obtendrían muchos más comentarios "correccionales" a medida que se familiarizaran con el código base.

Los beneficios de este enfoque son:

1. Todos saben lo que están haciendo. No hay conocimiento monopolizador o misterio confiado.
2. Todos aprenden de los comentarios de otros. Esto es importante. Si los comentarios solo se producen entre 2 personas en una conversación cara a cara durante la vinculación, entonces alguien del otro lado de la sala no se beneficiará de la misma manera que lo haría si ocurriera en la lista de correo.
3. Otros desarrolladores generalmente pueden detectar algunos errores antes de que estén en el control de versión.

No estoy de acuerdo con esto en absoluto. ¿Cuál es la diferencia entre las Buenas Técnicas de Desarrollo y los llamados Codificadores Ninja que pueden escribir códigos asombrosos pero inexplicables a simples mortales? El desarrollo de software es ahora (IMO) una disciplina de denominador común más bajo donde el talento y la astucia se rechazan en favor de la facilidad de mantenimiento y la facilidad de comprensión. Es demasiado arriesgado.

No puedo pensar en un momento en el que haya visto un código en una revisión que me haga decir 'Oh, eso es genial'. Solo puedo suponer que si encuentro un código como este, caería en el campo Cool-Yet-Inacceptable.

También tendrías problemas con personas que no reciben comentarios positivos, tal vez se esfuerzan demasiado y hacen un desastre final. "¡Confía en mí, funciona!".

Las revisiones de código están ahí para distribuir la responsabilidad de la calidad del código entre el equipo, es decir, no se puede culpar a un desarrollador individual si surge un problema grave más adelante. Úselo para encontrar problemas, utilícelo para obtener explicaciones del desarrollador original de cosas extrañas en caso de que alguna vez tenga que mantenerlo. Personalmente, estoy más interesado en recibir comentarios negativos. Los clientes no se preocupan por la frialdad de su código, solo que hace lo que quieren.

Deja la contraposición al pub.

Me ha importado. No quiero comentarios de pelusa o positividad por el bien de la positividad. Si todo el código que escribí es horrible, dime por qué, corregámoslo y aprendemos. Pero si hago algo bien, es bueno escucharlo de vez en cuando. No necesito un refuerzo positivo porque todo lo que hice fue "correcto", pero incluso si es un "mejoremos X, Y y Z, pero el resto se ve bien" importa.

No es tan importante como la retroalimentación honesta. Trabajo para una gran corporación financiera, y a nuestros clientes no les importa si el programador se está esforzando o es un buen tipo, ¡o generalmente escribe un buen código! Requieren un software que funcione.

Creo que es importante ser completamente objetivo. Intentar aumentar la moral haciendo comentarios positivos es una pérdida de tiempo para mi mente.

Esto puede significar que las revisiones de código son excesivamente críticas, pero ese no es el punto. También debemos ser críticos de nosotros mismos. Me parece que la suposición de que el código que he escrito es probablemente una basura completa y que definitivamente podría mejorarse me impulsa a mejorar mi código y mi nivel de habilidad.

Si no obtiene comentarios, puede considerar que ha hecho un buen trabajo.

El mantra es simple: si uno quiere un Código de calidad (que es menos real), entonces deben practicarse métodos de revisión adecuados. Dicho esto, los comentarios positivos ayudan a un desarrollador / programador a pensar e idear ideas / soluciones / soluciones. No seas demasiado duro, pero sé firme en el punto. P & A Los gerentes deben conocer las buenas metodologías y prácticas para que puedan guiar al equipo (oa un miembro) en la dirección correcta. Esto se traduce en calidad. Período.

Cuando el código es para una competencia o se envía para una entrevista de trabajo (en otras palabras, el código está escrito y no puede ser reescrito), entonces los comentarios positivos son una necesidad. De hecho, debe asegurarse de que haya comentarios positivos (¡donde sea posible!) Así como negativos. De esa manera, el programador sabe dónde se encuentran sus fortalezas y debilidades, y puede compensarlas.

Sin embargo, parece que estás hablando en un entorno de trabajo, donde el código se puede reescribir. En cuyo caso, estás tratando de sacar a los insectos de tu sistema. Entonces, en esa situación, solo los errores negativos tienen algún valor.

Si se siente incómodo al respecto, organice una reunión semanal de revisión de códigos, en la que todos puedan hablar sobre el código correcto y el código incorrecto.

EDITAR: Aunque diré que, si algo te impresiona lo suficiente, no hay nada que te impida expresar tus elogios en persona. El rastreador, sin embargo, parece ser solo para la revisión del código de producción.