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

¿Es importante señalar las partes buenas del código durante una revisión del código y las razones por las que es bueno? Los comentarios positivos pueden ser igualmente útiles para el desarrollador que se está revisando y para los demás que participan en la revisión.

Estamos realizando revisiones utilizando una herramienta en línea, por lo que los desarrolladores pueden abrir revisiones para su código comprometido y otros pueden revisar su código dentro de un período de tiempo determinado (por ejemplo, 1 semana). Otros pueden comentar sobre el código o los comentarios de otros revisores.

¿Debería haber un equilibrio entre los comentarios positivos y negativos?

Mejore la calidad y la moral utilizando revisiones de código de pares
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Cosas que todos deberían hacer: Revisión de código
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

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

Entonces 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 un monólogo en ejecución, así que a medida que entiendo lo que estoy leyendo habrá un montón de "Ok, veo lo que hace ... Bueno, se conecta a esto y llama eso, está bien ... y esa pieza depende de ambos bien ".

Creo que de esta manera no es "¡oo la la es tan genial!", Podría ser un código aburrido perfectamente trivial, pero escuchar a alguien realmente analizar y mostrar la comprensión de lo que escribiste es una forma de retroalimentación positiva en sí misma, la respuesta es "Este código tiene sentido", cuando me encuentro con partes que no entiendo, pido una explicación y cuando lo entiendo exclamo "Ah, lo tengo".

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

Dicho esto, si ve partes del código que son características buenas o positivas (incluso el código trivial aburrido puede ser bueno si es la forma mínima de sí mismo) Definitivamente tiendo a decir esas características, nuevamente no las atribuyo como "Wow ¡Excelente!" tanto como "Veo que esta es una implementación mínima" o "Ok, este algoritmo complejo tiene muchos comentarios", concéntrese en los atributos del código, no tanto en su bondad o maldad inherentes.

Cada vez que atribuya "bondad" o "maldad" al código en una revisión de código para evitar que el ingeniero se sienta despreciado o sostenido en un pedestal, no diga que algo es bueno o malo, sino que hable sobre la causa y el efecto de su código

"Ok, esta parte tiene sentido, ah hay un número mágico aquí, el significado de ese valor podría no ser bien entendido por el próximo ingeniero que toque esto"

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

"Ah, hay un diccionario estático aquí, si varios hilos tocan ese diccionario podríamos encontrarnos con algunas condiciones de carrera"

Tenga en cuenta que no estoy diciendo que algo sea bueno o malo, sino que el ingeniero cuyo código se está revisando entenderá si el ingeniero debe cambiarlo o no. Obviamente, debe finalizar la revisión del código con un sí o un no, pero la acumulación de estas afirmaciones en el transcurso de las mismas suavizará las 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 registrar esto en ".

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

En general, creo que si alguien escribe un código de pieza que realmente te hace decir "¡Guau, 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 nuevamente. Sin embargo, tiene que ser más que solo seguir pautas y prácticas estándar. Elogiar porque alguien sangraba bien o agregaba comentarios repetitivos podría poner el listón bastante bajo.

Esta no es tanto una pregunta de programación como una pregunta de gestión general e interacciones humanas. La retroalimentación positiva en las revisiones de código es exactamente tan importante como la retroalimentación positiva en cualquier tipo de revisión.

Si esto se requiere o no (y en qué medida 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 de manera mucho más efectiva cuando se combina con elogios. Otros ven los elogios como poco sinceros cuando se entregan con corrección.

La fórmula general a veces se denomina "Sandwich de retroalimentación": cosas buenas primero, cosas malas en segundo lugar, cosas buenas en último lugar. La idea es mantener el tono general positivo y al mismo tiempo asegurarse de que se reciba la retroalimentación negativa. Esto puede ayudar a prevenir el estrés al anticipar una revisión, y ayudar a prevenir la crianza autoabsorbida después. Ambos son muy importantes con respecto a la productividad y la calidad. Esto no es solo una tontería emocional delicada; Es el comportamiento humano 101.

Nuevamente, debe conocer a la persona con la que está trabajando y comprender a qué responde. De lo que se trata es de tratar con las personas, y los buenos gerentes saben cómo hacer que las personas respondan.

Creo que la retroalimentación positiva es muy importante y es principalmente de una dinámica personal, realpolitik. Todos nos sentamos y escribimos código durante horas, días, semanas, meses, y la mayoría de nosotros nos enorgullece 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 "Averigüe qué tan mal piensan las personas que apesta". En consecuencia, los desarrolladores comenzarán a molestarse o incluso a temer las revisiones de código, y eso es claramente un perjuicio para el equipo. Los desarrolladores se "olvidarán" de revisar su código o desarrollarán la impotencia aprendida y simplemente preguntarán a sus críticos constantes qué hacer con cada pequeña cosa para evitar ser criticados en estas reuniones.

Está muy bien decir que, en teoría, es más lógico arreglar lo malo y pedirle a todos que dejen las emociones en la puerta, pero son precisamente las actitudes como las que son responsables de que los desarrolladores de representantes sean sordos interpersonalmente. Dejando a un lado las teorías, somos humanos y a los humanos nos gusta recibir una palmada en la espalda de vez en cuando, incluso una nominal. Eso importa.

Es más importante si está haciendo revisiones paralelas o de equipo. En una revisión escrita, ninguna noticia es una buena noticia. El objetivo es llevar el código a producción. Cuando es su código, debe sentirse bien consigo mismo.

La revisión del código debe usarse como fuente de información para ayudar con la tutoría y la gestión del equipo. Hay muchas oportunidades para dar retroalimentación positiva sin saturar la base de datos de revisión de código. Se pueden extraer ejemplos para compartir con otros.

Hay mucho más para revisar el desarrollador que no sea su código. El tiempo de revisión del código de secuestro puede ser contraproducente para sacar 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 los comentarios de revisión de código.

La única forma en que puedo pensar en dónde proporcionar retroalimentación positiva sobre el código podría ser contraproducente para usted es si no tiene cuidado de evitar el "cumplido de revés". La mayoría de la gente está familiarizada con esto ... se expresa con frases como "Buen trabajo, pero ..."

Si todos llegan a la reunión con la actitud de que esta 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, entonces todos los comentarios son comentarios "buenos". La retroalimentación que resalta las formas de mejorar la práctica de codificación se vuelve tan importante como la retroalimentación que resalta un nuevo método útil para manejar un problema.

Por lo menos, si uno no llega a ese punto, debe enfatizarse que esforzarse por hacer un ciclo de "buenos comentarios, malos comentarios, buenos comentarios, malos comentarios" dentro del proceso de revisión solo se encontrará con el mismo sentimiento de cumplido de revés. No intente forzar una buena retroalimentación, intente reforzar un buen esfuerzo y acumule agujeros en el conocimiento.

Frases de las que más he aprendido 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 tenemos 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 un parche en la lista de correo / herramienta en línea.
2. Todos los que necesitan cuidado miran el parche, sugieren mejoras.
3. Dev vuelve al n. ° 1
4. Si no se necesita mejorar, la gente dice "Buen trabajo, por favor comprométase". <- COMENTARIOS POSITIVOS. Todo el código que se acepta es bueno. Mientras menos personas tengan que decirte que cambies las cosas, mejor te irá.
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 la base de código.

Los beneficios de este enfoque son:

1. Todos saben lo que todos están haciendo. No hay conocimiento que monopolice ni cometa misterio.
2. Todos aprenden de los comentarios de los demás. Esto es importante. Si la retroalimentación solo ocurre entre 2 personas en una conversación cara a cara durante el emparejamiento, entonces alguien del otro lado de la sala no se beneficia de la misma manera que lo haría si sucediera en la lista de correo.
3. Otros desarrolladores generalmente pueden detectar algunos errores antes de que estén en el control de versiones.

No puedo estar 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 un código increíble pero inexplicable 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 son rechazados a favor de la facilidad de mantenimiento y la facilidad de comprensión. Es demasiado arriesgado.

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

También tendrías problemas con las personas que no reciben comentarios positivos, tal vez tratando demasiado y haciendo un desastre eventual "¡Confía en mí, funciona!".

Las revisiones de código están ahí para difundir 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, úselo 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. A los clientes no les importa la frescura de su código, solo que hace lo que quieren.

Deja la espalda al pub.

Me ha importado. No quiero comentarios espontáneos o positividad por el bien de la positividad. Si todo el código que escribí es malo, dígame por qué y corrijamos y aprendamos. Pero si hago algo bien, es bueno escucharlo de vez en cuando. No necesito refuerzo positivo para todo lo que hice que fue "correcto", pero incluso si es un "vamos a mejorar X, Y y Z, pero el resto se ve bien", es importante.

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 si es un buen tipo, o si generalmente escribe un buen código. Requieren software que funcione.

Creo que es importante ser completamente objetivo. Intentar elevar 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 con nosotros mismos. Me parece que la suposición de que el código que he escrito es probablemente una basura completa y definitivamente podría mejorarse me impulsa a mejorar mi código y mi nivel de habilidad.

Si no recibe 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 se deben practicar los métodos de revisión adecuados. Dicho esto, los comentarios positivos ayudan a un desarrollador / programador a pensar y proponer ideas / soluciones / soluciones. No seas demasiado duro, pero sé firme en el punto. Los gerentes de preguntas y respuestas deben conocer buenas metodologías y prácticas para poder guiar al equipo (o miembro) en la dirección correcta. Esto da como resultado calidad. Período.

Cuando el código es para una competencia o se presenta para una entrevista de trabajo (en otras palabras, el código que está escrito y no se puede reescribir), entonces los comentarios positivos son obligatorios. De hecho, debe asegurarse de que haya comentarios positivos (cuando sea posible) y negativos. De esa manera, el codificador sabe dónde residen sus fortalezas y debilidades, y puede compensarlo.

Sin embargo, parece estar hablando en un entorno laboral, donde el código puede reescribirse. En cuyo caso, estás tratando de eliminar los errores de tu sistema. Entonces, en esa situación, solo los errores negativos tienen valor.

Si se siente incómodo con eso, tenga una reunión de revisión de código semanal, donde todos puedan discutir tanto el código bueno como el código malo.

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