¿Qué debo hacer cuando espero una revisión?

32

Antes de hacer mi pregunta, debo explicar la situación.

Estoy trabajando para una empresa como ingeniero de software junior. Una de las personas mayores siempre me detiene cuando he terminado mi desarrollo y quiero comprometerme.

Él siempre quiere que espere a que lo revise. Esto está bien, porque generalmente encuentra algunos errores y hace algunas optimizaciones.

Sin embargo, debo confirmar mi código antes de la fecha límite. Cuando terminé, lo llamé y le dije que estaba terminado. Suele llegar tarde. Entonces mi código también llega tarde.

Mi pregunta es, ¿qué debo hacer? ¿Debo esperarle para una revisión?

EDITAR: adición a la pregunta. Tengo curiosidad sobre un tema más.

Quiero ser libre al codificar. ¿Cómo podría ganarme la confianza para la libertad de desarrollo?

Algunas explicaciones: he hablado con él sobre esto. Pero no sirvió de nada. Ya utilizamos un rastreador de problemas, pero no hay ninguna tarea para las revisiones. Solo hay tareas de desarrollo y prueba.

yfklon
fuente
10
Habla con él al respecto.
Florian Margaine
18
envíele un correo electrónico para decirle que está hecho y que está esperando su revisión. Luego, siempre puede consultar ese correo electrónico si alguien le pregunta por qué no cumplió una fecha límite.
dreza
55
Un rastreador de problemas es solo una herramienta para recordarle pasos importantes que el equipo no quiere olvidar. Si su equipo ve las revisiones como uno de esos pasos, las revisiones probablemente deberían agregarse como tareas separadas. Si su equipo puede manejar cuál de las partes del código debe revisarse sin ingresarla explícitamente en el rastreador de problemas, entonces no es necesario agregar tales tareas. Eso es algo que debería discutir con su equipo.
Doc Brown
3
Sea paciente, no tiene idea de lo beneficioso que es tener un segundo par de ojos (especialmente un mayor) que revisen su código.
JeffO

Respuestas:

70

Entonces mi código también llega tarde.

No, no es su código, es su código y el de los mayores. Están trabajando en equipo, tienen una responsabilidad compartida, y cuando ustedes dos pierden una fecha límite, es culpa de ambos. Así que asegúrese de que el que cumple los plazos lo note. Si esa persona también lo ve como un problema, seguramente hablará con los dos juntos, eso puede ayudar más que una sola conversación con su compañero de trabajo.

Y a tu EDICIÓN:

Quiero ser libre al codificar. ¿Cómo podría ganarme la confianza para la libertad de desarrollo?

Revisar el código es uno de los ahorradores de calidad más importantes. Es prácticamente imposible escribir un código excelente sin un segundo par de ojos, incluso cuando tiene> 20 años de experiencia en programación. Por lo tanto, en un buen equipo, el código de todos debe revisarse constantemente, tanto el código de su superior como su código. Esto no tiene nada que ver con la desconfianza en su contra en persona (o, al menos, no debería). Mientras creas que "codificar gratis" sin un segundo par de ojos es mejor, sigues siendo un programador junior.

Doc Brown
fuente
44
@blank: perdiste mi punto: estoy hablando de responsabilidades y tu punto de vista sobre ellas. Usted cree que solo usted es responsable de cumplir con el plazo; eso está mal, y debe asegurarse de que todos los demás en su equipo también lo sepan.
Doc Brown
Tienes razón al respecto. Pero no hay responsabilidad para el superior. No hay tarea para él para revisar el código. Pero lo hace siempre.
yfklon
27
@blank: ese es exactamente mi punto: si el senior te dice que esperes, él asume la responsabilidad. Que sea transparente para quien define los plazos.
Doc Brown
27

En un buen equipo, debe tener una cola de tareas de desarrollo asignadas en un rastreador de problemas .

De esa manera, mientras espera a un revisor, podría ( debería ) trabajar en la próxima tarea que espera en esa cola. Una vez que se acostumbre a trabajar de esa manera, esto abrirá una oportunidad para que sus cambios se revisen en "lotes", disminuyendo así los retrasos.

  • Si no tiene esa "cola", discuta esto con su gerente, o mejor aún, con el revisor. Si su equipo no tiene un rastreador de problemas razonablemente conveniente para cosas como esa, considere estudiar las bolsas de trabajo u oportunidades de trabajo internas de la compañía para encontrar un mejor equipo (también puede discutir esto con el gerente / revisor, pero no espere que esto ayude, falta de un buen rastreador de problemas es a menudo un síntoma de que algo se rompe gravemente en un equipo).

Quiero ser libre al codificar. ¿Cómo podría ganarme la confianza para la libertad de desarrollo?

Para averiguarlo, primero debe comprender el propósito de las revisiones de código. Usted mencionó la confianza , es una buena "aproximación", pero no del todo precisa.

  • Por ejemplo, en uno de mis proyectos recientes, el desarrollo ha sido realizado por un mini equipo de mí y mi colega. Nos confiamos y respetamos mutuamente, pero a pesar de esto revisamos el 100% del código. Lo estábamos haciendo porque esto nos permitió encontrar y corregir rápidamente algunos errores y, lo que también es muy importante, porque las revisiones no tomaron mucho tiempo y no bloquearon nuestro trabajo.

Verá, sería más exacto pensar en las revisiones de código en términos de los esfuerzos invertidos para evitar ciertos riesgos . En un buen equipo, puede esperar una especie de comprensión compartida de cómo "equilibrar adecuadamente" esto. Tenga en cuenta que no existe un equilibrio adecuado para todos, depende en gran medida de un proyecto: el riesgo y el impacto de los errores en un software de misión crítica difiere naturalmente de eso en una aplicación no crítica.

Con su ejemplo, puede esperar "bloquear las revisiones" siempre que los esfuerzos invertidos por su revisor estén justificados al encontrar errores y mejoras que es mejor corregir antes de comprometer su código.

Es probable que esperen que con la práctica y con la orientación recibida en las revisiones mejorará la codificación, de modo que encontrarán cada vez menos problemas que valen la pena resolver antes de comprometerse. Tan pronto como descubran que su código se volvió "lo suficientemente seguro" para permitir "medidas de prevención de riesgos" menos engorrosas, puede esperar que el proceso cambie, por ejemplo, las revisiones después de la confirmación .

Dependiendo de un proyecto, en algún momento su código puede incluso considerarse lo suficientemente seguro como para omitir las revisiones, dejando el descubrimiento de los errores a los evaluadores (pero eso no necesariamente sucederá, consulte mi ejemplo anterior).

mosquito
fuente
1
Parece que sugiere una solución técnica para un problema organizacional. Según mi experiencia, eso rara vez funciona.
Doc Brown
55
@DocBrown No creo que esta respuesta realmente se centre en una solución técnica. El núcleo de la solución es "debe tener una cola de tareas asignadas a usted". Esa es una solución organizacional a un problema organizacional. Si esa cola se mantiene en un rastreador de problemas, correos electrónicos, una hoja de cálculo, una pizarra o una pila de notas de publicación es solo un detalle.
Carson63000
@ Carson63000 exactamente así. También agregaría que tener tareas en un rastreador de problemas para que uno no tenga que correr al gerente / senior para solicitar una nueva tarea también es un detalle de la organización (y no es un poco menor en mi experiencia)
gnat
1
@gnat: bueno, podrías haber escrito "por ejemplo en un rastreador de problemas" para aclararlo. Pero no estoy seguro de si la pregunta que está respondiendo (la del título) es el punto central de la pregunta de OP escrita en el texto a continuación (que es diferente).
Doc Brown
@DocBrown No hice eso intencionalmente, porque creo que es demasiado importante el detalle de la organización para decirlo como "por ejemplo" (la sola idea de que los compañeros de equipo junior vengan a pedirme la próxima tarea cuando terminen con los envíos actuales me da escalofríos en la columna vertebral )
mosquito el
9

Aquí hay varias respuestas posibles, dependiendo de cuál sea exactamente su problema.

  • Si su principal preocupación es "Me faltan los plazos", no. Ustedes dos están perdiendo fechas límite conjuntamente. ¿Puede (con confianza) decir "Terminaré en una hora, entonces podemos hacer la revisión del código"? Eso podría ser suficiente. ¿Puedes completar el código el día antes de la fecha límite? Eso debería ser un búfer abundante. ¿Está completando su código, con mucho espacio entre "revisar" y la fecha límite? Si esto último, ni siquiera es una falla conjunta, diría.

  • El código siempre debe ser revisado. No puedo registrar nada sin (al menos) un segundo par de ojos y otro ser humano "eso está bien". Eso se aplica a los proyectos donde soy el programador principal, así como a los proyectos en los que normalmente no contribuyo (pero he logrado encontrar un error que me afecta y que quiero solucionar). Sin embargo, la rigurosidad de una revisión se basa mucho en la confianza. Si confío en que la persona que desea enviar el código conoce bien la base del código, no seré tan estricto como si no supiera qué tan bien la persona conoce la base del código.

Vatine
fuente
5

Mi pregunta es, ¿qué debo hacer? ¿Debo esperarle para una revisión?

No, no deberías simplemente quedarte inactivo. Siempre hay algo que hacer. Como Gnat sugirió , debería haber una cola de tareas. O, en una forma ágil de desarrollo, una lista de tareas asignadas para la iteración actual. Si está inactivo, hay algo mal en la organización de su empresa o su equipo.

Otra cosa es: ¿su supervisor superior está realmente verificando cada código que hace? En caso afirmativo, también podría hacer programación de pares.


Quiero ser libre al codificar. ¿Cómo podría ganarme la confianza para la libertad de desarrollo?

Hay algunas regulaciones que requieren que senior verifique el trabajo de junior (creo que medical iso 62304 lo requiere). Si es así, no puedes hacer nada.

Lo que puede cambiar es pedirle a las personas mayores que no verifiquen literalmente todo. Puede configurar el proceso de revisión de código y verificar cosas importantes.

BЈовић
fuente
3

Use git localmente, confirme sus cambios en una rama y comience la tarea 2 mientras espera. Luego, cuando termine, puede fusionar sus cambios en su nuevo trabajo y ya estará por delante de la curva en la próxima tarea.

Haga esto el tiempo suficiente y muy pronto, él puede revisar 2 o más cosas de una sola vez. Elija cosas donde es poco probable que las líneas se superpongan para minimizar los conflictos.

codificador de barcos
fuente
2

Una solución a esto podría ser involucrar al desarrollador senior mucho antes mediante la Programación por pares en su trabajo.

Página de Wikipedia sobre programación de pares

La ventaja más obvia para usted sería que la revisión se realiza mucho antes en el proceso, por lo que ya no tendrá que esperar al desarrollador principal.

Además de esto, podrá ver los procesos de pensamiento y las técnicas del desarrollador principal mientras escribe el código, y aprender de esto.

Es posible que tenga el problema de que el desarrollador senior no quiera emparejarse con usted. Eso puede ser difícil, pero mi propia experiencia es que los desarrolladores senior y junior obtienen mucha experiencia de la programación en pareja.

A menudo también existe la preocupación de que reducirá la productividad al tener 2 desarrolladores trabajando en el mismo trabajo. Es difícil medir cuál es el efecto sobre la productividad con la programación de pares, la respuesta más común que he escuchado es que la productividad de los equipos que se emparejan y los que no lo hacen es casi la misma. (Si alguien conoce alguna buena investigación sobre esto, me encantaría saberlo)

Andy Lowry
fuente
2

No es una respuesta completa en sí misma, solo una adición a las excelentes respuestas anteriores ...

¿Revisas tu propio código antes de registrarlo? Sé que no es lo más divertido, pero trato de obligarme a hacerlo la mayor parte del tiempo. He estado programando profesionalmente durante 20 años (34 años en total), pero generalmente encuentro al menos un error y / o una cosa que olvidé, o al menos podría mejorar. Estoy de acuerdo con el sentimiento de que su código siempre debe revisarse y que un segundo par de ojos es mejor que un par. Pero incluso el mismo par que revisa el código dos veces es mejor que una.

¿Escribes pruebas unitarias para tu código? Además de las pruebas unitarias, también tengo un pequeño script de shell que busca los errores más comunes que cometo personalmente. Algunos de ellos son gramática y ortografía en inglés, otros son problemas de codificación que el compilador no capta. Lo ejecuto antes de registrar grandes cambios como cortesía para todos los que están aguas abajo.

Normalmente dejo que la gente escriba su código y ocasionalmente se queje de ello más tarde, pero no reviso todos los registros. Una vez trabajé con un programador muy joven cuyo código tuve que revisar y generalmente deshacer porque cometieron muchos errores. Eso no terminó bien. Usted tiene una profesión en la que a menudo es más importante hacerlo bien que hacerlo a tiempo. Si aprendes de tus errores, llegarás lejos.

Si puede minimizar la cantidad de cambios que su revisor necesita hacer en su código, maximiza la posibilidad de que confíen en usted para escribir código que no siempre necesita ser revisado con tanto cuidado. Si desea liberarse de las revisiones, asuma la máxima responsabilidad por la calidad de su propia producción.

Algunas o todas estas sugerencias podrían hacerse mientras espera que alguien más revise su código.

GlenPeterson
fuente
1

Creo que realizar revisiones manuales de códigos es ... bueno ... algo así como 80. Bueno, tal vez de los 90.

En esta era moderna de integración continua y sistemas de revisión de código en línea, realmente no desea retener ninguna confirmación de código solo porque tiene miedo de que "pueda romper el control de la fuente".

Vamos gente. Para eso están los conjuntos de cambios (o listas de cambios). Hace que sus programadores alimenten las fauces hambrientas de su sistema de control de fuente. Luego, su servidor de integración continua se inicia con una letanía de compilaciones específicas (bueno, con suerte solo la compilación diaria, pero algunos de nosotros nos dejamos llevar). Si algo se rompe, coloca el trofeo de mono de código (generalmente un juguete de plástico que alguien encontró de una caja de cereal Lucky Charms) en el escritorio del autor y retrocede la lista de cambios. Bueno, algunos sistemas de integración continua envían automáticamente notificaciones por correo electrónico / IM / escritorio a todos en el equipo / departamento / organización que la compilación está rota, junto con un ingenioso hipervínculo para mostrar a todos los que rompieron exactamente la compilación en qué archivo o prueba. Ahora es el programador desafortunado '

A medida que se ejecuta este proceso, se inicia el sistema de revisión de código (nuevamente, activado por el registro). Una lista de miembros calificados del equipo recibe una notificación de la lista de cambios comprometida con el control de origen, se inicia una revisión en el sistema de revisión y todos comienzan a hacer anotaciones a los cambios en la lista de cambios. Esperemos que todos digan "LGTM". Si el programador es inteligente, recordará orar / sobornar / esconderse. Si hay problemas serios, los revisores pueden crear un defecto (que puede engancharse en el sistema de seguimiento de errores), o incluso requerir que se retire la lista de cambios. Sí, los cambios retirados no solo perjudican al ego, sino a la mente, eso es cierto. Es un buen condimento para los desarrolladores junior, reintegrar las listas de cambios rechazadas.

Si su entorno de desarrollo carece de un CI o un sistema de revisión de código, debe investigarlos seriamente. Un par de enlaces pueden ayudarte:

Atlassian Crucible
JetBrains TeamCity
reitveld
Control de crucero

Si va a obtener un servidor CI, también debe pensar seriamente en los marcos de prueba de unidad. Si eres un desarrollador de C #, busca algo como NUnit para comenzar.

code4life
fuente
No sé quién rechazó esta respuesta, pero no estoy de acuerdo con él. Estoy totalmente de acuerdo con code4life en que la revisión del código debe hacerse desde el control de origen, no desde la copia local. Un cambio que demore algún día en completarse debe confirmarse todos los días, tal vez en una sucursal, pero aún debe confirmarse diariamente. A partir de aquí, la revisión del código podría realizarse en un cambio parcial, y las pruebas de CI, compilación e integración diarias se pueden aplicar en esa rama cuando se vuelva lo suficientemente estable.
jfg956
Sip. Y las revisiones de código se realizan contra una lista de cambios en estos días. Las listas de cambios rechazadas se retiran (esa es la opción nuclear), o se generan defectos. Queremos lanzar los compromisos contra el CI tan pronto como sea posible, según el Código Completo de McConnell.
code4life
Supongo que quien rechazó la respuesta no leyó más allá de la primera línea. Creo que la primera línea es un poco engañosa.
Vitalik
LOL, bueno, los años 2010 ... ¡es la era del TDAH-ismo ...!
code4life
Primero: ¿por qué introduce una nueva palabra " revisión manual de código"? ¿Cómo sería una revisión automática de código? A mi entender, la revisión de código es manual. Una persona está leyendo un código para confirmar que hace exactamente lo que se supone que debe hacer (nada menos y nada más). Cualquier automatización como linting o pruebas automatizadas no es una revisión de código. (continuará ...)
try-catch-finally
-1

Dígale de antemano cuándo estará listo su código, no en el momento en que esté listo. Debería poder determinar que aprox. una semana por delante Eso le da tiempo para preparar y planificar la revisión para que se ajuste a sus dos planes.

Jan Doggen
fuente