¿Cómo manejo el desacuerdo en una revisión de código con respecto a un caso de borde poco probable?

  

un caso oscuro que es extremadamente improbable que ocurra, de hecho no estoy seguro de que sea posible que ocurra

No tener comportamientos no probados en el código puede ser muy importante. Si se ejecuta un fragmento de código, por ejemplo. 50 veces por segundo, una probabilidad en un millón ocurrirá aproximadamente cada 5.5 horas de tiempo de ejecución. (En su caso, las probabilidades parecen menores.)

Puede hablar sobre las prioridades con su gerente (o con quien sea una persona de mayor rango a cargo de la unidad en la que trabaja). Comprenderás mejor si, por ejemplo, trabajar en el rendimiento del código o en ser un código a prueba de balas es la máxima prioridad y cuán improbable puede ser ese caso de esquina. Su crítico también puede tener una idea sesgada de prioridades. Después de haber hablado con la persona a cargo, le resultará más fácil (dis) estar de acuerdo con las sugerencias de su revisor y tendrá algo a lo que referirse.

Siempre es una buena idea tener más de un revisor. Si su código solo es revisado por un colega, pídale a alguien más que conozca ese código, o el código base en general, que eche un vistazo. Una segunda opinión, de nuevo, le ayudará a (des) ponerse de acuerdo más fácilmente con las sugerencias del revisor.

Tener una serie de comentarios recurrentes durante varias revisiones de código generalmente indica que una cosa más grande no se comunica claramente, y los mismos problemas surgen una y otra vez. Trate de descubrir esa cosa más grande y discútala directamente con el revisor. Haz suficientes preguntas por qué . Me ayudó mucho cuando comencé a practicar la revisión de códigos.

Puedo darte un ejemplo de un caso de esquina que nunca podría ocurrir y que causó un desastre.

Cuando la Ariane 4 se estaba desarrollando, los valores del lateral accelerometers se ajustaron para encajar en un entero con signo de 16 bits y debido a que la salida máxima posible de los acelerómetros, al escalarse, podría nunca superar los 32767 y el mínimo podría nunca caída por debajo de -32768 no había "necesidad de la sobrecarga de la verificación de rango". En general, se supone que todas las entradas se deben verificar en un rango antes de cualquier conversión, pero en este caso se trataría de detectar un caso de esquina imposible.

Varios años después, se estaba desarrollando Ariane 5 y el código para escalar los acelerómetros laterales se reutilizó con pruebas mínimas como Fue "probado en uso". Desafortunadamente, el cohete más grande podría esperar mayores aceleraciones laterales, por lo que los acelerómetros se actualizaron y podrían producir 64 bits valores flotantes .

Estos valores más grandes "ajustados" en el código de conversión, recuerdan no control de rango, y los resultados del primer lanzamiento en 1996 no fueron buenos. Le costó millones a la empresa y causó una importante interrupción en el programa.

Elpuntoqueestoytratandodehaceresquenodebesignorarloscasosdepruebayaquenuncasucede,extremadamenteimprobable,etc.:lasnormasquecodificaronpidiólaverificaciónderangodetodosvaloresdeentradaexternos.Siesohubierasidoprobadoymanejado,entonceseldesastrepodríahaberseevitado.

ObservequeenAriane4estonofueunerror,(yaquetodofuncionóbienparacadavalorposible),fueunincumplimientodelosestándares.Cuandoelcódigosereutilizóenunescenariodiferente,fallócatastróficamente,mientrasquesisehubierarecortadoelrangodevaloresprobablementehubierafalladocongracia,ylaexistenciadeuncasodepruebaparaestepodríahaprovocadounarevisióndelosvalores.Tambiénvalelapenaseñalarque,mientraslosprogramadoresyevaluadoresrecibieronalgunascríticasdelosinvestigadoresdespuésdelaexplosión,lagerencia,QA&Elliderazgoquedóconlamayorpartedelaculpa.

Aclaración

Aunquenotodoelsoftwareescríticoparalaseguridad,nitanespectacularcuandofalla,miintencióneraresaltarquelaspruebas"imposibles" todavía pueden tener valor. Este es el caso más dramático que conozco, pero la robótica también puede producir algunos resultados desastrosos.

Personalmente, diría que una vez que alguien haya destacado un caso de esquina al equipo de prueba, se debe realizar una prueba para verificarlo. El jefe del equipo de implementación o el jefe de proyecto puede decidir no tratar de solucionar los fallos encontrados, pero debe tener en cuenta que existen deficiencias. Alternativamente, si la prueba es demasiado compleja o costosa de implementar, se puede plantear un problema en cualquier rastreador que esté en uso y / o en el registro de riesgos para aclarar que este es un caso no probado, que puede ser necesario abordado antes de un cambio de uso o evitar un uso inadecuado.

Ya que no se manejó antes, está fuera del alcance de su esfuerzo. Usted o su colega pueden preguntarle a su gerente si vale la pena el esfuerzo de cubrir este caso.

Con algoritmos complejos, es muy difícil demostrar que ha pensado en cada caso de prueba que se presentará en el mundo real. Cuando dejas intencionalmente un caso de prueba roto porque no aparecerá en el mundo real, potencialmente estás dejando otros casos de prueba que aún no has pensado.

El otro efecto que ocurre a menudo es cuando maneja casos de prueba adicionales, su algoritmo necesariamente se vuelve más general y, debido a eso, encuentra formas de simplificarlo y hacerlo más sólido para todos su prueba casos. Esto le ahorra tiempo de mantenimiento y solución de problemas en el camino.

Además, hay innumerables casos de "esto nunca debería suceder", errores que ocurren en la naturaleza. Esto se debe a que su algoritmo podría no cambiar, pero sus entradas podrían cambiar años después cuando nadie se acuerda de este caso de uso no manejado. Es por eso que los desarrolladores experimentados manejan este tipo de cosas cuando están frescos en sus mentes. Vuelve para morderte más tarde si no lo haces.

Esta no es una pregunta técnica, sino una decisión de estrategia empresarial. Observa que la solución sugerida es para un caso muy oscuro que casi nunca sucederá. Aquí hay una gran diferencia si está programando un juguete o si está programando un equipo médico o un dron armado. Las consecuencias de un mal funcionamiento raro serán muy diferentes.

Al realizar revisiones de código, debe aplicar una comprensión básica de las prioridades comerciales al decidir cuánto invertir en el manejo de casos raros. Si no está de acuerdo con su colega en su interpretación de las prioridades del negocio, es posible que desee tener una discusión con alguien en el lado comercial de las cosas.

Las revisiones de código no son puramente sobre la corrección del código. En realidad, eso está bastante lejos en la lista de beneficios, detrás del intercambio de conocimientos y es un proceso lento pero constante hacia la creación de un consenso de diseño / estilo de equipo.

A medida que experimenta, lo que cuenta como "correcto" es a menudo discutible, y cada uno tiene su propio ángulo sobre lo que es eso. En mi experiencia, el tiempo y la atención limitados también pueden hacer que las revisiones de código sean altamente inconsistentes: el mismo problema puede ser detectado o no dependiendo de diferentes desarrolladores y en diferentes momentos por el mismo desarrollador. Revisores en la mentalidad de "¿Qué mejoraría este código?" a menudo sugerirá cambios que no agregarían a sus propios esfuerzos de forma natural.

Como programador experimentado (más de 15 años como desarrollador), los programadores a menudo me revisan con menos años de experiencia que yo. A veces me piden cambios con los que estoy ligeramente en desacuerdo o que no me parecen importantes. Sin embargo, todavía hago esos cambios. Peleo batallas por los cambios solo cuando siento que el resultado final causaría una debilidad en el producto, donde el costo del tiempo es muy alto, o donde un punto de vista "correcto" puede ser objetivo (por ejemplo, el cambio que se solicita es ganado). t trabaje en el idioma que estamos usando, o un punto de referencia muestra que una mejora en el rendimiento no es una).

Así que sugiero que escoja sus batallas con cuidado. Dos días codificando un caso de prueba que crees que no es necesario probablemente no valga la pena el tiempo / esfuerzo para luchar. Si está utilizando una herramienta de revisión, como las solicitudes de extracción de GitHub, entonces tal vez comente sobre el costo / beneficio que percibe, para anotar su objeción, pero acepte seguir haciendo el trabajo. Esto cuenta como un retroceso suave, por lo que el revisor sabe que está alcanzando un límite y, lo que es más importante, incluye su justificación para que casos como estos se puedan escalar si entran en un punto muerto. Desea evitar la escalada de desacuerdos escritos, no desea tener un argumento de estilo de foro de Internet sobre las diferencias de trabajo, por lo que puede ser útil hablar primero del problema y registrar un resumen justo del resultado de la discusión, incluso si aún estoy de acuerdo en no estar de acuerdo sobre la necesidad del trabajo (es completamente posible que una discusión breve amigable decidirá por ambos de todos modos).

Después del evento, este es un buen tema para la revisión del sprint o las reuniones de planificación del equipo de desarrollo, etc. Preséntelo tan neutral como pueda, por ejemplo. "En la revisión del código, el Desarrollador A identificó este caso de prueba adicional, se necesitaron dos días adicionales para escribir, ¿cree el equipo que la cobertura adicional se justificó a este costo?" - este enfoque funciona mucho mejor si realmente hace el trabajo, ya que lo muestra en una luz positiva; usted ha hecho el trabajo y solo quiere encuestar al equipo por la aversión al riesgo en comparación con el desarrollo de funciones.

Le aconsejo que al menos haga valer contra el caso oscuro. De esa manera, no solo los futuros desarrolladores verán que usted decidió activamente en contra del caso, sino que con un buen manejo de fallas, que ya debería estar en su lugar, también atraparía sorpresas.

Y luego, haga un caso de prueba que afirme esa falla. De esta manera, el comportamiento está mejor documentado y se mostrará en las pruebas unitarias.

Esta respuesta asume, obviamente, que su juicio sobre el hecho de ser "extremadamente improbable si es posible" es correcto y no podemos juzgarlo. Pero si lo es, y su colega está de acuerdo, entonces una afirmación explícita contra el evento debería ser una solución satisfactoria para ambos.

Como parece que eres nuevo allí, solo hay una cosa que puedes hacer: consultar con el líder del equipo (o líder del proyecto). 13 horas es una decisión de negocios; para algunas firmas / equipos, mucho; para algunos, nada. No es tu decisión, todavía no.

Si el mensaje dice "cubre ese caso", está bien; si dice "nah, arruina", está bien, su decisión, su responsabilidad.

En cuanto a las revisiones de código en general, relájate al respecto. Tener una tarea devuelta una o dos veces es perfectamente normal.

Una cosa que no creo haber visto abordada en especie, aunque se mencionó en la respuesta de @SteveBarnes:

¿Cuáles son las repercusiones de una falla?

En algunos campos, una falla es un error en una página web. Una pantalla azul de PC y reinicios.

En otros campos, es la vida o la muerte: el auto manejo se bloquea. El marcapasos médico deja de funcionar. O en la respuesta de Steve: las cosas explotan y se pierden millones de dólares.

Hay un mundo de diferencia en esos extremos.

El hecho de que valga la pena o no las 13 horas para cubrir un "fracaso" no debería depender de usted. Debe estar a cargo de la administración y los propietarios. Deben tener una idea de la imagen más grande.

Debería poder hacer una buena estimación de lo que valdrá la pena. ¿Su robot simplemente disminuirá la velocidad o se detendrá? ¿Rendimiento degradado? ¿O un fallo del robot causará daño monetario? ¿Pérdida de vida?

La respuesta a esa pregunta debe conducir la respuesta a "¿vale la pena 13 horas de tiempo de las empresas". Aviso: Dije el tiempo de las empresas. Pagan las cuentas y finalmente deciden lo que vale la pena. Su gerencia debe tener la última palabra de cualquier manera.

¿Tal vez hablar con la persona responsable de priorizar el trabajo? En el inicio podría ser CTO o propietario del producto. Él podría ayudar a encontrar si se requiere este trabajo extra y por qué. También puede traer sus preocupaciones durante los enfrentamientos diarios (si los tiene).

Si no hay una responsabilidad clara (por ejemplo, el propietario del producto) para el trabajo de planificación, intente hablar con las personas que lo rodean. Más tarde, podría convertirse en un problema que todos están llevando el producto a la dirección opuesta.

La mejor manera de manejar el desacuerdo es la misma, independientemente de si eres un desarrollador junior o un desarrollador senior, o incluso un CEO.

Actúa como Columbo .

Si nunca has visto ningún Columbo, fue un espectáculo bastante fantástico. Columbo era un personaje muy modesto: la mayoría de la gente pensaba que estaba un poco loco y que no valía la pena preocuparse. Pero al parecer humilde, y solo pedirle a la gente que explique que él fue capaz de obtener a su hombre.

Creo que también está relacionado con el método socrático .

En general, desea hacer preguntas a usted mismo y a los demás para asegurarse de que está tomando las decisiones correctas. No desde una posición de "Tengo razón, te equivocas", sino desde una posición de descubrimiento honesto. O al menos lo mejor que puedas.

En tu caso, tienes dos ideas aquí, pero tienen el mismo objetivo fundamental: mejorar el código.

Tiene la impresión de que escatimar en la cobertura de código para un caso potencialmente improbable (¿imposible?) en favor del desarrollo de otras funciones es la mejor manera de hacerlo.

Su compañero de trabajo tiene la impresión de que es más valioso ser más cuidadoso con los casos de esquina.

¿Qué ven ellos que tú no ves? ¿Qué ves que no ven? Como desarrollador junior, en realidad estás en una excelente posición porque naturalmente debería hacer preguntas. En otra respuesta, alguien menciona cuán sorprendentemente probable es un caso de esquina. Así que puedes comenzar diciendo: "Ayúdame a entender, tenía la impresión de que X, Y y Z, ¿qué me falta? ¿Por qué el framboozle del widget? Tenía la impresión de que podría resolverse en circunstancias cromulentas. Will ¿La varilla de swizzle en realidad incluye los pinceles ANZA? "

A medida que cuestione sus suposiciones y sus conclusiones, investigará, descubrirá sesgos y, finalmente, descubrirá cuál es el curso de acción correcto.

Comience asumiendo que todos los integrantes de su equipo son perfectamente racionales y tienen en mente los mejores intereses del equipo y del producto, igual que usted. Si están haciendo algo que no tiene sentido, entonces necesitas descubrir qué es lo que no sabes que hacen o lo que no.

13 horas no es tan importante, simplemente lo haría. Recuerda que te están pagando por ello. Sólo tiza como "seguridad laboral". También es mejor mantener un buen karma entre el equipo. Ahora, si era algo que le llevaría una semana o más, entonces podría involucrar a su gerente y preguntarle si ese es el mejor uso de su tiempo, especialmente si no está de acuerdo con él.

Sin embargo, parece que necesita un apalancamiento en su grupo. Aquí le explicamos cómo puede aprovechar: pedir perdón, no pedir permiso. Agregue cosas al programa como mejor le parezca (dentro del alcance del curso, es decir, asegúrese de que resuelva por completo el problema que el jefe quiere ...) e infórmeselo al gerente o a sus colegas después del hecho. No les preguntes: "¿Está bien si agrego la característica X". Más bien, simplemente agregue las características que personalmente desea en el programa. Si se enojan con una nueva característica o no están de acuerdo, quítelo. Si les gusta, guárdalo.

Además, cada vez que te piden que hagas algo, recorres la "milla extra" y agregas muchas cosas que olvidaron mencionar o cosas que funcionarían mejor que lo que dijeron. Pero no les preguntes si está "bien" hacer un esfuerzo adicional. Solo hazlo y cuéntalo casualmente después de que haya terminado. Lo que estás haciendo es entrenarlos ...

Lo que sucederá será que su gerente lo considerará un "entusiasta" y comenzará a depositar su confianza en usted, y sus colegas comenzarán a verlo como el líder, porque usted comienza a ser el propietario del programa. Y luego, cuando ocurran cosas como lo que mencionas en el futuro, tendrás más opinión porque esencialmente eres la estrella del equipo y los compañeros de equipo se retirarán si no estás de acuerdo con ellos.

La revisión del código tiene varios propósitos. Una de la que es consciente, obviamente, es " ¿Este código cumple con su propósito? " En otras palabras, es funcionalmente correcto; ¿Está adecuadamente probado? son las partes no obvias debidamente comentadas; ¿Se ajusta a las convenciones del proyecto?

Otra parte de la revisión del código es compartir el conocimiento sobre el sistema. Es una oportunidad para que tanto el autor como el revisor aprendan sobre el código modificado y cómo interactúa con el resto del sistema.

Un tercer aspecto es que puede proporcionar una revisión de los problemas que existían antes de realizar cualquier cambio. Muy a menudo, cuando reviso los cambios de otra persona, detectaré algo que omití en una iteración anterior (muy a menudo algo mío). Una declaración como, "Aquí hay una oportunidad para hacer que esto sea más sólido de lo que era", no es una crítica, ¡y no lo tome como uno!

Mi equipo actual considera la revisión del código no solo como una puerta de acceso o un obstáculo que el código debe pasar sin daños antes de confirmar, sino que principalmente como una oportunidad para una discusión un tanto estructurada de un área particular de funcionalidad. Es una de las ocasiones más productivas para compartir información. (Y esa es una buena razón para compartir la revisión de todo el equipo, en lugar de ser siempre el mismo crítico).

Si percibes las revisiones de código como una actividad de confrontación, esa es una profecía autocumplida. Si, por el contrario, los considera como la parte más colaborativa de su trabajo, estimularán las mejoras continuas en su producto y en la forma en que trabajan juntos. Ayuda si una revisión puede ser clara sobre las prioridades relativas de sus sugerencias, hay una milla de diferencia entre "Me gustaría un comentario útil aquí" y "Esto se rompe si x es negativo", por ejemplo.

Habiendo hecho muchas declaraciones generales arriba, ¿cómo se aplica eso a su situación específica? Espero que ahora sea obvio que mi consejo es responder a la revisión con preguntas abiertas y negociar qué enfoque tiene el mayor valor. Para su caso de ejemplo donde se sugiere una prueba adicional, entonces algo como "Sí, podemos realizar una prueba para eso; estimo que tomará < time > para implementar. ¿Cree que vale la pena el beneficio? ¿Y hay algo más que podamos hacer para garantizar que la prueba no sea necesaria? "

Una cosa que me sorprende cuando leo tu pregunta: si se requieren dos días de esfuerzo para escribir un nuevo caso de prueba, entonces tu nueva prueba es un escenario muy diferente a tus pruebas existentes (en cuyo caso probablemente haya mucho valor) o ha identificado la necesidad de una mejor reutilización del código en la suite de prueba.

Finalmente, como un comentario general sobre el valor de las revisiones de código (y como un resumen conciso de lo que he dicho anteriormente), me gusta esta declaración, en Maintainers Don't Scale por Daniel Vetter :

  

Al menos para mí, la revisión no se trata solo de garantizar la buena calidad del código, sino también de difundir el conocimiento y mejorar la comprensión. Al principio tal vez haya una sola persona, el autor (y eso no es un hecho), entendiendo el código. Después de una buena revisión, debe haber al menos dos personas que lo entiendan completamente, incluidos los casos de esquina.

El código SIEMPRE puede ser mejor.

Si estás en una revisión de código y no ves nada que pueda ser mejor o una prueba de unidad que pueda detectar un error, no es el código perfecto, pero el revisor no está haciendo su trabajo. Si eliges mencionar la mejora es una elección personal. Pero casi cada vez que su equipo hace una revisión del código, debería haber cosas que alguien note que podrían ser mejores o que todos probablemente hayan perdido el tiempo.

Dicho esto, si usted actúa sobre los comentarios o no, depende de su equipo. Si sus cambios solucionan el problema o agregan suficiente valor sin cambios que su equipo los acepte, entonces combínelos y registre sus comentarios en el registro para que alguien los aborde más adelante. Si el equipo encuentra que sus cambios agregan más riesgo o complejidad que valor, entonces tiene que resolver los problemas en consecuencia.

Solo recuerda que el código cualquiera tiene al menos un caso de borde más que se podría probar y podría usar al menos una refactorización más. Esta es la razón por la que las revisiones de código se realizan mejor como un grupo con todos los que miran el mismo código al mismo tiempo. Para que al final todos puedan llegar a un consenso sobre si el código en revisión es o no aceptable (como lo es) y agrega suficiente valor para unirse a la base de la comunidad o si hay que hacer ciertas cosas antes de que haya suficiente valor para fusionar .

Dado que está haciendo esta pregunta, asumo que en realidad no está haciendo "revisiones de código", sino que está creando una solicitud de extracción u otro mecanismo de envío para que otros puedan comentar de una manera no determinista. Así que ahora estás en un problema de gestión y una definición de hecho. Supongo que su administración es indecisa y en realidad no comprende el proceso y el propósito de las revisiones de código y es probable que no tenga una "definición de hecho" (DOD). Porque si lo hicieran, su DOD respondería explícitamente a esta pregunta y usted no tendría que venir aquí y preguntar.

¿Cómo lo arreglas? Bueno, pídale a su gerente que le dé un DOD y le diga si siempre debe implementar todos los comentarios. Si la persona en cuestión es su gerente, entonces la respuesta es evidente.

Esta pregunta no trata sobre las virtudes de la programación defensiva, los peligros de los casos de esquina o los riesgos catastróficos de los errores en los productos físicos. De hecho, ni siquiera se trata de ingeniería de software en absoluto .

De lo que realmente se trata es cómo un profesional junior maneja las instrucciones de un profesional superior cuando el junior no puede estar de acuerdo o apreciarlo.

Hay dos cosas que debes apreciar para ser un desarrollador junior. En primer lugar, significa que, si bien es posible que usted está en lo correcto, y que él está equivocado, lo es, en el balance de probabilidades, no es probable. Si su compañero de trabajo le está sugiriendo que no puede ver el valor, debe considerar seriamente la posibilidad de que simplemente no tenga la experiencia suficiente para entenderlo. No tengo ese sentido de esta publicación.

Lo segundo que hay que apreciar es que su socio principal se llama así porque tiene más responsabilidad. Si un joven rompe algo importante, no estará en problemas si sigue las instrucciones. Sin embargo, si un senior les permitiera que lo rompieran, al no plantear problemas en la revisión del código, con toda razón se sentirían muy molestos.

En última instancia, es un requisito implícito de su trabajo que observe las instrucciones de aquellos en los que la empresa confía para dirigir sus proyectos. ¿En general, es incapaz de diferir a los adultos mayores cuando hay buenas razones para valorar su experiencia? ¿Tiene la intención de seguir ninguna instrucción que no pueda entender? ¿Crees que el mundo debería detenerse hasta que estés convencido? Estos valores son incompatibles con trabajar en equipo.

Un punto final. Piensa en los proyectos que escribiste hace seis meses. Piensa en los proyectos que escribiste en la universidad. ¿Ves lo mal que parecen ahora, todos los errores y el diseño al revés, los puntos ciegos y las abstracciones mal orientadas? ¿Qué pasaría si le dijera que dentro de seis meses contará las mismas fallas en el trabajo que está haciendo hoy? ¿Eso ayuda a demostrar cuántos puntos ciegos hay en tu enfoque actual? Porque esa es la diferencia que hace la experiencia.

  

constantemente hace comentarios a mi código que me sugieren hacer mucho más   trabajo que es necesario.

Puedes dar recomendaciones, pero en última instancia no es tu función decidir qué es necesario. Es su trabajo implementar lo que la administración o (en este caso, su revisor) decida que es necesario. Si no está de acuerdo con lo que es demasiado necesario o demasiado fuerte, es probable que se quede sin trabajo. En consecuencia, es parte de su profesionalismo aceptar esto y estar en paz con él.

  

Me había sugerido que manejara un caso oscuro que es extremadamente   poco probable que suceda

Aquí hay otras grandes respuestas que muestran cómo incluso los que no son errores (es decir, algo que probablemente no puede fallar alguna vez ) todavía deben volver a trabajarse. (p. ej., en el caso de construir en el futuro la seguridad del producto, seguir los estándares, etc.) Parte del rol de un gran desarrollador es tener la mayor confianza posible de que su código será robusto en cada situación posible cada vez y en el futuro. a prueba de errores, no solo trabaja en situaciones probadas en las condiciones actuales la mayor parte del tiempo

Sugerencias a los revisores de códigos para aumentar la utilidad comercial de su revisión de código (usted como OP debería proponer tal cambio):

• Marque sus comentarios por tipo. "Crítico" / "Debe hacer" / "Opcional" / "Mejoras sugeridas" / "Es bueno tener" / "Estoy reflexionando".

  Si esto parece demasiado CDO / anal / complicado, al menos use 2 niveles: "Debe arreglarse para aprobar la revisión y se le debe permitir fusionar su cambio" / "Todos los demás".

Sugerencias para manejar las sugerencias de revisión de código que parecen menos críticas:

• Cree un ticket abierto en el sistema de emisión de boletos que elija (¿su equipo usa uno, con suerte?), siguiendo la sugerencia

• Coloque el número de boleto como un comentario de respuesta al elemento de revisión de código si su proceso permite respuestas a comentarios como lo hacen las reseñas de ojo de pez o de correo electrónico.

• Comuníquese con el revisor y pregunte explícitamente si ese elemento es del tipo "debe arreglarse o no se fusionará / liberará".

  • Si la respuesta es "Sí", pero usted no está de acuerdo, deje que la persona responsable de la gestión del proyecto (PM, su gerente, etc.) tome una decisión: presente el desacuerdo de manera completa y honesta. Esto no tiene que ver con cuál de ustedes tiene "razón", sino con lo que es mejor para el proyecto, por lo tanto, el trabajo del gerente o gerente de proyecto.

Ahora, trate ese ticket como cualquier otra solicitud de desarrollo.

1. Si se decide ser urgente después de la escalada, trátela como una solicitud de desarrollo urgente. Deprioretizar otro trabajo y trabajar en esto.

2. De lo contrario, trabaje en él de acuerdo con la prioridad que le asignaron y su ROI (que puede diferir según su línea comercial, como se explica en otras respuestas).

Debería no escalar esto a la administración.

En la mayoría de las empresas, el encargado de la gestión siempre elegirá no escribir esa prueba adicional, no pasar un tiempo mejorando la calidad del código, para no perder tiempo refactorizando.

En muchos casos, la calidad del código depende de las reglas no escritas en el equipo de desarrollo y del esfuerzo adicional que ponen los programadores.

Eres un desarrollador junior y esta es tu primera revisión de código . Debes aceptar el consejo y hacer el trabajo. Solo puede mejorar el flujo de trabajo y las reglas de su equipo si las conoce y respeta por un tiempo para que pueda entender por qué están allí. De lo contrario, serás ese tipo nuevo que no respeta las reglas y se convierte en el lobo solitario del equipo.

Eres nuevo en el equipo, sigue los consejos que obtienes por un tiempo, descubre por qué están allí, no traigas los primeros consejos que te cuestionen en la reunión de scrum. Las verdaderas prioridades comerciales serán evidentes para usted después de un tiempo sin preguntar (y puede que no sea lo que el responsable de administración le dirá cara a cara).

Es muy importante que haga un código que satisfaga lo que su solicitud de liderazgo / gestión. Cualquier otro detalle sería simplemente "agradable de tener". Si eres un experto (lee: "si no eres un desarrollador junior") en tu campo, entonces eres "elegible" para abordar los problemas menores que encuentres en el camino sin consultar a tus líderes en todo momento.

Si crees que algo está mal y eres relativamente experto en tu campo, entonces hay muchas posibilidades de que tengas razón .

Aquí hay algunas declaraciones que podrían ser útiles para usted:

• Se me pidió que hiciera X, el revisor de código sugiere que también haga Y, ¿debería hacerlo o debería pasar a cosas más importantes?
• Me estás sugiriendo Y, así que, ¿puedes averiguar al menos un caso de prueba que detecte ese comportamiento para que yo pueda probarlo? Creo que ese código no será llamado.
• ¿Quizás no deberíamos desarrollar un respaldo seguro para los casos no cubiertos primero? Así que los detectamos temprano y los arreglamos sobre la marcha para poder enfocarnos en cosas más importantes.
• bien, mientras estoy implementando Y, ¿podría ser tan amable de escribir algunos casos de prueba para que podamos hacer eso de una vez por todas ?
• Se me pidió que hiciera X, y creo que podría hacerlo Y a menos que haya otras prioridades. La próxima vez, ¿por qué no presenta una solicitud de función en lugar de ponerla como comentario de revisión en mi código ? Al menos podemos escuchar más opiniones de otros miembros del equipo sobre esa característica antes de implementarla (generalmente cualquier cosa importante debe ser una característica y debe ser manejada por más de una persona; por lo general, la revisión del código debe ser sobre revisión enfoques de código y soluciones; el resto es corrección de errores y características).

¿Piensas seriamente que la actitud de tu crítico está dañando el proyecto o crees que es correcto la mayoría de las veces (excepto que a veces él simplemente comete errores menores en la evaluación? y exagera eso)?

Para mí, suena más como que está escribiendo cosas que no pertenecen a una revisión de código, lo cual es una mala práctica porque hace que sea más difícil para todos rastrear cosas. Sin embargo, no sé qué otros comentarios de revisión hizo, así que no puedo decir nada sobre otros casos.

En general, intente evitar lo siguiente:

• No estás haciendo lo que se ha solicitado
• Haces que tu crítico se sienta tonto

Si en realidad está revisando tu código, es porque la gerencia confía en él más que tú.

Cuando hay desacuerdo durante la revisión del código sobre el alcance:

1. Documente el alcance que está realmente cubierto por el código. A nadie le gustan las sorpresas desagradables.
2. Date cuenta de que el alcance es una decisión de negocios. El alcance ya debería conocerse cuando comience a trabajar en una función, pero si no lo está, siempre puede pedir una aclaración más adelante.

Si el revisor de código es el que toma las decisiones comerciales, puede cambiar el alcance en cualquier momento, incluso durante la revisión del código, pero no lo hace en su función de revisor de código.

Si no puede probar que el caso de borde sea imposible, debe asumir que es posible. Si es posible, entonces es inevitable que eventualmente ocurra, y más temprano que tarde. Si el caso de Edge no se ha producido en las pruebas, puede ser un indicio de que la cobertura de la prueba está incompleta.

1. Acepta los comentarios.
2. Antes de realizar cambios en su código, intente crear una prueba para el caso de Edge y ver si puede obtener una falla en la prueba (prueba de que el problema existe). Si es imposible crear un caso de prueba de este tipo y obtener una falla de prueba, entonces puede poder concluir que el caso de borde es realmente imposible (aunque dudaría en sacar tal conclusión) .
3. Si puede obtener una falla en la prueba, aplique el cambio de código apropiado para pasar la prueba.

Por el bien del producto, es probable que desee poder producir el caso perimetral e inducir una falla, de modo que pueda aplicar la solución y tener confianza en que se ha evitado un problema potencial.

El punto principal de las revisiones de código es poner ojos adicionales en el código. Ninguno de nosotros es inmune a los errores o descuidos. Es muy común mirar un fragmento de código muchas veces y no notar un error obvio, donde un par de ojos nuevos pueden detectarlo inmediatamente.

Como dijiste, has implementado un nuevo algoritmo. No sería prudente sacar conclusiones sobre el comportamiento de su nuevo algoritmo basado en el comportamiento u observaciones acerca de su predecesor.

Hay revisores de códigos que saben lo que están haciendo, y si dicen que se debe cambiar algo, entonces se debe cambiar, y cuando dicen que se debe probar algo, entonces se debe probar.

Hay revisores de códigos que necesitan justificar su propia existencia creando un trabajo inútil para otros.

Cuál es cuál es para que usted decida, y cómo manejar el segundo tipo es más una pregunta para el lugar de trabajo.

Si usas scrum, entonces la pregunta es si tu trabajo hace lo que se supone que debe hacer (aparentemente lo hace), y puedes poner el caso extremadamente raro y tal vez imposible en el backlog, donde será priorizado, y si entra en un sprint, entonces tu revisor puede sentirse libre de recogerlo y hacer el trabajo de 13 horas. Si realiza el trabajo X y debido a que realiza el trabajo X, se da cuenta de que el trabajo Y también necesita hacerlo, entonces el trabajo Y no se convierte en parte del trabajo X, es su propio trabajo independiente.