Respuesta corta
¿Debo arreglar el código yo mismo?
No.
¿Debo darles comentarios sobre el proceso de revisión y dejar que hagan las correcciones de acuerdo con mis instrucciones?
Si. Según sus sugerencias , no instrucciones . Las instrucciones suenan demasiado autoritarias.
Y si es así, ¿cómo doy esta retroalimentación? ¿Rellene ciertos documentos de plantilla y se los envíe, o hay algún software que me ayudará a marcar las cosas con problemas dentro de los archivos de código donde luego pueden verificarlo? (Estoy usando Visual Studio).
Use una herramienta para dar su opinión. Puedes usar Visual Studio.
Respuesta larga
Solía usar Visual Studio, pero constantemente tenía que preguntarle a otros desarrolladores: "Hey, ¿pueden enviarme su trabajo para que pueda revisarlo?" Eso no me gustó y nunca funcionó realmente bien. Ahora, uso el Asistente de revisión porque puedo comenzar una revisión mirando los registros. No necesito confiar en que otro desarrollador me envíe trabajo para revisar. También me ayuda a marcar elementos como defectos, o simplemente marcar elementos para que el autor los vea. Esto funciona para nuestro equipo porque una vez que comenzamos una revisión, permanece en el tablero de revisión y no se pierde en la traducción. Esto está integrado con Visual Studio. Como mencioné, Visual Studio también tiene su proceso de revisión nativo, pero creo que tiene limitaciones y el proceso no es natural; por lo tanto, uso Review Assistant.
Esta herramienta también ayuda con el proceso de ida y vuelta, discusiones, etc.
El proceso, más o menos, es el siguiente:
Reviso algo, luego se lo envío al autor (en su caso, junior dev). Hacen cambios y luego lo envían de vuelta. Miro los cambios y hago comentarios. Si estoy de acuerdo con los cambios, cierro la revisión. De lo contrario, va y viene. A veces, si hay demasiado de un lado a otro, simplemente me acerco a su escritorio y uso una pizarra, realmente agiliza el proceso.
Las revisiones de código son un área sensible, así que tenga mucho cuidado con la elección de la redacción. Nunca le digo a nadie
Mala elección de la redacción
Revisé su código y hay algunos elementos que debe cambiar.
En cambio digo esto:
Mejor elección de redacción
Miré tu código y necesito ayuda. ¿Puede revisar los artículos que le envié y ver si puede aclarar algunas de mis preguntas?
Esto hace que el autor piense:
- Necesito ayuda para que no entren en modo defensivo.
- Parece que ellos son los revisores, no yo. Técnicamente hablando, ya que les pido que echen otro vistazo y cambien algunas cosas, son como el revisor.
Estas simples elecciones de palabras me han ayudado enormemente.
Nunca subestimo a los desarrolladores junior. He trabajado con algunos desarrolladores senior (más de 10 años de experiencia) y el código fue peor que un estudiante cooperativo junior. Entonces, el hecho de que sean senior o junior no es tan importante; su trabajo es realmente lo que habla más que años de experiencia.
A menudo, para alentar a los desarrolladores junior y hacer que participen en las revisiones, les enviaré algo para que revisen por mí: algo que puedan descubrir, algo que encontrarán desafiante pero no totalmente más allá de ellos. Puedo decirlo como a continuación:
¿Puede por favor revisar algún código para mí porque no puedo resolverlo?
Esto me ayuda mucho de nuevo. Esto ayuda porque muestra claramente que no soy el único que revisa, sino que también hacen revisiones y también son parte del proceso. Muestra que la idea es producir un código bueno y limpio y pedir ayuda si es necesario. El proceso de revisión es una cultura, por lo que realmente necesitamos trabajar en ello.
Ahora, algunas personas pueden preocuparse de que si hacen lo anterior, los desarrolladores junior perderán respeto porque simplemente hicieron algo que usted no pudo hacer. Pero eso está lejos de la verdad: pedir ayuda muestra humildad. Además, hay muchas situaciones en las que puedes brillar. Finalmente, si ese es su miedo, tiene problemas de autoestima. Por último, tal vez realmente no lo sé: quiero decir que algunos de estos desarrolladores tienen algoritmos frescos en su cabeza porque los estudiaron hace un mes.
De todos modos, de vuelta a juniors y reseñas. Deberías ver la expresión de sus caras cuando lo descubran y me envíen una respuesta. Entonces puedo decirles: "OK, déjenme hacer los cambios y si están contentos con esto, cierren el problema".
Se sienten increíbles al tener el poder de mirar mi trabajo y decir: "Sí, sus cambios son buenos. Cerré el problema".
Aunque nunca reparo el código porque:
- El autor no aprenderá de eso.
- Es como si yo dijera: "Hazte a un lado, déjame mostrarte cómo se hace. Mi código es mejor que el tuyo".
- ¿Por qué habría? Esto es más trabajo para mí.
Pero sugeriré ideas y fragmentos de código en mis comentarios para ayudar al autor. Tenga en cuenta que a veces mis comentarios simplemente le piden al autor que no entiendo su código; Puede que no haya nada malo con su código. Es posible que necesiten cambiar nombres de variables, agregar comentarios, etc. Por lo tanto, ni siquiera sabré qué cambiar en ese caso; solo ellos lo harán.
Si continúa haciendo revisiones, tarde o temprano tendrá una muy buena idea del nivel de conocimiento de cada desarrollador del equipo. Saber esto es realmente útil y debes aprovecharlo y desatarlo. Así es como: si reviso algún código y veo áreas obvias para mejorar y sé que otro desarrollador también puede detectarlo, haré que lo revisen. Algo así como "Oye, veo algunas áreas que se pueden mejorar. ¿Puedes revisarlo con más detalle y enviar tus comentarios al autor?" Esto también funciona muy bien porque ahora tengo otros 2 desarrolladores trabajando entre ellos.
Si estoy revisando algo de trabajo y noto algo de lo que todo el equipo puede beneficiarse, crearé un escenario hipotético y explicaré el problema en una reunión. Comenzaré explicando el escenario y preguntaré a todos si pueden encontrar el problema o ver un problema, involucrarlos. Haz que todos hagan preguntas. Luego, finalmente, presente un mejor enfoque. Si alguien más tiene un mejor enfoque, les agradezco y reconozco frente al equipo que su enfoque es mejor. Esto muestra que no soy el tipo de personalidad de "mi camino o la autopista". Además, NUNCA abro el trabajo de alguien y empiezo a señalar los problemas en una reunión, el autor no lo apreciará, independientemente de cuán agradable e inofensivo creo que estoy siendo.
Cuando hago revisiones, no solo busco un buen código limpio, sino también lo que está haciendo el código. Si el requisito comercial es: Si un empleado ha estado en la compañía por más de 10 años, dele un aumento del 5%. De lo contrario, 2.5% . Lo primero que reviso es si realmente está haciendo eso. Luego verifico si lo está haciendo de una manera limpia, consistente y eficiente.
Si hago una revisión, me aseguro de hacer un seguimiento o nadie tomará las revisiones en serio.
Hace años, solía trabajar con alguien que haría una revisión y contactaba al gerente de desarrollo y al gerente de control de calidad, pero ambos gerentes provenían de una experiencia empresarial o tenían poca experiencia en desarrollo. Él solo hizo esto para impresionarlos. A nadie le gustó y fue entonces cuando me dije que nunca cometería ese error.
La otra cosa que solía hacer es elegir el estilo de programación y estaba convencido de que su estilo es el mejor ("Mi kungfu es mucho mejor que tu estilo mono ..."). Esa fue otra lección para mí: siempre hay más de 1 forma de resolver un problema.
Responda a algunas de sus preguntas numeradas
1- ¿Debo arreglar el código yo mismo?
No, por favor vea las razones que dije anteriormente.
2- ¿Debo darles su opinión sobre el proceso de revisión y dejar que hagan las correcciones de acuerdo con mis instrucciones?
Sí, trate de usar oraciones y un tono que sea amigable pero que requiera atención. Sé tan claro como puedas. Indique cuál es el problema con el código, cómo mejorarlo. NO simplemente pida cambiarlo. Pero proporcione razones.
¿Cómo doy esta retroalimentación? ¿Rellene ciertos documentos de plantilla y se los envíe, o hay algún software que me ayudará a marcar cosas con problemas dentro de los archivos de código donde luego pueden verificarlo? (Estoy usando Visual Studio).
Como dije, puedes usar la herramienta que yo uso u otra herramienta. No use correos electrónicos o documentos de Word porque se pierden y es difícil hacer un seguimiento.
Después de haber revisado el código y se han realizado las correcciones, en algún momento ha pasado y algunas partes del código que revisé en el pasado han cambiado, ¿cómo hago el proceso de revisión? ¿Debería volver a verificar todo el código nuevamente?
Principalmente lo que hago es verificar el delta (solo cambios). Pero debe tener en cuenta la imagen general para asegurarse de que nada se rompa y siga la arquitectura.
Pensamientos finales
Personalmente, creo que la palabra "revisión de código" es una mala elección y no sé cómo comenzó. Podrían haber elegido una palabra mucho mejor y menos autoritaria.