Cuando reviso el código, normalmente trato de hacer recomendaciones específicas sobre cómo resolver los problemas. Pero debido al tiempo limitado que uno puede pasar para revisar, esto no siempre funciona bien. En estos casos, encuentro más eficiente si el desarrollador encuentra una solución por sí mismo.
Hoy revisé un código y descubrí que una clase obviamente no estaba bien diseñada. Tenía una serie de atributos opcionales que solo se asignaban a ciertos objetos y se dejaban en blanco para otros. La forma estándar de resolver esto sería dividir la clase y usar la herencia. Sin embargo, en este caso específico, esta solución parecía complicar demasiado las cosas. Yo no participé en el desarrollo de este software y no estoy familiarizado con todos los módulos. Por lo tanto, no me sentí lo suficientemente informado como para tomar una decisión específica.
Otro caso típico que experimenté muchas veces es que encuentro una función, un nombre de clase o variable obviamente sin sentido o incluso engañoso, pero no puedo encontrar un buen nombre yo mismo.
En general, como revisor, ¿está bien decir "este código es defectuoso porque ..., lo hace de manera diferente" o tiene que encontrar una solución específica?
fuente
Respuestas:
Como revisor, su trabajo es verificar si un código (o documento) cumple con ciertos objetivos que se acordaron antes de la revisión.
Algunos de estos objetivos generalmente implicarán una decisión de juicio si el objetivo se ha cumplido o no. Por ejemplo, el objetivo de que el código debe ser mantenible generalmente requiere una llamada de juicio.
Como revisor, es su trabajo señalar dónde no se han cumplido los objetivos y es el trabajo del autor asegurarse de que su trabajo realmente cumpla con los objetivos. De esta manera, no es su trabajo decir cómo deben hacerse las correcciones.
Por otro lado, solo decirle al autor "esto es defectuoso. Arreglarlo" generalmente no conduce a una atmósfera positiva en el equipo. Para una atmósfera positiva, es bueno al menos indicar por qué algo tiene defectos en los ojos y proporcionar una mejor alternativa si tiene una.
Además de eso, si está revisando algo que parece "incorrecto" pero realmente no tiene una mejor alternativa, entonces también podría dejar un comentario en la línea de "Este código / diseño no me sienta bien, pero yo no tengo una alternativa clara. ¿Podemos discutir esto? " y luego intenten obtener algo mejor juntos.
fuente
Algunas buenas respuestas aquí, pero creo que falta un punto importante. Hace una gran diferencia el código que está revisando, qué tan experimentada es esa persona y cómo maneja esas sugerencias. Si conoce bien a su compañero de equipo y espera que una nota como "este código sea defectuoso porque ..., hágalo de manera diferente" sea suficiente para que él o ella encuentre una mejor solución, entonces ese comentario puede estar bien. Pero definitivamente hay personas en las que dicho comentario no es suficiente, y que necesitan que se les diga exactamente cómo mejorar su código. Entonces, en mi humilde opinión, esta es una decisión judicial que solo puede hacer para el caso individual.
fuente
Ninguno de los dos es la OMI ideal. Lo mejor que puede hacer es hablar con el autor y solucionar el problema en colaboración.
Las revisiones de código no tienen que ser asíncronas. Se desbloquearán muchos problemas si deja de verlos como un proceso burocrático y se toma un poco de tiempo para la comunicación en vivo.
fuente
No. Si estás haciendo eso, no eres un crítico, eres el próximo codificador.
No. Su trabajo es comunicar el problema en cuestión. Si presentar una solución aclara el problema, hágalo. Simplemente no esperes que siga tu solución. Lo único que puedes hacer aquí es hacer un punto. No puede dictar la implementación.
Cuando esa es la forma más efectiva de comunicarse. Somos monos codificados, no mayores ingleses. A veces, la mejor manera de mostrar que el código apesta ... es menos que óptimo ... es mostrarles el código que apesta menos ... es más opt ... oh diablos, ya sabes a qué me refiero.
fuente
El problema principal es que si las personas supieran cómo escribir mejor el código, por lo general lo habrían hecho en primer lugar. Si una crítica es lo suficientemente específica depende mucho de la experiencia del autor. Los programadores con mucha experiencia podrían recibir críticas como "esta clase es demasiado complicada" y volver a la mesa de dibujo y encontrar algo mejor, porque simplemente tuvieron un mal día debido a un dolor de cabeza o estaban siendo descuidados porque estaban escapado.
Sin embargo, por lo general, debe identificar al menos la fuente de la complicación. "Esta clase es demasiado complicada porque infringe la Ley de Demeter por todas partes". "Esta clase mezcla las responsabilidades de la capa de presentación y la capa de persistencia". Aprender a identificar esas razones y explicarlas sucintamente es parte de convertirse en un mejor crítico. Raramente tiene que entrar en muchos detalles sobre las soluciones.
fuente
Hay dos tipos de programadores malos: los que no siguen las prácticas estándar y los que "solo" siguen las prácticas estándar.
Cuando he tenido contacto laboral limitado / proporcionar comentarios a alguien, no diría, "Este es un mal diseño". pero algo así como "¿Puedes explicarme esta clase?" Puede descubrir que es una buena solución, el desarrollador sinceramente hizo lo mejor que pudo o incluso reconoció que es una mala solución, pero es lo suficientemente buena.
Dependiendo de la respuesta, tendrá una mejor idea de cómo abordar cada situación y persona. Pueden reconocer rápidamente el problema y descubrir la solución por su cuenta. Pueden pedir ayuda o simplemente intentarán ir y resolverla por su cuenta.
Existen prácticas sugeridas en nuestro negocio, pero casi todas tienen excepciones. Si comprende el proyecto y cómo el equipo lo está abordando, ese puede ser el contexto para determinar el propósito de la revisión del código y cómo abordar las inquietudes.
Me doy cuenta de que esto es más un enfoque del problema que una solución explícita. Habrá demasiada variabilidad para cubrir todas las situaciones.
fuente
Cuando reviso el código, solo proporciono una solución para los problemas que identifico si puedo hacerlo con poco esfuerzo. Sin embargo, trato de ser específico sobre cuál creo que es el problema, refiriéndome a la documentación existente siempre que sea posible. Esperar que un revisor proporcione una solución para cada problema identificado crea un incentivo perverso: desalentará al revisor a señalar problemas.
fuente
Mi opinión es cada vez más fuerte para no proporcionar código en la mayoría de los casos, por varias razones:
Claro, hay algunos casos en los que está pensando en alguna alternativa específica, y vale la pena adjuntarla. Pero eso es realmente raro en mi experiencia. (muchas revisiones, grandes proyectos) El autor original siempre puede pedirle una muestra si es necesario.
Incluso entonces, debido a la tercera razón, al dar una muestra, puede valer la pena decir, por ejemplo, "usar
x.foo()haría esto más simple" en lugar de una solución completa, y dejar que el autor la escriba. Esto también te ahorra tiempo.fuente
Creo que la clave para codificar las revisiones es acordar las reglas antes de la revisión.
Si tiene un conjunto claro de reglas, entonces no debería ser necesario ofrecer una solución. Solo está comprobando que se han seguido las reglas.
La única vez que surgiría la cuestión de una alternativa sería si el desarrollador original no puede pensar en una forma de implementar la característica que se ajuste a las reglas. Supongamos que tiene un requisito de rendimiento, pero la función tarda más que su umbral después de varios intentos de optimización.
¡Sin embargo! si sus reglas son subjetivas "¡Los nombres deben ser aprobados por mí!" entonces, sí, se acaba de nombrar a usted mismo como jefe y debe esperar solicitudes de listas de nombres aceptables.
Su ejemplo de herencia (parámetros opcionales) es quizás mejor, int que he visto reglas de revisión de código que prohíben métodos largos y 'demasiados' parámetros de función. Pero normalmente estos pueden resolverse trivialmente mediante la división. Es la parte de "esta solución parecía complicar demasiado las cosas" donde su objetividad es intrusiva y quizás requiera justificación o una solución alternativa.
fuente
Si una solución potencial es rápida y fácil de escribir, trato de incluirla en mis comentarios de revisión por pares. Si no, al menos enumero mi preocupación y por qué encuentro problemático ese artículo en particular. En el caso de nombres de variables / funciones en los que no se puede pensar en algo mejor, por lo general, reconozco que no tengo una mejor idea y termino el comentario en forma de una pregunta abierta en caso de que alguien pueda . De esa manera, si a nadie se le ocurre una mejor opción, la revisión no se está retrasando.
Para el ejemplo que diste en tu pregunta, con la clase mal diseñada. Dejaría algunos comentarios que, aunque parece que puede ser excesivo, la herencia probablemente sea la mejor manera de abordar el problema que el código está tratando de resolver, y dejarlo así. Trataría de expresar de una manera que indique que no es un show-stopper y depende del criterio del desarrollador si solucionarlo o no. También abriría con un reconocimiento de que no está particularmente familiarizado con esa parte del código, e invitaría a desarrolladores y / o revisores más expertos para que aclaren si hay una razón por la que se hace de la manera en que está.
fuente
Ve y habla con la persona cuyo código estás revisando. Dígales, de manera amigable, que le ha resultado un poco difícil de entender, y luego discuta con ellos cómo podría aclararse.
La comunicación escrita conduce a grandes cantidades de tiempo perdido, así como a resentimientos y malentendidos.
Cara a cara, el ancho de banda es mucho mayor, y uno tiene el canal lateral emocional para prevenir la hostilidad.
Si realmente hablas con el chico, es mucho más rápido, y podrías hacer un nuevo amigo y descubrir que ambos disfrutan más de tu trabajo.
fuente