¿Cómo se construye una cultura de revisión de código? Mis observaciones de diez años

estoy de acuerdo con la regla de trozos pequeños pero en la práctica es difícil. a veces el cambio es grande por naturaleza.

nuestra solución fue esta: antes de enviar un cambio grande, escribimos y compartimos el enfoque en una página. una lectura de 5 min evita una hora de debate en la revisión.

enterarte del enfoque equivocado después de escribir 500 líneas es lo peor. a esas alturas nadie quiere volver atrás y la mala decisión sale a producción.

¿Puedo decir algo como novato?

Para mí lo más difícil no es no tomarme los comentarios como algo personal. Cuando llega un comentario que no entiendo, me da miedo volver a preguntar, creo que pareceré tonto. Luego adivino y arreglo mal.

No sé si me pasa solo a mí, pero quizás a otros también.

No te pasa solo a ti, es muy común y arreglarlo es nuestro trabajo, no el tuyo.

A nosotros nos funcionaron dos cosas. Primero, escribir la justificación al comentar. En vez de "cambia esto", decir "da error en este caso, por eso es mejor así". Si hay justificación, la necesidad de preguntar baja.

Segundo, cuando hay más de dos rondas de mensajes, llevar la conversación a un chat. Una reunión de 15 min es más rápida que 15 comentarios y desgasta mucho menos.

Y una cosa más: no hay preguntas tontas. Otras tres personas del equipo se preguntan lo mismo que tú pero no preguntan. Al preguntar, haces un favor a las cuatro.

Dejar la discusión de estilo a las herramientas es la mayor ganancia por sí sola. Se monta en una semana y ahorra tiempo durante años.

Aviso desde gestión de proyectos: poned el tiempo de revisión en el plan.

En nosotros pasó esto: durante mucho tiempo no consideramos la revisión como parte del trabajo, en el plan solo estaba el tiempo de desarrollo. Resultado: cada revisión se veía como "lo que retrasa el trabajo" y se hacía por cumplir.

Desde que lo pusimos en el plan, nadie sabotea las revisiones, porque ya no es algo que retrasa, es parte del plan.

Me pasó lo mismo.

Exactamente así. Si no lo pones por escrito desde el principio luego surgen discusiones.

Lo dejo como nota, por si sirve.

Estoy totalmente de acuerdo. Que todo el mundo haga algo no significa que sea lo correcto.

Si tenéis dudas, escribid, os responderé en la medida de lo posible.

A mí me pasó justo al revés por eso escribo. Lo importante no es la cifra sino en qué se basa esa cifra.

Si escribís el resultado aquí, también servirá de ayuda a otros.

Dejo una advertencia. Antes de decidir, mirad qué datos tenéis en la mano.

Ningún proceso mejora si no se registran datos porque no sabes qué tienes que arreglar. También me gustaría saber si alguien lo hace de otra manera.

Estoy siguiendo esto.

A nosotros también nos pasa.

Guardado.

Voy a resumir el tema porque se han dado varias respuestas diferentes. Empezad con una pequeña prueba, no lo integréis todo de golpe.

Yo seguiría por ese camino.

Perdona, pero esto no es válido en todos los casos. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Corrijanme si me equivoco.

Rara vez se encuentra un texto que lo explique tan claro. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Si el alcance crece, debe crecer el plazo o el presupuesto. No hay tercera opción. También me gustaría saber si alguien lo hace de otra manera.

tema muy oportuno.

Tomo nota, gracias.