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 ".