¿Cómo rechazar una revisión de código que crees que es innecesaria?

Estoy en una posición en la que me han pedido que revise un código que soluciona un problema que no creo que exista.

El programa de reparación, que tiene más experiencia que yo, insiste en que su solución es necesaria, pero para mí no parece ser más que un sofisma de C ++. Parte de nuestro proceso de implementación es una revisión de código, y como el segundo ingeniero más importante en una pequeña empresa, se espera que revise los cambios.

Creo que los revisores son tan responsables de los cambios de código como el codificador original, y no estoy dispuesto a aceptar la responsabilidad de este cambio. ¿Cómo rechazarías esta crítica?

Solicite un caso de prueba que falle sin el cambio que tiene éxito con el cambio.

Si él no puede producir uno, lo usas como justificación.

Si puede producir uno, debe explicar por qué la prueba no es válida.

Los revisores deben ser objetivos.

Está claro que has formado una opinión sobre el código en cuestión antes de siquiera haberlo revisado, y parece que tú y el fijador han replanteado posiciones. Si es así, entonces tendrá dificultades para aparecer como objetivo y un momento aún más difícil para ser objetivo. Nada de eso ayuda al proceso, y puede ser que lo mejor y más objetivo que puede hacer es retirarse con el argumento de que está demasiado cerca del problema.

Considere un enfoque de equipo.

Si no es posible eliminarse, tal vez pueda hacer que otros ingenieros revisen el código al mismo tiempo. O estarán de acuerdo con usted en que el código debe ser rechazado o no. Si están de acuerdo con usted, entonces ya no será solo usted frente al reparador, y podrá establecer un caso más sólido en el que el equipo analizó la solución objetivamente y decidió no aceptarla. Por otro lado, si deciden aceptar la solución, esa también será una decisión del equipo. No es necesario decir que debe participar con una mente tan abierta como sea posible y que no debe tratar de influir en las opiniones de los otros miembros del equipo con otra cosa que no sea una discusión racional. Importante: si después hay un mal resultado, no arrojes al equipo debajo del autobús diciendo "Bueno, yo siempre decía que era un código incorrecto, pero los demás miembros del equipo me superaban en número ".

Los rechazos son una parte natural del proceso de revisión del código.

El proceso de revisión del código no está ahí para las correcciones de sellos de goma de personas más mayores; está ahí para proteger y mejorar la calidad del código. No hay nada de malo en rechazar una solución siempre que lo haga por la razón correcta, es decir, que la solución no mejore el código. Si, después de una revisión abierta del código, todavía siente que la solución no reduce el riesgo y / o la magnitud de un problema demostrable, entonces debe rechazarlo. No es personal, solo tu sincera opinión. Si el reparador no está de acuerdo, también está bien, y en ese momento se convierte en un problema para la administración. Solo asegúrese de ser honesto, abierto y profesional.

La responsabilidad corta en ambos sentidos.

Dijiste que no quieres ser responsable de este cambio, aparentemente porque no crees que haya un problema. Sin embargo, es necesario darse cuenta de que si se equivoca y no es un problema, entonces puede llegar a ser responsable de rechazar el código que habría evitado el problema.

Toma nota.

Mantener un registro escrito del proceso de revisión lo ayudará a mantener sus datos correctos. Escriba sus pensamientos y preocupaciones mientras revisa, describe y los resultados de cualquier prueba que pueda realizar para medir el supuesto problema y la solución, etc. Si el problema se intensifica, tendrá un registro de lo que ha hecho para respaldar su posición. Si el asunto vuelve a surgir en el futuro (probablemente lo hará si el fijador está conectado a su propia vista), tendrá algo para refrescar su memoria.

Escriba sus razones de rechazo y defensas para posibles contraargumentos. Luego discuta racionalmente con el fijador y, si es necesario, escale a la administración.

Si tiene suficiente documentación (incluidas listas de códigos, resultados de pruebas y argumentos objetivos ), estará bien cubierto.

Causará alguna mala voluntad con el fijador, así que asegúrese de que el problema valga la pena (es decir, ¿la no reparación causa daño?)

Además, si el reparador está relacionado de alguna manera con los propietarios, olvide esta respuesta.

Recientemente en las noticias de LinkedIn, había un artículo sobre la resolución de conflictos en el lugar de trabajo y ser humilde, en lugar de parecer arrogante. Lamentablemente, no puedo encontrar el enlace ahora, pero la esencia general era tratar de formular preguntas de una manera no conflictiva. Por favor, no entiendas esto como si dijera que eres arrogante, es solo la forma en que se escribió el artículo.

De todos modos, decirle al programador sénior que está equivocado en su suposición solo lo llevará a tomar un enfoque defensivo y atacarlo nuevamente en su respuesta. Sin embargo, si plantea la pregunta de por qué cree que existe el problema, desde el punto de vista de su falta de comprensión, es probable que esté más abierto a discutir el asunto.

Entonces, en lugar de decir "El problema no existe, así que no debería tener que revisar esto", tal vez pregunte algo como "Para revisar esto correctamente, necesito entender el problema. ¿Puede explicarlo a su ¿punto de vista?"

Como ejemplo, el artículo describió una prueba realizada a niños donde un adulto sostenía un cubo cuyas caras eran todas de un color, excepto la que estaba frente al adulto. Cuando se les preguntó a los niños qué color estaba viendo la cara del adulto, los menores de 5 años casi siempre decían el color que podían ver, ya que no podían comprender que el adulto pudiera tener una visión diferente a la suya.

C / C ++ puede estar lleno de comportamientos indefinidos. Por un lado, es malo, ya que puede conducir a comportamientos inesperados. Por otro lado, permite una optimización agresiva y, por lo general, cuando usa C / C ++ le interesa la velocidad.

Escribir un caso de prueba que se rompa puede ser difícil; puede involucrar una arquitectura extraña o un compilador que ya no existe. También puede parecer que en cualquier arquitectura sensata "no debería causar ningún problema".

Sin embargo, en un momento u otro cambiará la plataforma (por ejemplo, si desea volverse móvil para portar a ARM o desea acelerar las cosas y usar GPU). En este punto, las cosas pueden comenzar a romperse y deberá depurarlo. Puede ser tan trivial como actualizar el compilador a una versión más nueva (y es posible que lo desee / lo necesite).

El código problemático fue:

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

Durante la última iteración d[++k] => d[++15] => d[16]se accede. Como generalmente el siguiente elemento era la memoria legal (en términos de paginación, no el modelo de memoria C), incluso los compiladores triviales no producían ningún ejecutable con comportamiento extraño. La única forma de escribir el caso de prueba era encontrar una plataforma con exactamente el mismo modelo de memoria que C (probablemente VM).

Sin embargo, se ve gcc 4.8 prerelase que d[++k]se ejecuta en cada bucle. De lo k < 16contrario, el acceso sería ilegal y la legalidad del programa alimentado al compilador es parte del contrato. Entonces, la condición del bucle siempre es verdadera dados los supuestos, por lo que es un bucle infinito. Esto puede sonar extraño, pero era una optimización perfectamente legal: la emisión system("dd if=/dev/zero of=/dev/sda"); system("format c:")también sería el reemplazo correcto del bucle. Hay formas más sutiles de elegir exhibir comportamientos. Por ejemplo, durante la conferencia sobre memoria transaccional , recuerdo que el presentador intentó varias veces obtener un valor incorrecto cuando 2 hilos aumentaron el mismo valor.

Sin embargo, C / C ++, a diferencia de algunos lenguajes, está estandarizado, por lo que dicha disputa se puede hacer con referencia a la fuente objetiva:

• Si cree que esto no es un problema, intente probarlo utilizando el estándar C / C ++ (es decir, que conduce a un valor y comportamiento definidos)
• Si piensa que esto es un problema, pídale que lo pruebe usando el estándar C / C ++ (es decir, que conduce a un valor o comportamiento indefinido)

En general, si su equipo está escribiendo en C / C ++, es útil tener a mano el estándar, incluso los expertos del equipo pueden encontrar algo extraño allí de vez en cuando.

Esto suena más como un problema con la política de su equipo que con esta revisión específica. Cuando trabajé en una gran tienda de software en un equipo de 9 personas, un crítico absoluto tenía poder de veto sobre el código, y este era un estándar que todos respetamos. Éramos bastante talentosos e inteligentes, a saber. "maduro", pero más en el sentido de "no infantil" que "experimentado" - que nuestro líder de equipo podría esperar razonablemente que siempre podamos llegar a un acuerdo sin tener que recurrir a argumentos en un período de tiempo prudente.

Simplemente en función de su idioma en su publicación, podría advertirle que parece que va a abordar esta situación de una manera que podría conducir a un argumento descentralizado. Tal vez sea "masturbación intelectual", pero probablemente haya una razón por la que él o ella lo hizo, y la carga para usted será encontrar una forma más simple de resolver ese problema, y ​​si no existe, documente en el comentario por qué el código masturbatorio era, de hecho, necesario.

Haga que el remitente muestre pruebas de que su código soluciona su problema. Si él puede probar y mostrarle pruebas, entonces usted es el que está equivocado y debería dejar de quejarse y lidiar con eso. Si no puede mostrar pruebas para respaldar su reclamo, hay un problema y mostrar pruebas de que su parche soluciona el problema, entonces lo enviaría de vuelta a la mesa de dibujo.

Por supuesto, podría haber una política interna sensible en torno a esto. Pero esta es la forma en que iría (deliciosamente).