¿Cuál es la mejor manera para que un programador maneje la revisión de código?

Soy bastante nuevo en la revisión de códigos, pero he estado codificando durante años durante mi doctorado, ¡lo que no siempre te convierte en un buen programador!

Si el revisor cambia su código y lo revisa línea por línea, ¿qué debe hacer si no está de acuerdo? A veces elegiste X y el revisor lo cambia a Y, y tenías Y en mente pero decidiste no hacerlo debido a las desventajas, pero el revisor afirma que esas desventajas no son importantes. ¿Deberías verbalizar tu desacuerdo, o simplemente no y escucharlos?

Es difícil si no eres bueno aceptando críticas y si el revisor es una persona más importante en la organización. No sería bueno parecer demasiado defensivo.

Es cierto, parecer defensivo no es útil; pero entonces, ninguno de los dos está siendo criticado, por lo que si cree que esto está sucediendo, realmente debería expresar sus preocupaciones de que la revisión del código no lo está ayudando a escribir un mejor código dentro de la organización.

El revisor tiene la responsabilidad de revisar el código por incumplimiento real y defectos, no usarlo como un medio para escribir su código de la manera en que lo habría hecho. Esto significa que la revisión está ahí para revisar cómo hizo algo y señalar las áreas en las que cometió un error (algo que lo mejor de nosotros hacemos) o que no entendió el marco o los estándares o las "razones históricas". Así es como estás.

Entonces, si hay varias formas de hacer algo, debe haber una buena razón por la cual su código se cambia a una forma alternativa, de lo contrario, es simplemente una rotación no constructiva que no lo ayudará.

Además, recuerde que el revisor tampoco es perfecto. Pueden tener una idea de que Y es la forma de hacerlo, y no se han dado cuenta de que X es mejor. Debería explicar las razones por las que lo hizo de la manera X. El revisor podría estar de acuerdo con usted, o podría decirle por qué Y es una mejor solución; puede haber otros factores que usted no sabe que hace.

En resumen, las revisiones son una forma de hacer que los miembros del equipo se comuniquen sobre sus cambios en el código. Así que habla con el crítico al respecto.

SI ayuda, hable de manera imparcial, como si ni siquiera fuera el autor del código que se está revisando. El código pertenece a la empresa o al equipo después de todo, y el equipo deberá mantenerlo. Simplemente resultó ser el tipo que lo escribió, ese no es un factor tan importante como muchos creen.

Escribir código de computadora es un excelente ejemplo de tomar decisiones bajo incertidumbre . Siempre hay presiones conflictivas, y la forma en que decides en una pregunta determinada depende de las presiones que percibas y de cuán grandes las consideres.

Por lo tanto, cuando un revisor no está de acuerdo con su decisión, eso significa que ve diferentes presiones / riesgos que usted, o considera que algunos de ellos son más grandes / pequeños que usted. Debe hablar absolutamente sobre estas diferencias, porque no hacerlo perpetúa los problemas que llevaron al desacuerdo en primer lugar.

Si su revisor es más experimentado, su experiencia puede decirles correctamente que este o ese riesgo no es muy relevante en la práctica, o pueden saber que algún tipo de error tiene una larga historia de ocurrencia en su organización, y vale la pena tener mucho cuidado para evitarlo Por el contrario, si siente que sabe algo que probablemente su crítico no sabe, debe expresarlo absolutamente; guardar silencio equivale a un incumplimiento del deber de su parte.

La parte más importante del manejo de la situación es comprender que la crítica de las decisiones de diseño no siempre es una crítica a la personalidad de alguien. (En los raros casos en que realmente es, lo notará muy pronto, y si realmente no puede complacer a alguien, nada de lo que haga hace la diferencia, entonces, ¿dónde está el daño en seguir las mejores prácticas? Mucho mejor para encontrar una mejor posición como lo antes posible.) Es solo el resultado de que diferentes personas tienen diferentes percepciones de los muchos riesgos y recompensas involucradas en el código de computadora, y dado lo complejo que es el código de computadora moderno, eso es de esperar. Hablar sobre las diferencias ayuda a mejorar el código y mejorar su cooperación en este caso y en casos futuros.

Las otras respuestas ya contienen muy buena información. Me gustaría ampliar un poco sobre algunos aspectos que han sido insinuados por gbjbaanb (vea mi comentario a su respuesta).

En mi experiencia, he observado diferentes tipos de comentarios durante las revisiones de código:

1. "Sinceramente, creo que esto es incorrecto / subóptimo y que debería cambiarlo de esta manera". Normalmente tomo en serio este tipo de comentarios, y solo me opondré al cambio sugerido si creo que tengo un punto fuerte en contra.
2. "Creo que su solución está bien, considere esta alternativa, pero depende de usted si acepta el cambio o no". También me tomo en serio este tipo de comentarios: el revisor sugiere una alternativa, a pesar de que no tienen una opinión sólida de que su solución sea mejor. Tengo la oportunidad de aprender algo y aceptaré el cambio si me gusta más. De lo contrario, el revisor encuentra que está bien si mantengo el código de acuerdo a mi gusto.
3. "Lo hubiera hecho de manera diferente, así que tienes que cambiarlo, punto" o incluso "¡Oh, he cambiado tu código porque ...", el cambio no se ha sugerido, ya se ha confirmado! Se proporciona una explicación rápida sobre el cambio, con la sugerencia de que no hay mucho tiempo para discutir los detalles porque tenemos que pasar a la siguiente tarea.
4. El revisor sugiere pequeños cambios de naturaleza trivial que no mejoran el código sino que lo hacen diferente. Cuando se le pide que discuta los cambios sugeridos, el revisor entabla largas discusiones sobre detalles triviales hasta que se rinde por agotamiento.

Las opciones 3, 4 pueden aparecer disfrazadas de 1 y 2: "Fue realmente importante hacerlo de la manera que he sugerido". o "Puedes rechazar el cambio si realmente quieres", dijo con un tono que de hecho significa exactamente lo contrario de lo que se dice. En caso de que se oponga a los cambios que considera innecesarios, la propiedad del código compartido puede usarse como justificación de esta actitud: "¡El código no le pertenece a usted, pertenece al equipo!" Puede saber cuándo la intención del revisor no es honesta si el revisor no está muy abierto a la discusión, se irrita y trata de impulsar su solución a toda costa. Básicamente ya lo han decidido, y cualquier otra discusión es solo una pérdida de tiempo.

Las opciones 1 y 2 de IMO son un signo de un crítico honesto que está tratando de ayudar, está tratando de enseñarle algo mientras respeta su trabajo y también está abierto a aprender algo por sí mismo. En este escenario, trato de no sentirme demasiado orgulloso cuando recibo comentarios constructivos de un revisor.

Las opciones 3 y 4 sugieren que hay algún juego de poder en curso: lo importante es si lo hacemos a mi manera o a tu manera, no es que intentemos encontrar una buena solución que satisfaga a ambos. Esto puede estar relacionado con el ego del revisor, pero también con su incapacidad para comprender cualquier código que no siga su forma de pensar. Normalmente están perturbados por el código que no les resulta familiar y les gustaría imponer su camino en toda la base del código.

Si las situaciones 3 y 4 ocurren con demasiada frecuencia, el trabajo en equipo puede ser bastante desagradable. En tal situación, consideraría dejar el equipo.

Para abordar su problema de qué hacer cuando no está de acuerdo ...

Hablar de esto es el camino a seguir, como la mayoría de la gente ya ha señalado.

Si ya lo ha hecho, tal vez más de una vez, incluso, una técnica útil que utilizamos es si todavía hay desacuerdo en alguna área (s) es decir 'sí, sería bueno refactorizar eso:

¿Podemos poner un boleto separado para eso?

Un boleto por separado le permite ingresar el código, en lugar del temido modo 'abandonar y nunca moverse' que he conocido bien en algunos lugares. Esto encaja bien con ágil, haciendo la menor cantidad 'posible' y distribuyendo la carga. A veces, yagni terminará aplicando. Algunas veces, el gerente de producto decidirá que hay necesidades más urgentes que ese refactor en términos de valor para el cliente, plazos y recursos.

La revisión de código es probablemente algo bueno en general, pero desde mi experiencia, es mejor que sirva como herramienta para los desarrolladores de nuevos equipos que usan nuevas pautas de codificación o para corregir errores importantes, de modo que se reduce el riesgo de cometer errores. Si crees que sabes mejor que el revisor, debes preguntarte por qué la solución que él propone es mejor y discutir con tus puntos de vista sobre el asunto. Nadie lo sabe todo mejor, por lo que la revisión de código debería o podría ser una experiencia de aprendizaje valiosa para ambos.

La revisión del código es una oportunidad para detectar posibles problemas y transmitir conocimientos, tanto para el revisor como para el codificador.

Como revisor de código, la responsabilidad es resaltar posibles áreas de riesgo, incumplimiento de la práctica estándar, mejoras y, en general, solo otro punto de vista sobre la misma área de código.

Esto no debería dar lugar a un cambio en el código sin discutir / comprender las decisiones del codificador en el momento del desarrollo.

Si el revisor está haciendo cambios, puede tener dificultades para delegar el trabajo a otros, lo cual es difícil para muchas personas inteligentes.

Como codificador que recibe una revisión, está protegido de un posible problema cuando se implementa, se le da la oportunidad de aprender algo nuevo y la oportunidad de compartir sus conocimientos con el revisor.

Independientemente de la antigüedad, su forma de pensar puede llegar a una solución que a algunos no se les ocurre, por lo que la revisión puede ser su oportunidad de brillar simplemente haciendo lo que cree que es correcto.

Siempre que tanto el codificador como el revisor acepten que pueden estar equivocados y que está bien estar equivocado, una revisión se convierte en algo que fortalece al equipo porque trabajan juntos en la solución.

Parece que todavía no has revisado tu código :-)

El objetivo de la revisión del código es obtener código de calidad decente y saber que tiene un código de calidad decente. Cuando se revisa el código de un desarrollador inexperto, puede usarse para enseñar cómo escribir un código mejor, evitando frustrar a ese desarrollador.

El revisor nunca debe cambiar su código. Pueden hacer sugerencias más o menos sólidas sobre cómo les gustaría que se cambie su código, y pueden decidir si aceptan su código o no.

Si la revisión va a la derecha / si se revisan su código, lo que es probable que se obtiene es algunos comentarios de cómo me iba a escribir el código que se puede aprender de, o ignorar - estas son las cosas en las que tengo una opinión y que son libres de tener una opinión diferente. En mi área, una buena denominación de funciones, variables, etc. se considera importante, por lo que puede obtener algunas sugerencias para mejorar la denominación. Por lo general, debe hacer cambios en ese caso (a veces encontrando un nombre aún mejor para algo). A veces encuentro errores. Tú los arreglas. A veces encuentro cosas que creo son errores, y me equivoco. Si es difícil ver que el código es correcto, puede hacerlo más obvio. Si me equivoco, me dices.

Si creo que el diseño generalmente no es correcto, entonces esto debería haberse discutido anteriormente. Entonces deberíamos pensar si su diseño es lo suficientemente bueno, teniendo en cuenta la cantidad de trabajo involucrado en un cambio, o tal vez estaba equivocado y su diseño es mejor. Deberíamos terminar con un acuerdo.

Si el revisor y el revisor no pueden estar de acuerdo, entonces tenemos un problema. Porque significa que uno de nosotros es incapaz de trabajar en equipo, o uno de nosotros es incapaz de distinguir entre un diseño bueno o malo, o ambos. Esto no es necesariamente tu culpa. Desafortunadamente, hay desarrolladores que son mayores y no tienen idea, y eso será un problema para la empresa y para usted.

Si sucede, piense muy, muy duro: ¿Tiene algún problema para aceptar críticas bien fundadas? Si ese es el caso, debe cambiar su actitud. ¿Eres demasiado inexperto para ver por qué el revisor tiene razón? Si ese es el caso, no hay problema. Confía en el crítico y aprende. ¿Estás seguro de que sabes mejor que el revisor? Acepte la revisión, pero pregúntele a un tercer desarrollador confiable sobre su opinión. Recuerde que puede estar realmente seguro de sí mismo y estar en lo cierto, pero también puede estar realmente seguro de sí mismo y estar equivocado.