Los revisores deben ser objetivos.
Está claro que se formó una opinión sobre el código en cuestión antes de siquiera haberlo revisado, y parece que usted y el reparador han establecido posiciones. Si eso es así, entonces tendrá un momento difícil para aparecer como objetivo, y un momento aún más difícil para ser ser . Nada de eso ayuda al proceso, y puede ser que lo mejor y más objetivo que puede hacer es retirarse porque está demasiado cerca del problema.
Considera un enfoque de equipo.
Si no es posible eliminarlo, quizás 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 lo harán. Si están de acuerdo con usted, entonces ya no será solo usted contra el reparador, y podrá demostrar que el equipo analizó la corrección de manera objetiva y decidió no aceptarla. Por otro lado, si deciden aceptar el arreglo, también será una decisión del equipo. No hace falta decir que deberías participar con una mente tan abierta como puedas manejar, y que no debes tratar de influir en las opiniones de los otros miembros del equipo mediante otra cosa que no sea una discusión racional. Importante: si hay un mal resultado más tarde, no lance al equipo debajo del autobús diciendo "Bueno, Yo siempre dije que era un código incorrecto, pero los demás miembros del equipo me superaron en número". p>
Los rechazos son una parte natural del proceso de revisión del código.
El proceso de revisión de código no está disponible para reparaciones de sellos de goma de personas 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 hagas por la razón correcta, es decir, que la solución no mejora el código. Si, después de una revisión abierta del código, aún 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 honesta opinión. Si el reparador no está de acuerdo, eso también está bien, y en ese punto se convierte en un problema para que la gerencia lo descubra. Solo asegúrate de ser honesto, abierto y profesional.
La responsabilidad se reduce en ambos sentidos.
Usted dijo que no quiere ser responsable de este cambio, aparentemente porque no cree que haya un problema. Sin embargo, debes darte cuenta de que si te equivocas y hay un problema , puedes terminar siendo responsable de rechazar el código que hubiera evitado el problema.
Toma notas.
Mantener un registro escrito del proceso de revisión le ayudará a mantener sus datos claros. Escriba sus pensamientos e inquietudes al revisar, la descripción y los resultados de cualquier prueba que pueda realizar para medir el supuesto problema y la solución, etc. Si el problema aumenta, tendrá un registro de lo que ha hecho para respaldar su posición. Si vuelve a surgir el problema en el futuro (probablemente lo hará si el reparador está adjunto a su propia vista), tendrá algo para refrescar su memoria.