Después de algunos serios problemas de calidad en el último año, mi compañía recientemente introdujo revisiones de código. El proceso de revisión del código se introdujo rápidamente, sin pautas ni ningún tipo de lista de verificación.

Otro desarrollador y yo elegimos revisar todos los cambios realizados en los sistemas, antes de fusionarlos en el tronco.

También fuimos elegidos como "Líder técnico". Esto significa que somos responsables de la calidad del código, pero no tenemos ninguna autoridad para implementar cambios en el proceso, reasignar desarrolladores o retrasar proyectos.

Técnicamente podemos negar la fusión, devolviéndola al desarrollo. En realidad, esto termina casi siempre con nuestro jefe exigiendo que se envíe a tiempo.

Nuestro gerente es un MBA que se preocupa principalmente por crear un cronograma de los próximos proyectos. Mientras lo intenta, casi no tiene idea de lo que hace nuestro software desde el punto de vista comercial, y está luchando por comprender incluso las demandas más básicas de los clientes sin la explicación de un desarrollador.

Actualmente, el desarrollo se realiza en las sucursales de desarrollo en SVN, después de que el desarrollador cree que está listo, reasigna el ticket en nuestro sistema de tickets a nuestro gerente. El gerente luego nos lo asigna.

Las revisiones del código han generado algunas tensiones dentro de nuestro equipo. Especialmente algunos de los miembros mayores cuestionan los cambios (es decir, "Siempre lo hicimos así" o "¿Por qué el método debe tener un nombre razonable, sé lo que hace?").

Después de las primeras semanas, mi colega comenzó a dejar pasar las cosas, para no causar problemas con los compañeros de trabajo (ella misma me dijo que, después de que un cliente presentara un informe de error, sabía que había un error, pero temía que el el desarrollador estaría enojado con ella por señalarlo).

Yo, por otro lado, ahora soy conocido por ser un imbécil por señalar problemas con el código comprometido.

No creo que mis estándares sean demasiado altos.

Mi lista de verificación en este momento es:

• El código se compilará.
• Hay al menos una forma en que el código funcionará.
• El código funcionará con la mayoría de los casos normales.
• El código funcionará con la mayoría de los casos extremos.
• El código arrojará una excepción razonable si los datos insertados no son válidos.

Pero acepto completamente la responsabilidad de la forma en que doy retroalimentación. Ya estoy dando puntos procesables que explican por qué algo debe cambiarse, a veces incluso solo pregunto por qué algo se implementó de una manera específica. Cuando pienso que es malo, señalo que lo habría desarrollado de otra manera.

Lo que me falta es la capacidad de encontrar algo que señalar como "bueno". Leí que uno debería tratar de emparejar las malas noticias con las buenas.

Pero estoy teniendo dificultades para encontrar algo que sea bueno. "Oye, esta vez realmente cometiste todo lo que hiciste" es más condescendiente que agradable o útil.

Ejemplo de revisión de código

Hola joe

Tengo algunas preguntas sobre sus cambios en la clase Library \ ACME \ ExtractOrderMail.

No entendí por qué marcaste "TempFilesToDelete" como estático. Por el momento, una segunda llamada a "GetMails" arrojaría una excepción, porque usted agrega archivos pero nunca los elimina, después de eliminarlos. Sé que la función solo se llama una vez por ejecución, pero en el futuro esto podría cambiar. ¿Podría simplemente convertirlo en una variable de instancia? Entonces podríamos tener varios objetos en paralelo.

... (Algunos otros puntos que no funcionan)

Puntos menores:

• ¿Por qué "GetErrorMailBody" toma una excepción como parámetro? ¿Me he perdido algo? No está lanzando la excepción, simplemente la pasa y llama "ToString". ¿Porqué es eso?
• SaveAndSend no es un buen nombre para el método. Este método envía correos de error si el procesamiento de un correo salió mal. ¿Podría cambiarle el nombre a "SendErrorMail" o algo similar?
• No solo comente el código antiguo, bórrelo directamente. Todavía lo tenemos en subversión.

¿Cómo encontrar cosas positivas en una revisión de código?

Después de algunos serios problemas de calidad en el último año, mi compañía recientemente introdujo revisiones de código.

Genial, tiene una oportunidad real de crear valor para su empresa.

Después de las primeras semanas, mi colega comenzó a dejar pasar las cosas, para no causar problemas con los compañeros de trabajo (ella misma me dijo, que después de que un cliente presentó un informe de error, ella sabía del error, pero temía que el desarrollador estaría enojado con ella por señalarlo).

Su compañero de trabajo no debería estar revisando el código si no puede decirle a los desarrolladores qué hay de malo en su código. Es su trabajo encontrar problemas y solucionarlos antes de que afecten a los clientes.

Del mismo modo, un desarrollador que intimida a los compañeros de trabajo está pidiendo que lo despidan. Me sentí intimidado después de una revisión de código: se lo dije a mi jefe y lo manejé. Además, me gusta mi trabajo, así que mantuve los comentarios, positivos y negativos. Como revisor, eso depende de mí, no de nadie más.

Yo, por otro lado, ahora soy conocido por ser un imbécil por señalar problemas con el código comprometido.

Bueno, eso es lamentable, dices que estás siendo discreto. Puede encontrar más para alabar, si tiene más que buscar.

Critica el código, no el autor

Da un ejemplo:

Tengo algunas preguntas sobre sus cambios en

Evite usar las palabras "usted" y "su", digamos, "el" cambia en su lugar.

¿Me he perdido algo? [...] ¿Porqué es eso?

No agregue florituras retóricas a sus críticas. No hagas bromas tampoco. Hay una regla que he escuchado: "Si te hace sentir bien decirlo, no lo digas, no es bueno".

Tal vez estás puliendo tu propio ego a expensas de otra persona. Manténgalo solo en los hechos.

Eleve el listón dando comentarios positivos

Eleva el listón para alabar a sus compañeros desarrolladores cuando cumplen con estándares más altos. Entonces eso significa la pregunta,

¿Cómo encontrar cosas positivas en una revisión de código?

es bueno y vale la pena abordarlo.

Puede señalar dónde se encuentra el código con los ideales de las prácticas de codificación de nivel superior.

Búsquelos para que sigan las mejores prácticas y sigan elevando el listón. Después de que se esperen los ideales más fáciles de todos, querrás dejar de elogiarlos y buscar prácticas de codificación aún mejores para alabar.

Mejores prácticas específicas del idioma

Si el lenguaje admite documentación en código, espacios de nombres, funciones de programación orientadas a objetos o funcionales, puede llamarlas y felicitar al autor por usarlas cuando sea apropiado. Estos asuntos generalmente se incluyen en las guías de estilo:

• ¿Cumple con los estándares internos de la guía de estilo de idiomas?
• ¿Cumple con la guía de estilo más autorizada para el idioma (que probablemente sea más estricto que el interno y, por lo tanto, cumpla con el estilo interno)?

Mejores prácticas genéricas

Puede encontrar puntos para elogiar los principios de codificación genéricos, bajo varios paradigmas. Por ejemplo, ¿tienen buenas pruebas unitarias? ¿Las pruebas unitarias cubren la mayor parte del código?

Buscar:

• pruebas unitarias que solo prueban la funcionalidad del sujeto, burlándose de la costosa funcionalidad que no está destinada a ser probada.
• altos niveles de cobertura de código, con pruebas completas de API y funcionalidad semánticamente pública.
• pruebas de aceptación y pruebas de humo que prueban la funcionalidad de extremo a extremo, incluida la funcionalidad que se burla para las pruebas unitarias.
• buen nombre, puntos de datos canónicos, por lo que el código es SECO (no se repita), sin cadenas o números mágicos.
• nombre de variables tan bien hecho que los comentarios son en gran medida redundantes.
• limpiezas, mejoras objetivas (sin compensaciones) y refactorizaciones apropiadas que reducen las líneas de código y la deuda técnica sin hacer que el código sea completamente extraño para los escritores originales.

Programacion Funcional

Si el lenguaje es funcional o admite el paradigma funcional, busque estos ideales:

• evitando el estado global y global
• usando cierres y funciones parciales
• funciones pequeñas con nombres legibles, correctos y descriptivos
• puntos de salida únicos, minimizando el número de argumentos

Programación Orientada a Objetos (OOP)

Si el lenguaje admite OOP, puede alabar el uso apropiado de estas características:

• encapsulación: proporciona una interfaz pública pequeña y bien definida, y oculta los detalles.
• herencia - código reutilizado adecuadamente, tal vez a través de mixins.
• polimorfismo: las interfaces se definen, quizás clases base abstractas, funciones escritas para admitir polimorfismo paramétrico.

bajo OOP, también hay principios SÓLIDOS (tal vez algo de redundancia a las características de OOP):

• responsabilidad única: cada objeto tiene un interesado / propietario
• abierto / cerrado: no modifica la interfaz de los objetos establecidos
• Sustitución de Liskov: las subclases pueden sustituirse por instancias de padres
• segregación de interfaz: interfaces proporcionadas por composición, quizás mixins
• inversión de dependencia - interfaces definidas - polimorfismo ...

Principios de programación de Unix :

Los principios de Unix son modularidad, claridad, composición, separación, simplicidad, parsimonia, transparencia, robustez, representación, menos sorpresa, silencio, reparación, economía, generación, optimización, diversidad y extensibilidad.

En general, estos principios pueden aplicarse bajo muchos paradigmas.

Sus criterios

Estos son demasiado triviales: me sentiría condescendiente si me elogiaran por esto:

• El código se compilará.
• Hay al menos una forma en que el código funcionará.
• El código funcionará con la mayoría de los casos normales.

Por otro lado, estos son elogios bastante altos, considerando lo que parece estar tratando, y no dudaría en elogiar a los desarrolladores por hacer esto:

• El código funcionará con la mayoría de los casos extremos.
• El código arrojará una excepción razonable si los datos insertados no son válidos.

¿Escribir las reglas para pasar la revisión del código?

Sin embargo, esa es una gran idea en teoría, si bien no solía rechazar el código por nombres incorrectos, he visto nombres tan malos que rechazaría el código con instrucciones para solucionarlo. Debe poder rechazar el código por cualquier motivo.

La única regla que se me ocurre para rechazar el código es que no hay nada tan atroz que lo mantenga fuera de producción. Un nombre realmente malo es algo que estaría dispuesto a mantener fuera de producción, pero no puedes hacer que eso sea una regla.

Conclusión

Puede elogiar las mejores prácticas que se siguen bajo múltiples paradigmas, y probablemente bajo todos ellos, si el lenguaje los admite.

No se moleste en elegir algo bueno a menos que sea un ejemplo conciso y sólido y esté directamente relacionado con el tema central.

No lo endulzaré: por lo que parece, estás tratando con al menos una persona que no está segura de sus habilidades y está manejando los desafíos de su trabajo de una manera inmadura. También es probable que sean malos en su trabajo: un buen desarrollador siempre debe estar dispuesto a reflexionar, tomar críticas constructivas y estar abierto a cambiar sus formas.

Ahora que está en el aire, hablemos de ti. Independientemente de si cree que está siendo razonable, debe tener mucho cuidado con personas como esta para que la pelota ruede. He descubierto que la mejor manera de tratar con estas personas es tener mucho cuidado con la forma en que expresas las cosas.

Asegúrese de culpar al código y no al autor . Concéntrese en el único problema en cuestión en lugar de la montaña de poo que es su base de código, que pueden haber tenido una mano importante en la creación y se consideraría como un ataque personal adicional. Elija sus batallas inicialmente, concéntrese en los problemas críticos que se manifiestan a sus usuarios para que no esté lanzando una serie de críticas a la persona que los lleva a descartar todo lo que está diciendo.

El lenguaje corporal y el tono son importantes si les hablas en persona, sé claro con lo que estás diciendo y asegúrate de no hablar con ellos o descartar sus habilidades técnicas. Es muy probable que estén a la defensiva desde el principio, por lo que debe resolver sus preocupaciones en lugar de confirmarlas. Debes ser consciente de esta conversación sin ser demasiado obvio para que ellos subconscientemente piensen que estás de su lado, y esperemos que acepten que necesitan hacer los cambios que se hicieron notar.

Si esto no funciona, puede comenzar a ser un poco más agresivo. Si el producto se puede ejecutar desde una sala de conferencias, créelo en el proyector durante la revisión del código y muestre el error de primera mano, es mejor si un gerente está allí para que la persona no pueda retroceder. Esto no es para avergonzarlos, sino para obligarlos a aceptar que el problema es real para el usuario y que necesita ser solucionado, en lugar de solo una queja que tenga con su código.

Eventualmente, si no llega a ningún lado, está cansado de tratar a la persona como un estudiante de jardín de infantes, y la gerencia no es consciente del problema, y ​​esto refleja mal su desempeño como revisor de códigos o le importa el bienestar de su persona. empresa y / o producto, debe comenzar a hablar con su jefe sobre su comportamiento. Sea lo más específico e impersonal posible: haga un caso de negocios que la productividad y la calidad están sufriendo.

Las revisiones de código pueden ser tóxicas, perder el tiempo y la voluntad de minar guerras nerd. Simplemente observe la divergencia de opiniones sobre cosas como código limpio frente a comentarios, convenciones de nomenclatura, pruebas de unidad e integración, estrategias de verificación, RESTfulness, etc., etc.

La única forma de asegurarse de evitar esto es escribir las reglas para aprobar una revisión de código.

Entonces no es una persona la que falla o aprueba el registro. Simplemente están comprobando que se han seguido las reglas.

Y debido a que están escritos de antemano, cuando escribe su código puede seguir las reglas y no tener que explicar su razonamiento o tener argumentos más adelante.

Si no le gustan las reglas, tenga una reunión para cambiarlas.

No endulzaría sus comentarios porque puede considerarse como condescendiente.

En mi opinión, la mejor práctica es centrarse siempre en el código y nunca en el autor.

Es una revisión de código , no una revisión de desarrollador , así que:

• "Este ciclo while puede que nunca termine", no "Su ciclo puede que nunca termine"
• "Se necesita un caso de prueba para el escenario X", no "No escribió la prueba para cubrir este escenario"

También es muy importante aplicar la misma regla al hablar sobre la revisión con otros:

• "Anne, ¿qué opinas sobre este código?", No "Anne, ¿qué opinas sobre el código de Jon?"

La revisión de código no es el momento para una revisión de desempeño, debe hacerse por separado.

Me sorprende que no se haya mencionado en ninguna respuesta hasta ahora, y tal vez mi experiencia con las revisiones de código es inusual, pero:

¿Por qué está revisando toda la solicitud de fusión en un solo mensaje?

Mi experiencia con las revisiones de código es a través de GitLab; Siempre imaginé que otras herramientas de revisión de código funcionarían de manera similar.

Cuando doy una revisión de código, comento líneas específicas e individuales de la diferencia. Es muy poco probable que esto se reciba como crítica personal, porque es un comentario sobre el código, y en realidad se muestra como comentario sobre el código, que se muestra directamente debajo del código sobre el que es un comentario.

Puedo también observaciones sobre toda la petición de fusión, ya menudo lo hacen. Pero se pueden señalar puntos específicos en líneas específicas de la diferencia. (Además, cuando se agrega una nueva confirmación de modo que la diferencia cambia, los comentarios sobre la "diferencia obsoleta" se ocultan de forma predeterminada).

Con este flujo de trabajo, las revisiones de código se vuelven mucho más modulares y menos cohesivas. Una línea de una revisión de código simplemente puede decir:

Buen enfoque, envolviendo esto en una función dedicada!

O podría decir:

Este nombre de objeto realmente no coincide con el propósito del objeto; tal vez podríamos usar un nombre como 'XYZ' en su lugar?

O si hay problemas importantes con una sección, podría escribir:

Veo que este código funciona (y veo por qué funciona) pero requiere un estudio enfocado para entenderlo. ¿Podría refactorizarlo en funciones separadas para que sea más fácil de mantener en el futuro?

(Ejemplo: la función ABC en realidad está haciendo tres cosas aquí: desconcertar al foo, prohibir el boz y frotar el zorf. Todas podrían ser funciones separadas).

Después de escribir todo lo anterior, puedo hacer un comentario resumido sobre toda la solicitud de fusión, algo como:

Esta es una gran característica nueva y será realmente útil una vez fusionada. ¿Puede por favor limpiar el nombre de la función y manejar la refactorización mencionada en los comentarios individuales que he hecho, y luego hágamelo saber para verla nuevamente? :)

Incluso si la solicitud de combinación es un desayuno completo para perros, los comentarios individuales pueden ser simples. Solo habrá más de ellos. Entonces el comentario resumido podría decir:

Lo siento, pero este código no está realmente a la altura. Hay muchos casos extremos (como se detalla en los comentarios individuales) que se manejarán incorrectamente y darán una mala experiencia al usuario, o incluso corrupción de datos en un caso. (Vea el comentario en commit 438a95fb734.) Incluso algunos casos de uso normal resultarán en un rendimiento extremadamente malo de la aplicación (detalles específicos en comentarios individuales en el diff para somefile.c).

Para estar listo para la producción, esta característica necesitará una reescritura completa con más atención dada a los supuestos que son seguros de hacer en cada punto del flujo. (Sugerencia: ninguna suposición es segura a menos que se haya verificado).

Estoy cerrando la solicitud de fusión a la espera de una reescritura completa.

Resumen: revise los aspectos técnicos del código como comentarios en líneas de código individuales. Luego resuma esos comentarios en un comentario general sobre la solicitud de fusión. No se vuelva personal, solo trate los hechos y, en su opinión, sobre el código , no sobre el codificador. Y base su opinión en hechos, observación precisa y comprensión.

Estoy realmente sorprendido de que nadie haya captado eso, pero hay algo mal con la revisión de muestra publicada.

Simplemente no hay ninguna razón por la que deba dirigirse directamente a Joe. Que Joe arregle sus fallas no es asunto tuyo. Que alguien lo haga, es asunto tuyo. Su preocupación es la calidad del código. Entonces, en lugar de escribir solicitudes / pedidos / demandas (que, si yo fuera Joe, podría simplemente rechazar porque no eres legítimo para esto), mantente en tu rol y escribe una lista simple de tareas anónimas.

Tratar de ser justo al dar puntos buenos y malos no solo es imposible, sino que está completamente fuera de su rol.

Aquí hay un ejemplo de reformulación con contenido tomado de su revisión:

• Antes de extraer los cambios en la clase Library \ ACME \ ExtractOrderMail, necesitamos solucionar algunos problemas.
• A menos que me haya perdido algo, "TempFilesToDelete" no debería ser estático.
• En el futuro, podemos llamar a la función más de una vez por ejecución, es por eso que necesitamos (lo que se debe hacer aquí).
• Necesito entender por qué "GetErrorMailBody" toma una excepción como parámetro. (y, estoy siendo límite aquí, porque a estas alturas, ya deberías tener una conclusión )
• Se debe cambiar el nombre de SaveAndSend para que se ajuste mejor a su comportamiento, como por ejemplo "SendErrorMail"
• El código comentado debe eliminarse para facilitar la lectura. Utilizamos subversion para eventuales retrocesos.

Si formula la revisión de esta manera, no importa cuánto lo odie el lector personalmente, todo lo que puede ver aquí son notas sobre las mejoras que alguien tiene que continuar más adelante. Quien ? Cuando ? A nadie le importa. Qué ? Por qué ? Eso deberías decir.

Ahora, abordará la razón por la cual las revisiones de códigos están aumentando la tensión al eliminar el factor humano de la ecuación.

El objetivo de la revisión del código es encontrar problemas. Si hay algún error, lo mejor que puede hacer es escribir un caso de prueba que esté fallando.

Su equipo (gerente) debe comunicar que la producción de errores es parte del juego, pero encontrarlos y solucionarlos salvará el trabajo de todos .

Puede ser útil tener reuniones regulares (ya sea en equipo o en pareja) y analizar algunos de los problemas. El programador original no introdujo problemas intencionalmente, y a veces podría pensar que era lo suficientemente bueno (y a veces incluso podría serlo). Pero tener ese segundo par de ojos ofrece una visión completamente nueva, y podría aprender mucho al observar los problemas.

Realmente es algo cultural, y necesita mucha confianza y comunicación. Y es hora de trabajar con los resultados.

Creo que lo positivo sería lograr un consenso sobre los estándares de codificación antes de hacer las revisiones. Otros tienden a comprar más a algo cuando tienen aportes.

Para algo como las convenciones de nomenclatura, pregunte a otros si esto es importante. La mayoría de los desarrolladores estarán de acuerdo especialmente entre sus pares. ¿Quién quiere ser la persona que no quiere estar de acuerdo con algo tan frecuente en el mundo de la programación? Cuando comienzas el proceso eligiendo el código de alguien y señalando la falla, se ponen muy a la defensiva. Cuando se establezcan los estándares, habrá desacuerdos sobre la interpretación o sobre lo que se considera "suficientemente bueno", pero está mejor de lo que está ahora.

Otra parte de este proceso es determinar cómo las revisiones de código manejarán las objeciones. Esto no puede convertirse en un debate interminable. En algún momento, alguien tiene que tomar la decisión. Tal vez pueda haber un tercero para ser el juez o el revisor obtenga todo el poder. Las cosas que hay que hacer deben ser el objetivo.

La parte final de esto es hacerles saber a todos que las Revisiones de Código no fueron idea suya, que se quedarán, por lo que todos deberían hacer un esfuerzo para aprovecharlo al máximo. Si todos se sienten impotentes, ¿tal vez se les permita revisar su código?

Con suerte, algún resultado medible para la administración es limitar los errores, las quejas de los clientes, los retrasos, etc. De lo contrario, alguien acaba de escuchar la palabra clave "revisión del código" y se dio cuenta de que si la agregan a su proceso, ocurrirán milagros sin mucho tiempo y energía. y esfuerzo puesto en esto.

Esto puede ser duro, pero no se preocupe por dar buenos comentarios si no hay nada bueno para medir.

Sin embargo, en el futuro, a medida que sus desarrolladores comiencen a mejorar su código, es cuando querrá darles buenos comentarios. Querrá señalar las mejoras en el código, y también querrá señalar los beneficios para el equipo en su conjunto. Cuando comience a ver una mejora, también lo harán, y las cosas deberían comenzar a cambiar lentamente.

Otra cosa; puede haber un aire defensivo porque sienten que no tienen voz. ¿Por qué no dejar que revisen el código del otro? Hágales preguntas específicas e intente involucrarlas. No deberías ser tú contra ellos; Debería ser un esfuerzo de equipo.

1. ¿Qué cambiarías de este código si tuvieras tiempo?
2. ¿Cómo mejorarías esta área de la base de código?

Pregunta eso ahora, y pregunta eso dentro de seis meses. Hay una experiencia de aprendizaje aquí.

El punto principal: no elogie en términos de código donde no está garantizado, pero reconozca el esfuerzo y definitivamente reconozca la mejora. Trate de hacer que las revisiones sean un ejercicio de equipo en lugar de uno adversario.

Calidad sin tensión

Ha preguntado cómo puede encontrar cosas positivas que decir sobre el código, pero su verdadera pregunta es cómo puede evitar las "tensiones dentro de [su] equipo" al tiempo que aborda los "problemas de calidad graves".

El viejo truco de emparedar "malas noticias en buenas noticias" puede ser contraproducente. Es probable que los desarrolladores lo vean por lo que es: una invención.

Los problemas de arriba hacia abajo de su organización

Sus jefes le encargaron garantizar la calidad. Se le ocurrió una lista de criterios para la calidad del código. Ahora, desea ideas para el refuerzo positivo para proporcionar a su equipo.

¿Por qué preguntarnos qué necesita hacer para que su equipo sea feliz? ¿Has considerado preguntarle a tu equipo?

Parece que estás haciendo todo lo posible para ser amable. El problema no es cómo está entregando su mensaje. El problema es que la comunicación ha sido unidireccional.

Construyendo una cultura de calidad

Hay que cultivar una cultura de calidad para crecer de abajo hacia arriba.

Hágale saber a su jefe que le preocupa que la calidad no mejore lo suficientemente rápido y que desee intentar aplicar algunos consejos de The Harvard Business Review .

Reúnase con su equipo. Modele los comportamientos que desea ver en su equipo: humildad, respeto y un compromiso para mejorar.

Diga algo como: “Como saben, [compañero de trabajo] y yo tuvimos la tarea de garantizar la calidad del código, para evitar el tipo de problemas de producción que hemos sufrido recientemente. Personalmente, no creo que haya resuelto este problema. Creo que mi mayor error fue no involucrarlos a todos ustedes al principio. [compañero de trabajo] y yo todavía somos responsables ante la gerencia por la calidad del código, pero en el futuro, todos estamos en el esfuerzo de calidad juntos ”.

Obtenga ideas del equipo sobre la calidad del código. (Una pizarra podría ayudar). Asegúrese de que sus requisitos lleguen al final. Ofrezca sus ideas de manera respetuosa y haga preguntas cuando sea apropiado. Esté dispuesto a sorprenderse de lo que su equipo siente que es importante Sea flexible, sin comprometer las necesidades comerciales.

(Si tiene algún código antiguo que le avergüence, podría sacarlo, alentando a todos a ser sinceros. Al final, hágales saber a la gente que lo escribió. Modele la reacción madura que espera cuando otros reciben críticas de construcción. )

Revisiones de código colaborativo

No he trabajado en un lugar como el que usted describe, donde algunos programadores senior revisan todo el código y hacen correcciones. No es de extrañar que la gente responda como si fuera un maestro haciendo marcas rojas en sus papeles.

Si puede vender la idea a la gerencia, comience a hacer revisiones de código de pares . Esto se hace mejor en grupos pequeños, incluido usted u otro desarrollador responsable. Asegúrese de que todos sean tratados con respeto.

Un objetivo importante de la revisión por pares del código es garantizar que todos los miembros del equipo puedan entender el código. Considere su ejemplo de nombres de funciones poco claros: escuchar a un desarrollador más joven que encuentra que el nombre de la función es confuso puede ser más fácil de aceptar que otra "corrección" del desarrollador senior.

La calidad es un viaje

Otra cosa que hay que hacer es eliminar cualquier noción de que una revisión de código es una cosa de pasar / fallar. Todos deberían esperar hacer algunas ediciones después de una revisión de código. (Y su trabajo es garantizar que sucedan).

Pero si eso no funciona ...

Supongamos que hace algunos avances estableciendo una cultura de calidad. Es posible que todavía no consigas a todos a bordo. Si alguien todavía no está con el programa de calidad, ahora el problema es que no están encajando con el equipo, en lugar de que haya un problema entre ustedes dos. Si necesitan ser despedidos del equipo, el resto del equipo comprenderá mejor los motivos.

Lo siento por otra respuesta larga, pero no creo que los demás hayan abordado completamente el elemento humano de este problema.

a veces incluso solo preguntando por qué algo se implementó de una manera específica. Cuando pienso que es malo, señalo que lo habría desarrollado de otra manera.

El problema con "¿Por qué lo implementaste de esta manera?" es que pones al desarrollador inmediatamente a la defensiva. La pregunta en sí misma puede implicar todo tipo de cosas según el contexto: ¿Eres demasiado estúpido para pensar en una mejor solución? ¿Es esto lo mejor que puedes hacer? ¿Estás tratando de arruinar este proyecto? ¿Te importa la calidad de tu trabajo? etc. Preguntar "por qué" el código fue desarrollado de cierta manera solo será confrontativo, y eso subvierte cualquier intento pedagógico que tu comentario haya tenido.

Del mismo modo, "Habría hecho esto de manera diferente ..." también es confrontativo, porque el pensamiento inmediato que tendrá el desarrollador es " Bueno, lo hice de esta manera ... ¿Tienes un problema con eso? " Y de nuevo, es más confrontacional que tiene que serlo y aleja la discusión de mejorar el código.

Ejemplo:

En lugar de preguntar "¿Por qué elegiste no usar la variable constante para este valor?", Simplemente di "Este valor codificado debe ser reemplazado por la constante XYZen el archivo Constants.h" Hacer la pregunta sugiere que el desarrollador eligió activamente no usar constante ya definida, pero es muy posible que ni siquiera supieran que existía. Con una base de código lo suficientemente grande, habrá muchas cosas que cada desarrollador no sabe. Esta es simplemente una buena oportunidad de aprendizaje para que el desarrollador se familiarice con las constantes del proyecto.

Hay una línea muy fina para caminar con las revisiones de código: no necesita endulzar todo lo que dice, no necesita intercalar malas noticias con buenas noticias, y no necesita suavizar el golpe. Podría ser la cultura en la que estoy, pero mis compañeros de trabajo y yo nunca nos felicitamos mutuamente en las revisiones de códigos: las partes del código que desarrollamos que están libres de defectos son un cumplido suficiente. Lo que debe hacer es identificar el defecto que ve y quizás dar una razón por la cual (el por qué es menos útil cuando es obvio / simple).

Bueno:

• "El nombre de esta variable debe cambiarse para que coincida con nuestro estándar de codificación".

• "La 'b' en el nombre de esta función debe estar en mayúscula para ser PascalCase".

• "El código de esta función no está sangrado correctamente".

• "Este código es un duplicado del código encontrado en ABC::XYZ(), y debería usar esa función en su lugar".

• "Debería usar try-with-resources para garantizar que las cosas se cierren correctamente en esta función, incluso si se producen errores". [Solo agregué un enlace aquí para que los usuarios que no son de Java sepan lo que significa probar con recursos]

• "Esta función necesita ser refactorizada para cumplir con nuestros estándares de complejidad n-path".

Malo:

• " Creo que podría mejorar este código cambiando el nombre de la variable para que coincida con nuestro estándar"

• " Quizás sería mejor usar try-with-resource para cerrar correctamente las cosas en esta función"

• " Podría ser deseable echar un vistazo a todas las condiciones de esta función. Su complejidad de N-path está por encima de la complejidad máxima permitida de nuestro estándar".

• "¿Por qué las sangrías aquí son 2 espacios en lugar de las 4 de nuestro estándar?"

• "¿Por qué escribiste una función que rompe nuestro estándar de complejidad n-path?"

En las malas declaraciones, las partes en cursiva son cosas que las personas usan comúnmente cuando quieren suavizar el golpe, pero todo lo que realmente hace en una revisión de código es hacerte sonar inseguro de ti mismo. Si usted, el revisor, no está seguro de cómo mejorar el código, ¿por qué alguien debería escucharlo?

Las declaraciones 'buenas' son contundentes, pero no acusan al desarrollador, no atacan al desarrollador, no son confrontativas y no cuestionan por qué existe el defecto. Existe; Aquí está la solución. Ciertamente, no son tan conflictivos como la última pregunta de "por qué".

El problema que ves es: los desarrolladores no están contentos de que su código sea criticado. Pero ese no es el problema. El problema es que su código no es bueno (suponiendo obviamente que las revisiones de su código son buenas).

Si a los desarrolladores no les gusta que su código atraiga críticas, entonces la solución es fácil: escribir un código mejor. Usted dice que tuvo serios problemas con la calidad del código; eso significa que se necesita un mejor código.

"¿Por qué el método debe tener un nombre razonable, sé lo que hace?" es algo que encuentro particularmente inquietante. Él sabe lo que hace, o al menos lo dice, pero yo no. Cualquier método no solo debe tener un nombre sensible, debe tener un nombre que deje en claro inmediatamente al lector del código lo que hace. Es posible que desee ir al sitio web de Apple y buscar un video WWDC sobre los cambios de Swift 2 a Swift 3, una gran cantidad de cambios realizados solo para que todo sea más legible. Tal vez ese tipo de video podría convencer a sus desarrolladores de que los desarrolladores que son mucho más inteligentes que ellos encuentran que los nombres de métodos intuitivos son muy, muy importantes.

Otro elemento perturbador fue su colega que dijo "ella misma me dijo que, después de que un cliente presentara un informe de error, que sabía del error, pero temía que el desarrollador se enojara con ella por señalarlo". Existe la posibilidad de que haya algún malentendido, pero si un desarrollador se enoja si le señala un error, eso es malo.

Respetuosamente estoy en desacuerdo con el método de revisión de código que ha descrito. Dos empleados que entran en una "sala cerrada" y salen con críticas institucionalizan el tipo de noción de confrontación que las buenas revisiones de código deberían evitar .

Hacer que la revisión del código sea una experiencia positiva en la medida de lo posible es esencial para que tenga éxito. El primer paso es eliminar la noción adversaria de revisión. Que sea un evento grupal semanal o quincenal ; asegúrese de que todos sepan que son bienvenidos a participar. Pide pizza o sándwiches o lo que sea. Ni siquiera lo llames 'revisión de código' si eso suscita connotaciones negativas. Encuentre algo para celebrar, para alentar, para compartir, incluso si no es más que progresar a través del sprint o iteración actual. Túrnense para asignar liderazgo sobre la revisión.

Haga que el proceso sea un esfuerzo para servir al producto y a las personas. Si se realizan de manera constructiva y positiva, en donde se comparten y fomentan buenas técnicas o patrones, así como se desalienta a los pobres, todos se benefician. Todos reciben entrenamiento en público. Si tiene un programador problemático que no lo "entiende", debe abordarlo de forma privada y por separado, nunca frente al grupo más amplio. Eso está separado de la revisión de código.

Si tiene problemas para encontrar algo "bueno" que plantear, eso me plantea una pregunta: si se está progresando en el proyecto y la gente está trabajando, ese progreso en sí mismo es algo para celebrar. Si realmente no encuentra nada bueno, eso implica todo lo que se ha hecho ya que la última revisión es mala o no es mejor que neutral . ¿Es realmente el caso?

En cuanto a los detalles, los estándares comunes son esenciales. Dele a todos una participación en lo que se está haciendo. Y permita que se integren técnicas nuevas y mejores en su base de código. El hecho de no hacer eso garantiza que los viejos hábitos nunca se eliminen bajo el disfraz de "siempre lo hemos hecho así".

El punto en todo esto es que las revisiones de código tienen un poco de mala reputación porque están mal implementadas, se usan como martillos para menospreciar a los programadores menos experimentados o menos calificados, y eso no sirve a nadie. Tampoco es probable que los gerentes que los usan de esta manera sean gerentes muy efectivos. Las buenas revisiones de códigos en las que todos son participantes sirven a todos: el producto, los empleados y la empresa.

Disculpas por la duración de la publicación, pero después de haber estado en un grupo donde la revisión del código se ignoró en gran medida, condujo a un legado de código que no se puede mantener y solo a un rango limitado de desarrolladores que pueden, incluso si se les permite realizar cambios en una base de código de años. Era un camino que optaría por no recorrer de nuevo.

La paradoja del buen código es que no se destaca en absoluto y parece que fue muy sencillo y fácil de escribir. Realmente me gusta el ejemplo del jugador de billar de esta respuesta . En las revisiones de código, eso hace que sea muy fácil pasar por alto, a menos que sea un refactor de código incorrecto.

Hago un punto para buscarlo. Si estoy revisando el código y he revisado un archivo que era tan fácil de leer que parece engañosamente fácil de escribir, solo agrego un rápido "Me gusta cómo los métodos aquí son cortos y limpios" o lo que sea apropiado .

Además, debe liderar con el ejemplo. Debe insistir en que también se revise su código, y debe modelar cómo desea que se comporte su equipo cuando reciba la corrección. Lo más importante, debe agradecer sinceramente a las personas por los comentarios. Esto hace más diferencia que cualquier comentario unilateral que pueda dar.

Parece que el verdadero problema es que solo son dos personas las que están haciendo todas las revisiones de código, de las cuales solo tú las tomas en serio, lo que te ha llevado a una situación desafortunada con mucha responsabilidad y mucha responsabilidad. presión de los otros miembros del equipo.

Una mejor manera sería distribuir la responsabilidad de hacer las revisiones de código sobre el equipo, y hacer que todos participen en hacerlas, por ejemplo, dejando que los desarrolladores elijan a quién revisar su código. Esto es algo que su herramienta de revisión de código debería admitir.

He visto que esto sucede de primera mano y quiero advertirle que se aleje de las respuestas desafiadas de inteligencia emocional : pueden matar equipos enteros. A menos que desee reclutar, capacitar y normalizar nuevos desarrolladores cada año, es esencial crear una relación positiva con sus compañeros. Después de todo, ¿no tiene sentido hacer estas revisiones para mejorar la calidad del código y fomentar una cultura en la que la calidad del código sea mayor en primer lugar? Yo diría que es parte de su trabajo proporcionar refuerzo positivo como un medio para integrar este sistema de revisión de código en la cultura del equipo.

De todos modos, parece que necesita revisar su sistema de Revisión de Código. En este momento, por lo que parece, todo en su proceso de revisión es, o puede interpretarse como, subjetivo en lugar de objetivo. Es fácil sentirse herido cuando se siente como si alguien simplemente estuviera desarmando su código porque no les gusta, en lugar de tener una razón por la que pueden citar cuando algo no cumple con las pautas. De esta manera, es fácil rastrear y 'celebrar' las mejoras positivas en la calidad del código (con respecto a su sistema de revisión) de cualquier manera que sea apropiada para la cultura de su oficina.

Los líderes técnicos deben reunirse fuera de una sesión de revisión y presentar una guía de codificación / lista de verificación de revisión de código y deben cumplirse y consultarse durante la revisión. Este debería ser un documento vivo que se pueda actualizar y refinar a medida que se desarrolle el proceso. Estas reuniones de Tech Lead también deberían ser cuando la discusión 'La forma en que siempre hemos hecho las cosas' versus las 'Nuevas y mejoradas formas de hacer las cosas' debería ocurrir, sin que el desarrollador sea revisado sintiendo que el desacuerdo es el resultado de su código. Una vez que la directriz inicial se ha suavizado más o menos, otra forma de reforzar positivamente a los desarrolladores es solicitar sus comentarios y luego tomar medidas al respecto. y evolucionando el proceso como un equipo, esto hace maravillas para ponerlos al día para comenzar a revisar el código de a bordo para que no se quede atrapado haciendo revisiones hasta que también se retire.

Local...

Los programadores son solucionadores de problemas. Estamos condicionados a comenzar a depurar cuando se nos presenta un problema o error.

El código es un medio de formato de esquema. Cambiar a una narrativa en formato de párrafo para recibir comentarios introduce una desconexión que debe traducirse. Inevitablemente, algo se pierde o se malinterpreta. Inevitablemente, el revisor no está hablando en el lenguaje del programador.

Los mensajes de error generados por computadora rara vez se cuestionan y nunca se toman como una afrenta personal.

Los elementos de revisión de código son mensajes de error generados por humanos. Su objetivo es captar los casos límite que los programadores y las herramientas automatizadas pierden, así como los inevitables efectos secundarios en otros programas y datos.

Conclusiones ...

Por lo tanto, cuanto más elementos de revisión de código se puedan incorporar a las herramientas automatizadas, mejor se recibirán.

La advertencia es que, para permanecer incuestionable, dichas herramientas deben actualizarse continuamente, generalmente a diario o semanalmente, para cumplir con cada cambio en los procedimientos, estándares y prácticas. Cuando un gerente o equipo de desarrolladores decide hacer un cambio, se deben cambiar las herramientas para hacer cumplir eso. Gran parte del trabajo del revisor de códigos se convierte en mantener las reglas en las herramientas.

Ejemplo de comentarios de revisión de código ...

Una reescritura del ejemplo dado que incorpora estas técnicas:

• Tema:

  • Biblioteca \ ACME \ Clase ExtractOrderMail.

• Tema principal ...

  • TempFilesToDelete es estático
    • Las llamadas posteriores a GetMails arrojan una excepción ya que los archivos se agregan pero nunca se eliminan después de la eliminación. Aunque solo una llamada ahora, el rendimiento podría mejorarse en el futuro con cierto paralelismo.
    • TempFilesToDelete como variable de instancia permitiría que varios objetos se usen en paralelo.
• Problemas secundarios ...
  • GetErrorMailBody tiene un parámetro de excepción
    • Dado que no arroja una excepción en sí misma, y ​​solo pasa esto a ToString, ¿es necesario?
  • Guardar y enviar nombre
    • El correo electrónico puede o no usarse para informar esto en el futuro y este código contiene la lógica general para almacenar una copia persistente e informar cualquier error. Un nombre más genérico permitiría dichos cambios anticipados sin cambiar los métodos dependientes. Una posibilidad es StoreAndReport.
  • Comentando código viejo
    • Dejar una línea comentada y marcada OBSOLETO puede ser muy útil para la depuración, pero un "muro de comentarios" también puede ocultar errores en el código adyacente. Todavía lo tenemos en Subversion. ¿Quizás solo un comentario que hace referencia exactamente a dónde en Subversion?

Si no tiene nada bueno que decir sobre el código existente (que suena comprensible), intente involucrar al desarrollador para mejorarlo.

En un parche para un cambio funcional o corrección de errores, no es útil tener otros cambios (cambio de nombre, refactorización, lo que sea), agrupados en el mismo parche. Debe realizar el cambio que corrige el error o agrega la función, nada más.

Cuando se indiquen cambios de nombre, refactorización y otros cambios , hágalo en un parche separado, antes o después.

• Esto es bastante feo, pero supongo que es consistente con todos nuestros otros códigos desagradables. Vamos a limpiar eso más tarde (en un parche, idealmente, sin cambios funcionales).

  También ayuda si se une a la refactorización y les permite revisar su código. Te da la oportunidad de decir por qué crees que algo es bueno, en lugar de malo, y también mostrar un ejemplo de tomar bien la crítica constructiva.

Si necesita agregar pruebas unitarias a una nueva característica, está bien, van en el parche principal. Pero si está reparando un error, las pruebas deben realizarse en un parche anterior y no aprobarse para que pueda demostrar que la solución realmente solucionó el error.

Idealmente, el plan (sobre cómo puede probar una solución, o qué refactorizar y cuándo) debe discutirse antes de que se realice el trabajo, para que no hayan invertido una gran cantidad de esfuerzo en algo antes de descubrir que tiene un problema con él.

Si encuentra que el código no hace frente a las entradas que cree que debería, también puede ser una falta de coincidencia en lo que el desarrollador ve como entrada razonable. Acuerde eso de antemano también, si es posible. Al menos, discuta sobre lo que debería ser capaz de hacer frente y cuán desagradablemente se puede permitir que falle.

Creo que es un error suponer que existe una solución técnica o fácil para: "mis compañeros de trabajo se molestan cuando juzgo su trabajo según mis estándares y tienen cierto poder para imponerlo".

Recuerde que las revisiones de código no son solo una discusión de lo que es bueno o malo. Son implícitamente un "quién es el palo de jardín que estamos usando", un "quién toma la decisión" y, por lo tanto, lo más insidioso, un rango.

Si no aborda esos puntos, hacer revisiones de código de una manera que no tenga los problemas que encuentre será difícil. Aquí hay algunos buenos consejos sobre cómo hacerlo, pero te has propuesto una tarea difícil.

Si tiene razón, sin margen de maniobra, señalarlo es un ataque: alguien se equivocó. Si no: tu otro MBA que no lo entiende. De cualquier manera, vas a ser el malo.

Sin embargo, si lo que busca la revisión y por qué , es claro y acordado, tiene una posibilidad decente de no ser el malo. No eres el guardián, solo un corrector de pruebas. Obtener este acuerdo es un problema difícil de resolver [1]. Me gustaría darte un consejo, pero aún no lo he entendido ...

[1] No se resuelve solo porque la gente ha dicho "ok" o ha dejado de pelear por eso. Nadie quiere ser el tipo que diga X simplemente no es práctico para nuestra {inteligencia, experiencia, mano de obra, plazos, etc.}, pero eso no significa cuando se trata de una instancia específica de hacer X ...

Las revisiones de código deben ser mutuas. Todos criticaron a todos. Deje que el lema sea "No te enojes, desquitate". Todo el mundo comete errores y una vez que las personas le hayan dicho a un tiro caliente cómo corregir su código, entenderán que esto es solo el procedimiento normal y no un ataque contra ellos.

Ver el código de otras personas es educativo. ¡Comprender el código hasta el punto en que pueda señalar su punto débil y tener que explicar que la debilidad puede enseñarle mucho!

Hay poco espacio para elogios en una revisión de código, ya que el objetivo es encontrar fallas. Sin embargo, puedes acumular elogios en las soluciones . Tanto la puntualidad como la pulcritud pueden ser alabados.