¿Es un problema que las solicitudes de extracción se aprueben sin ningún comentario?

Recientemente me uní a una nueva compañía dentro de este pequeño equipo. Me encuentro con este problema en el que mis compañeros de trabajo aprueban mi solicitud de extracción unos segundos después de que les pido que la revisen. Nunca hay comentarios al respecto, sin importar cuán compleja sea la solicitud de extracción.

Me estoy frustrando un poco con esto porque sé que mi código no es perfecto, claro, pero no podré aumentar mis habilidades de codificación si no recibo comentarios. Siento que puedo escribir cualquier código y obtengo las aprobaciones para fusionarlo.

Actualmente no tenemos un gerente directo, así que no puedo hablar con ellos sobre esto. También me siento raro acerca de ir a los desarrolladores y pedirles que revisen mejor mis solicitudes de incorporación de cambios. ¿Quizás no debería?

Tenga en cuenta que las solicitudes de extracción de otros equipos tienen toneladas de comentarios, buenos comentarios, no quisquillosos.

No estoy seguro de qué hacer aquí.

¿Está seguro de que no le están dando al menos una revisión superficial antes de aprobarlo? Como, ¿has puesto un código que obviamente no debería haber entrado y lo aprobaron de todos modos?
Puede intentar introducir un error obvio (pero inofensivo) en su código para ver si realmente están revisando el código.
Estoy seguro de que no lo están revisando. Una vez puse un cambio de 10 archivos con más de 509 líneas de cambio de código y tardé 20 segundos en aprobarlo. No estoy bromeando, 20 segundos.
Realmente no quiero introducir ningún error. Prefiero ir por otro camino.
@mkki Si hay un error en el código, y se remonta a esta fusión, entonces quienquiera que sea responsable del sistema puede regresar en ese punto y preguntar si realmente se siguió el proceso de fusión y obtener una explicación.
@Underverse desafortunadamente, aún no hemos lanzado ninguna función al público. Por lo tanto, tendría que esperar algunas semanas para encontrar un error que se remonta a una mala revisión.
@mkki Para entonces, es posible que alguien más verifique su código, haga un cambio, lo pruebe y lo vuelva a fusionar. Si es así, sus pruebas pueden detectar cualquier cosa que su unidad / pruebas de integración no hayan detectado. SDLC, Agile o lo que sea que uses, siempre funciona de la misma manera. Cúbrase, asegúrese de haber hecho lo que pueda, márquelo con la gerencia y siga adelante.
Un problema frecuente para las empresas que realizan revisiones de código es malinterpretar su propósito y pensar que las personas mayores no las necesitan. Hablaría de eso con tus compañeros.
Esta pregunta debería haberse hecho en Software Engineering SE.
@Chris Creo que hay mucha superposición. Si simplemente se le preguntó como "mi colega debe verificar mi trabajo antes de firmarlo, pero simplemente lo firma sin verificar" y no mencionó el desarrollo de software, estaría bien aquí.
¿Haces retros para discutir lo que podrías estar haciendo mejor? No es que tenga un problema con hablar sobre revisiones de código en cualquier momento, pero una retrospectiva podría ser una buena oportunidad para mencionar tales cosas.
@JollyJoker de hecho, ¡es literalmente para lo que están!
@mkki entiende completamente que no desea introducir un error deliberadamente. ¿Qué tal un comentario que diga "si encuentra este comentario durante la revisión del código, muéstreselo a mkki y él le dará $5"? Pronto averigua si lo están mirando de cerca o no...
@mkki Si bien no es una excusa para saltarse la revisión, 509 LOC en 10 archivos es un poco dudoso.
A mí me parece que el problema es que aprueban tan rápido que claramente no revisaron nada. La ausencia de comentarios no es realmente el problema. Sugiero cambiar el título para reflejar mejor el cuerpo de la pregunta. (Esto no es "mover los postes de la portería" de la pregunta, ya que su pregunta es la misma, simplemente brinda un mejor resumen).
¿Cuál es su proceso de organización del trabajo? ¿Estás en Ágil? ¿Tienes sprints y retrospectivas al final de los sprints? ¿Hay alguna otra ceremonia programada que tenga en la que pueda mencionar cosas para comenzar/detener/continuar haciendo, donde este tema sería bastante relevante?
Recomiende que se agregue el comentario "También soy el desarrollador con más experiencia en el equipo" al texto de esta pregunta.
Pregunta sobre el comentario "También soy el desarrollador de mayor antigüedad en el equipo": supongo que eres mayor en años, pero ¿también eres mayor en el puesto o en alguna forma oficial? Si alguno de estos es un 'sí', cambia drásticamente lo que puede hacer para cambiar la cultura de la empresa, más allá de la respuesta actualmente aceptada de 'solo pida comentarios'.
Típico típico típico en mi empresa. La gente no dice "¿puedes revisar mi PR?", dicen "¿puedes aprobar mi PR?". Tengo la suerte de trabajar en un equipo pequeño que se preocupa por los estándares de calidad del código; en realidad, hacemos la revisión y, por lo general, nuestras relaciones públicas deben actualizarse de 1 a 3 veces antes de fusionarse.
¿Lo hacen también con las relaciones públicas de otros? ¿Usted mismo hace comentarios de relaciones públicas? Suponiendo que lo haga, ¿cómo reaccionan los autores entonces?
¿Cuál es la política oficial de la empresa? ¿Se espera que revisen su código? ¿O es simplemente que "no puede aprobar su propia solicitud de extracción"?

Respuestas (14)

La respuesta corta es no

Es el trabajo de la persona que ejecuta la fusión asegurarse de que se ha seguido el proceso. Tú hiciste tu trabajo, ahora ellos tienen que hacer el suyo.

Puede hacer un seguimiento con ellos y preguntar por qué no hay comentarios o comentarios sobre sus solicitudes de extracción si cree que debería haberlos. Esta es una pregunta cultural: ¿cómo funciona normalmente su oficina? ¿La gente hace una revisión del código real? ¿Cómo son las relaciones públicas de otras personas?

Las relaciones públicas de otros equipos tienen toneladas de comentarios, buenos comentarios, no quisquillosos.
Está bien, hay un problema, pero no es tu problema. No tienes control sobre lo que hacen los demás, y cada uno tiene que hacer su trabajo. Sugiero agregar esta información a la pregunta original: que sus solicitudes son diferentes de las demás.
@mkki ¿Por "otros equipos" te refieres a personas fuera de tu equipo que hacen relaciones públicas? Si es así, tiene sentido que los miembros fuera de su núcleo estén bajo un escrutinio más intenso.
También puede no ser problema de la persona que realiza la aprobación. Cuando tiene escasez de recursos, a veces tiene que elegir buenas prácticas por sus riesgos para asegurarse de que el equipo cumpla. De la misma manera, es posible que se le niegue la asistencia a un taller de capacitación extenso y relevante para mejorar su código poco antes de una fecha límite. No es diferente realmente.
Aquí vemos un patrón de preguntas y respuestas estándar de Workplace: alguien dice "algo va mal en mi empresa, ¿qué debo hacer?" y la respuesta que aparece es "simplemente no haga nada a menos que sus responsabilidades oficiales lo requieran". ¿A nadie aquí realmente le importa el éxito de las organizaciones para las que trabajan? ¿Nadie aquí está haciendo nada que realmente tenga un impacto en el mundo, de modo que las cosas que van mal importen al menos un poco, incluso si no en el sentido literal de que "la gente morirá"? Nunca compraré esta idea de que uno debe ignorar la disfunción porque no es su trabajo remediarla.
@MarkAmery bien dicho! Puede que no siempre sea posible hacer del mundo un lugar mejor, pero es por lo que debemos esforzarnos.
@MarkAmery Esa es una actitud noble, pero después de algunas décadas de ver los resultados de docenas de personas bien intencionadas que creen que saben cómo hacer mejor el trabajo de los demás, a menudo no es una actitud útil . Si realmente quiere poner en orden a la empresa, primero ascienda a un nivel en el que tenga la autoridad para hacer lo que quiera e imponérselo a otras personas.
@alephzero Claro: tener una rabieta por cada decisión y proceso con el que no está de acuerdo y negarse a abandonarlo hasta que se salga con la suya es aún peor; cierto nivel de voluntad de deferir a los demás es necesario para que cualquier organización funcione sin problemas. Pero no se sigue que la respuesta correcta sea lo que defiende esta respuesta: no intentar en absoluto influir en las cosas que van mal, incluso cuando están contenidas dentro de su propio equipo pequeño, directamente dentro de su propia área de experiencia e impactando. el resultado de su propio trabajo. El enfoque correcto se encuentra en algún lugar entre esos dos extremos.
@MarkAmery Lo que no ve es que si es tan bueno solucionando disfunciones en su organización (usted dijo que no ignoraría disfunciones incluso si no fuera su responsabilidad laboral), entonces ¿por qué no comparte su experiencia sobre cómo detuvo dicha disfunción en lugar de agregar otra voz? Será interesante ver cómo un compañero de trabajo que no tiene autoridad más allá de ser miembro de un equipo contratado para un propósito específico puede cambiar la organización para mejor.
@Dan "Será interesante ver cómo un compañero de trabajo que no tiene autoridad más allá de ser miembro de un equipo contratado para un propósito específico puede cambiar la organización para mejor". - como paso 1, sugiriendo que las personas hagan las cosas de la manera que usted cree que deberían hacerse, y diciéndoles por qué. Eso es con suficiente frecuencia.
@MarkAmery No está claro si está hablando por experiencia o tratando de expresar un pensamiento noble sobre cómo deberían ser las cosas. No creo que estés hablando por experiencia, ya que no dijiste nada. Convencer a la gente es difícil y es aún más difícil cuando no tienes la autoridad para hacerlo.
@Dan, hablo con mucha experiencia. Honestamente, encuentro esto desconcertante. ¿Debo inferir que nunca ha señalado un problema a alguien que luego solucionó, o hizo una sugerencia que luego implementó, sin que primero se le haya otorgado autoridad formal sobre ellos? ¿Que todas las ideas que has planteado en tu carrera han sido rechazadas a menos que la persona a la que se las expresaste fuera oficialmente tu subordinado? Sugerir formas de hacer mejor las cosas a compañeros y gerentes ha sido algo que la gente ha hecho en todas las empresas en las que he trabajado, y no tiene nada de especial.
@MarkAmery "Sugerir formas de hacer mejor las cosas a compañeros y gerentes ha sido algo que la gente ha hecho en todas las empresas en las que he trabajado, y no tiene nada de especial". - Genial.... así que esta experiencia tuya será súper genial para compartir como respuesta a esta pregunta. Dado que este parece ser un problema trivial (como usted lo llama, sin importancia, ya que ocurre a diario), ¿por qué no crea su propia respuesta y comparte esa experiencia en la que logró convencer a numerosas personas para que hicieran comentarios sobre su PR? Parece que vas a ser de gran ayuda para el OP.
Esta respuesta es un claro ejemplo de por qué debe publicar preguntas de ingeniería de software en el sitio de ingeniería de software SE. Nadie que entienda el desarrollo ágil de software le diría que este no es su trabajo o su responsabilidad. Usted y su equipo son responsables de su proceso y de mejorarlo.
Siendo "The Guy" que revisa y aprueba las solicitudes de incorporación de cambios, en gran medida le he dicho a mi equipo: "Mira, me aseguraré de que no haya ningún conflicto y de que si introduzco el código en la rama de destino, no No arroje errores del compilador Le echaré un vistazo al código, si no está demasiado complicado y me aseguraré de que parezca que estás haciendo las cosas bien, pero en su mayor parte, es posible que no sepa necesariamente qué es estás tratando de lograrlo. Solo estoy aquí para mantener estable al maestro". Hay otros revisores (pero yo soy el único que se fusiona) y un proceso de revisión secundario, por lo que es bueno que no haya comentarios (sobre las relaciones públicas).
@ Draco18s Donde hay un proceso automatizado para la calidad del código, las pruebas unitarias y de integración, y una visualización clara de los cambios con diferencias, seguro. Mi respuesta aquí proviene de la experiencia directa de años de trabajo con personas que tienen un trabajo que no lo hacen. Mucho de lo que hay en estos comentarios es cierto, y esto debería estar en SE.SO por el lado técnico. Del lado del lugar de trabajo, saber cómo trabajar dentro de un equipo y ser parte de ese equipo es igual de importante.
@MarkAmery: 100 % de acuerdo, para este problema más que para la mayoría no hay nada de malo en preguntar o mencionar esto al resto de su equipo. Puede mencionarlo como un tema de discusión, como "oye, ¿qué hacen normalmente para revisar el código antes de fusionar una solicitud de extracción? Me pregunto si podría tener un segundo par de ojos en mi código". A diferencia de algunas preguntas de Work.SE en las que no hacer nada tiene alguna justificación, no hay problema en meter la nariz en los asuntos de otras personas. Se trata de cómo tratan contigo . Al menos esta respuesta sugiere hablar con la gente.
@Underverse Y cada equipo es diferente. Sé que me encantaría usar pruebas unitarias (pero son frustrantemente difíciles de hacer en Unity 3D: oh, puede hacerlo, pero el 80% de su prueba unitaria implicará interactuar con UnityEngine, que solo se puede hacer como una "prueba de unidad de tiempo de ejecución" que no es rápida y horrible para trabajar) y algo como Jenkins, pero no sé cómo configurar y ejecutar Jenkins. Solo hay otro desarrollador senior además de mí, así que básicamente funciono como Jenkins. En cualquier caso, no estaba realmente comentando sobre los comentarios, sino brindando mi propia perspectiva.
@MarkAmery: suponga por un momento que no sabe si está haciendo lo correcto o lo incorrecto. Pero tienes la opción de ser proactivo o no. Si eres proactivo y acertado, ¡genial! Pero si está equivocado, ser proactivo solo lo empeora. "Zealot" es una palabra con una connotación negativa, aunque estrictamente no se refiere a correcto o incorrecto, sino al enfoque apasionado o proactivo. En resumen, no ser demasiado proactivo lo protege de la posibilidad de que se equivoque y se lo considere demasiado entusiasta y crea problemas (incluso si tiene buenas intenciones)
@MarkAmery: Estoy de acuerdo en que ser proactivo es la mejor manera de obtener el mejor resultado. Pero no ser proactivo lo protege del peor resultado. Especialmente cuando se encuentra en una situación en la que puede ser criticado en función de sus resultados (y no de sus intenciones), es más seguro errar por el lado de no ser proactivo. No me gusta, pero hay muchos lugares de trabajo donde el espíritu comunal es inexistente y la gente apenas puede cubrirse el trasero. Tu intención es noble, pero sin el apoyo del grupo solo te convierte en un objetivo para cualquiera que esté dispuesto a explotar tu buena voluntad.

Si bien las otras respuestas son buenas, mencionó algo nuevo y relevante en un comentario , lo que podría estar causando el comportamiento específico de sus compañeros de equipo en su caso. Tú dijiste :

También soy el desarrollador más senior del equipo.

Eso podría ser importante aquí. En ese caso, puedo imaginar fácilmente que lo tratan con más deferencia/respeto, y se podría aplicar una combinación de los siguientes (los he visto personalmente):

  • los otros miembros del equipo no quieren que los vea desafiando la calidad de su código; y/o

  • los otros miembros del equipo asumen que lo que escribes será mejor que lo que ellos escriben y por lo tanto (erróneamente) asumen que esto significa que no cometerás errores que podrían encontrar, incluso si revisaron tu código;

    y por lo tanto:

  • simplemente "sellan" sus solicitudes de extracción, que es lo que ve que sucede.

Esto es especialmente cierto ya que usted tiene:

recientemente se unió a una nueva empresa

Entonces, dado que eres nuevo en el equipo, es posible que no sepan que el desarrollador senior todavía quiere revisiones detalladas de miembros del equipo menos senior (no todos los desarrolladores senior lo hacen). ¿Quizás su equipo haya tenido anteriormente un desarrollador senior que "explotó" cuando se revisó su código, por lo que se han condicionado a no hacerlo?

También me siento raro acerca de ir a los desarrolladores y pedirles que revisen mejor mis solicitudes de incorporación de cambios.

Sugiero llevar a un miembro del equipo a un lado en un momento tranquilo y privado , y sin indicios de que hayan hecho algo malo, solo pregúnteles por qué no revisaron su código más a fondo. Y espero que den una respuesta honesta. Su respuesta podría coincidir con una de mis sugerencias anteriores, o podría traer algo nuevo, por ejemplo, tal vez hiciste algo en el pasado (sin saberlo) que les hizo pensar que no querías revisiones en profundidad, por lo que siempre han estado siguiendo ese concepto erróneo. ¿desde?

No creo que sepas la respuesta hasta que alguien en tu equipo te diga por qué se comportaron de esa manera.

Puede valer la pena reunir a todos y preguntar "¿realizamos revisiones de código y, de ser así, cuál es el proceso?" o "parece que no hacemos revisiones de código, ¿deberíamos comenzar?". Pero tal vez no vean la necesidad de ellos en absoluto (¡oye, Agile es hacer lo que funciona para el equipo!) y tienen otros procesos para la calidad del código después del evento (no juzgo si esto es bueno o malo, eso es no la pregunta formulada).
@gbjbaanb - " Podría valer la pena reunir a todos " Personalmente, deliberadamente no comenzaría con todos juntos. La presión de los compañeros puede dar resultados extraños, por ejemplo, las personas que no están de acuerdo con los que más hablan, pueden no hablar frente a ellos. Esto también puede inhibir cualquier explicación de por qué las revisiones de código (al menos las del código del OP) no se están realizando actualmente en ese equipo, especialmente si las razones son vergonzosas/personales/etc. Es por eso que sugerí comenzar con un silencio, privado uno a uno, para evitar la presión de los compañeros y facilitarles la apertura. Como siempre YMMV.
Si OP es el "desarrollador más senior" reconocido, parte de su cometido puede ser capacitar al equipo y mejorar la calidad del trabajo allí. Tener conocimiento de buenas prácticas de Code Review es algo que se podría compartir. Siento que valdría la pena enfatizar eso como parte de su respuesta que, de lo contrario, cubre todo lo que podría decir.
Una buena manera fácil de probar esto: poner un montón de basura en una solicitud de extracción y ver cuál es la reacción. Si se aprueba, tiene algo que puede presentar que sabe que no debería haber sido.
Llevar a alguien a un lado para hablar de esto probablemente se sienta raro para esa persona, sin importar cómo lo hagas. Probablemente sería mejor esperar a una conversación individual más natural, como ir a almorzar o tomar un café, y luego plantearlo como una conversación informal.
@UKMonkey ya lo ha hecho de manera efectiva. Si un PR se aprueba momentos después de emitido, significa que no importa lo que haya en el PR, basura o no.
Sugeriría decirles que necesita una retroalimentación constructiva sobre sus relaciones públicas para ayudarlo a mejorar, en lugar de preguntarles por qué están dando el visto bueno. Este último puede parecer acusatorio, mientras que el primero enfatiza que se trata de superación personal.

Como el desarrollador más senior del equipo, diría que es parte de su responsabilidad establecer expectativas para el flujo de trabajo de desarrollo de su proyecto.

He trabajado en proyectos que son colaboraciones entre desarrolladores sénior y competentes, donde las solicitudes de incorporación de cambios son pro forma , a menos que un relaciones públicas solicite específicamente que otros observen de cerca el código y vuelvan a verificar algo. Los comentarios detallados y las revisiones (especialmente sobre el estilo del código, etc.) no se esperaban ni eran bienvenidos por cada pequeño cambio. También he trabajado en proyectos en los que se examinan todas las relaciones públicas, incluso las correcciones de errores de una sola línea.

En su lugar, establecería expectativas con un empujón cortés y humilde, por ejemplo: "Estoy a punto de enviarle una solicitud de extracción para [Función X]. No estoy seguro de cómo solucioné [Problema Y]; ¿podría por favor, eche un vistazo y avíseme si detecta algún problema. Además, ¿tiene algún consejo sobre cómo podría refactorizar [Sección Z]? Creo que podría ser difícil de entender y mantener en el futuro, pero no veo una solución elegante".

Probablemente tendrá que dejarlo pasar hasta que obtenga un gerente directo.

Tenga en cuenta que la persona que aprueba su solicitud de extracción está tratando de "hacer su trabajo" y aparentemente, en su opinión, "su trabajo" no implica hacer una revisión extensa de su código. Pero ese es el problema: no puedes obligarlos a cambiar de opinión sobre en qué consiste su trabajo.

De manera realista, tendrá que esperar hasta que alguien con autoridad tenga la capacidad de indicar cuáles son las prioridades y pueda indicarle al otro programador que las revisiones de código son parte de lo que se supone que deben hacer.

Por lo general, este tipo de problema continúa hasta que un problema grave del sistema hace que la administración se involucre. Solo entonces les importa porque les afecta.

Estoy de acuerdo contigo, esto es un problema, pero no creo que el problema sea que no hay comentarios. Creo que el problema es que las solicitudes de extracción se aprueban instantáneamente . Eso significa que nadie está revisando críticamente su código . Y si no están revisando su código, probablemente tampoco estén revisando el código de los demás. No está aprendiendo / mejorando, y el código incorrecto está aterrizando en la rama principal.

Lo que necesitas aquí son aliados. Averigüe quién en este equipo se toma en serio la revisión del código. Ponga la revisión del código en la agenda de su próxima reunión de equipo y discútalo. Si la mayoría está de tu lado, es más probable que ganes. Si no es así, incluso en la mayoría de las nuevas empresas, hay algo de gestión. Hágales entender que este problema de "aprobación de amigos" es muy real y una amenaza. Muéstreles ejemplos de aprobación instantánea o incluso de código obviamente malo que no fue detectado.

Con el respaldo de la mayoría o de la gerencia, diríjase a quien administre el repositorio y asegúrese de que se establezcan reglas en los repositorios de código que requieran al menos un revisor de confianza (que se tome en serio la revisión del código) para aprobar cualquier solicitud de incorporación de cambios antes de que se fusione. Por lo tanto, todas las demás "aprobaciones de amigos" tienen menos importancia. Sin embargo, creo que sigue siendo importante que aquellos que no se toman en serio la revisión del código aún estén obligados a hacerlo, con la esperanza de que mejoren.

He luchado contra este mismo problema en mi equipo y contar con revisores de confianza fue mi solución. Debe proteger el repositorio de los "aprobadores de amigos" habituales. En mi experiencia, si no puede hacer que eso suceda, probablemente no haya forma de que pueda ganar la batalla de la calidad del código. Lo mejor que podrá hacer en ese caso es cubrirse el trasero y esperar el inevitable desastre que fuerza el asunto. No seas el que sostenga la bolsa cuando suceda. No comprometa su propia disciplina de revisión de código; tal vez algo de eso incluso se les pegue. No combine sus propias solicitudes de extracción hasta que tenga más de la cantidad requerida de aprobaciones. Y asegúrese de escribir pruebas unitarias mejores y más completas que el próximo.

Si puede hacer esto sin siquiera la apariencia de echarle la culpa, entonces la próxima vez que un defecto evidente que debería haber sido detectado en la revisión del código llegue a la rama principal (es decir, código con malos anti-patrones), tráigalo a colación. equipo como una oportunidad para mejorar la calidad con un enfoque renovado en el proceso de revisión de código. Solo asegúrate de que no haya culpa, o solo dañarás tu propia reputación.

Específicamente en lo que respecta a la necesidad de comentarios, creo que los comentarios generalmente solo deben hacerse si ve un problema o tiene una pregunta. Si las relaciones públicas son buenas, no hay razón para comentar; solo apruébalo. Sin embargo, si se rechaza un PR sin ningún comentario, creo que sería un problema porque el contribuyente no sabe qué se debe cambiar para que el PR sea aceptable.

(Y, esta pregunta probablemente pertenezca a Software Engineering SE).

Si no puede confiar en que sus desarrolladores (pagados) hagan buenas revisiones (con capacitación, expectativas explicadas de que hagan revisiones, etc.), simplemente despídalos y contrate a otros mejores. De lo contrario, tienes a Sally, Bob, Tom y Jane, que se pasan todo el día haciendo cosas divertidas del código, y los pobres y diligentes Jim y Joan, que se pasan todo el día simplemente revisando el código, que les lleva todo el día porque están siendo diligentes, y luego explican en levantarse todas las mañanas que pasaron todo el día revisando el código y sin hacer ningún progreso en sus tareas asignadas reales... nah, no estoy amargado (mucho).
Si esto. El objetivo es NO tener comentarios. Pero es para no tener comentarios porque el código es bueno, en lugar de porque los revisores no se molestaron en revisarlo.
@ user3067860 El problema que mencionó se puede combatir mediante la contabilidad de tareas. Si su herramienta Scrum admite el desglose de tareas en historias con horas, solo asegúrese de que la revisión del código sea una tarea distinta e independiente en cada historia, y que la revisión del código sea parte de la definición de Listo, y tome en serio el registro del tiempo de la tarea con precisión. Jim y Joan luego contribuirán con toda su capacidad en las tareas de revisión de código de las historias, y los demás quedarán expuestos como revisores poco serios. Si la gerencia pregunta por qué Jim y Joan "tardan demasiado" en la revisión del código, es la apertura perfecta para una discusión.
@wberry Pero preferiría renunciar y encontrar un mejor trabajo con mejores compañeros de trabajo que seguir siendo el único que hace todas las revisiones por pares, mientras que mis colegas hacen las cosas realmente divertidas. Además, prefiero renunciar y encontrar un trabajo mejor que registrar el "tiempo dedicado por horas", y si la razón por la que tengo que registrar el tiempo dedicado por horas es porque mis compañeros de trabajo son menores que no pueden hacer su parte del no- trabajo divertido......

Haz lo que yo hago: pregúntale directamente a un desarrollador sénior si puede echar un vistazo a tu conjunto de cambios propuesto y ver si está satisfecho con él. Solicite comentarios. Todavía tengo que tener una experiencia negativa con este enfoque.

Si no tienen tiempo para echar un vistazo a su código, se lo harán saber.

Es posible que tenga que comunicarme fuera de mi equipo para obtener esto.
@mkki, sus compañeros de equipo serían los más familiarizados con los módulos y los estándares de codificación del proyecto en el que está trabajando.
aunque ese es el problema. Mis compañeros de equipo no comentan mis relaciones públicas. También soy el desarrollador de más alto nivel en el equipo, así que voy a tener que llegar fuera de nuestro equipo.
@mkki ah, ya veo. Bueno, como el desarrollador más senior, deberías establecer el tono. Hable con sus colegas y explíqueles sus inquietudes y recuérdeles el propósito de las solicitudes de incorporación de cambios y las revisiones de código. El problema bien podría ser que, debido a que usted es el desarrollador más experimentado, los demás asuman que su código está bien o que desconfíen de señalar errores. Dices que no tienes un gerente directo, pero alguien debe estar diciéndote qué hacer, ¿verdad? No estás operando en el vacío.

Supongo que estoy un poco en contra de la corriente aquí, pero sí, esto es un problema y sí, deberías intentar ser parte de la solución. Antes de continuar, diré que este es un problema difícil de resolver. Este es el principio a seguir con las revisiones de código:

Si estamos aprobando la mayoría de las revisiones de código sin ninguna entrada, eso significa que creemos que generalmente hacemos las cosas correctamente la primera vez.

En términos generales, esa es una mala filosofía de vida. Para el software, sabemos que el código que ha sido probado y considerado digno de producción siempre tiene errores. Tuve un profesor en la universidad que afirmó que había aproximadamente 1 error por cada 100 líneas de código en la mayoría del software, pero no puedo encontrar una fuente para eso en este momento. Además, los errores son caros: algunos afirman que un error cuesta $ 10k si se encuentra en producción

Vale la pena dedicar un tiempo a revisar el código y al menos hacer preguntas al respecto.

En cuanto a resolver el problema, obviamente no puede obligar a las personas a cambiar ya que usted no es la gerencia (y, por supuesto, la gerencia realmente no puede obligar a las personas a cambiar). Recomiendo algunas cosas:

  1. Revise el código de la forma en que cree que se debe revisar el código. En las conversaciones que siguen, explícales a las personas por qué lo haces de la manera en que lo haces y déjales en claro que te encantaría que revisaran tu código de la misma manera.
  2. Discuta este problema con otras personas influyentes entre los ingenieros. En algunas empresas, estas personas serían arquitectos u otros desarrolladores sénior, pero sea cual sea el título del puesto, usted busca líderes técnicos que otros ingenieros de su equipo respeten. Hable de lo que está pasando con esta persona (estas personas) y trate de que le ayuden.
  3. Cuando obtenga un gerente directo, conviértalo en un tema de conversación con el gerente y convénzalo de que esto es algo que debe cambiar.

Reconocer este tipo de problemas e intentar resolverlos es un diferenciador importante entre los ingenieros.

No creo tu respuesta porque "en cuestión de segundos"
@Joshua No estoy seguro de a qué te refieres.
No podrían haber revisado la solicitud de incorporación de cambios en menos tiempo del que se tarda en leerla.
No veo a qué parte de mi respuesta te refieres.

Debe averiguar por qué no están revisando las solicitudes de incorporación de cambios antes de poder decidir qué hacer al respecto. Fuera de mi cabeza, podría ser cualquier combinación de:

  • Se están defiriendo a usted como el más antiguo.
  • Tienen otro proceso para revisar el código.
  • Tienen prácticas inseguras realmente horribles y simplemente nunca revisan el código.
  • Sus solicitudes de incorporación de cambios son demasiado complicadas para revisarlas en la herramienta.
  • Están bajo presión para liberar lo más rápido posible, omitiendo pasos que de otro modo serían esenciales.
  • No saben cómo hacer una revisión de código real.
  • Son demasiado perezosos para hacer una revisión de código real.

Creo que el mejor caso que podrías esperar sería si tienen otro proceso para revisar compromisos complicados, pero no te lo han explicado y se preguntan en silencio por qué no lo estás siguiendo si eres más senior. En cuyo caso, si tiene una conversación rápida, ellos pueden explicarle cómo revisan el código... y le recomendaría dar su camino al menos un intento honesto antes de declarar inmediatamente que su camino es mejor.

Creo que el caso más probable y más desafortunado son las buenas prácticas, no saber mejor y tratar de omitir pasos para ahorrar tiempo o esfuerzo. Luego, como el más antiguo, es su trabajo enseñarles y fomentar las buenas prácticas (tal vez incluso hacer cumplir las buenas prácticas, si fue contratado como líder). Probablemente necesitará hacer revisiones de código como grupo por un tiempo para establecer sus expectativas sobre qué tan completos deben ser. Y deberá ajustar su velocidad, ya que durante un tiempo pasará mucho tiempo revisando el código. (Lo compensa más tarde al no tener que dedicar tiempo a la corrección de errores, pero sin ningún producto lanzado... ¡ay!).

Si está trabajando en un entorno ágil, arreglar esto es su responsabilidad , así como la del resto del equipo. Ustedes son responsables de su propio proceso, son dueños de su trabajo, son un equipo autoorganizado de desarrolladores de software capaces y deben mejorar en todo lo que puedan, tanto individualmente como en equipo.

El problema central aquí es que no están siguiendo el proceso de revisión de cada línea de código o el proceso no está bien definido (por ejemplo, solo establece que los PR deben aprobarse, no que los cambios deben revisarse). De cualquier manera, deben decidir cómo van a trabajar a partir de ahora, definir un proceso en el que todos estén de acuerdo, posiblemente escribirlo (principalmente para futuras contrataciones), comprometerse a seguir el proceso que ustedes mismos acaban de decidir y hazlo. Mencionar esto es responsabilidad de cada miembro del equipo, incluyéndote a ti. Es posible que algunos (por ejemplo, los jóvenes) no se den cuenta de esta oportunidad de mejorar su forma de trabajar, así que plantéelo usted mismo y enséñeles por qué esto es bueno para el equipo en general (mejor código, menos errores).

Como otros han mencionado, esto podría estar relacionado con que usted sea el desarrollador más senior. Algunos pueden pensar que cuestionarte es malo y no darse cuenta de que en realidad es una gran oportunidad para que entiendan por qué haces (la mayoría) de las cosas mejor que ellos y cómo piensas en los problemas para llegar a (en su mayoría) mejores soluciones. Enséñales esto. Y también, esfuércese por crear un ambiente seguro, donde aunque a veces no vea claramente oportunidades como esta, se sienta libre de cuestionar cualquier cosa y cualquier persona sin temor a que la otra persona se sienta atacada. Es posible que desee preguntar cómo otros equipos de su empresa hacen eso y cómo pueden lograrlo ustedes.

Su trabajo debe ser revisado adecuadamente antes de ser aceptado. Dado que su compañero de trabajo aparentemente no está dispuesto a hacerlo, debe revisar su código usted mismo. Es una buena idea hacer esto de todos modos; cuanto mejor sea el código que permita que otros revisen, mejor para su reputación y menos trabajo para todos.

Eso no significa que no debas hacer que revise tu código correctamente.

Obviamente, un desarrollador necesita revisar su propio código, el proceso es parte del desarrollo normal. Y siento que "hacer que revise su código correctamente" no es útil.

Algunas cosas de la experiencia personal que pueden ayudar con su problema:

  • Mantenga las relaciones públicas pequeñas y simples. Revisar un RP pequeño que resuelve un solo problema bien definido es mucho más fácil que realizar muchos cambios diferentes en varios archivos. Cuanto más grande sea el PR, más probable es que sus compañeros lo hojeen y se pierdan cambios importantes.
  • Si hay cambios específicos sobre los que desea recibir comentarios, coméntelos y explique sus inquietudes. Esto llamará la atención de las personas sobre el cambio y les pedirá que compartan su opinión.
  • Etiquete a más personas en sus relaciones públicas y solicite al menos 2 o 3 aprobaciones antes de fusionarse.

Mi empleador asignará dos líderes de ingeniería a cada proyecto. Uno es el "líder de ingeniería" del mismo nombre que está a cargo de asignar tareas al proyecto y responder directamente a la producción y el control de calidad, y es esencialmente un tipo "el dinero se detiene aquí". El otro es un "ingeniero principal" cuya función laboral es esencialmente "ser el tipo que lo sabe todo".

Los ingenieros principales a menudo establecen pautas arquitectónicas para el proyecto, dictan que se usen (o no se usen) ciertas tecnologías y hacen cumplir las mejores prácticas en la base de código. Hasta cierto punto, esa base de código es su bebé y no deberían permitir una imperfección en el caparazón de ninguna de sus muchas tortugas. Con ese fin, el director mismo debería revisar una proporción decente de los RP que ingresan, o al menos revisar las revisiones .

Si tiene un ingeniero en un rol similar, le recomiendo que acuda a él con sus inquietudes. Parecen estar bien fundados. Si no lo hace, le recomiendo enfáticamente que (dada su antigüedad) desempeñe ese puesto usted mismo, con la soborno de su jefe de departamento.

Hay muchas buenas respuestas aquí, pero no noté a nadie que sugiriera eso en su PR:

  • Menciona lo que arreglaste
  • Menciona cómo lo probaste
  • Pídeles que miren/busquen cosas específicas

Otra cosa que podrías hacer, y yo hago esto con mis propias relaciones públicas, es después de enviar tu propia revisión de relaciones públicas .

Eso significa quitarse el sombrero de "Yo escribí esto" y ponerse el sombrero de "Alguien más escribió esto".

Pretenda que fue su desarrollador más joven en el equipo quien escribió el código y revíselo exactamente como esperaría que se revisara. Comente su PR de la forma en que esperaría que la gente lo comentara.

Ha habido varias veces al revisar mi propio código que descubrí cosas que olvidé arreglar/depurar código que olvidé eliminar.

También parece que tienes un cambio cultural que necesitas hacer. Como desarrollador sénior, tiene algo de peso, pero debe decidir si quiere gastar el capital político para exigir las cosas por decreto, o si quiere dedicar tiempo a desarrollar las habilidades de equipo que está buscando. . Este último es probablemente más eficaz, aunque puede llevar más tiempo.

Como se trata de Workplace.SE y no de Software Engineering SE, responderé esta pregunta desde el punto de vista general de "nueva contratación de ingenieros".

Estás en un nuevo trabajo en un equipo pequeño. Como tal, necesita orientación sobre la forma en que se hacen las cosas en esta empresa y en el proyecto en el que está trabajando. Pero como un equipo pequeño que probablemente ha tenido que lidiar con falta de personal hasta que lo contrataron, es probable que tengan una acumulación de trabajo que deba hacerse. ¿Has preguntado esto?

Tenemos una nueva contratación en nuestra empresa (ingeniería, no software). Al principio, solo se le asignó un proyecto, uno de mis proyectos, y estaba claramente frustrado porque no estaba recibiendo la supervisión que le gustaría. Pero tenía cosas urgentes que hacer (ya que hemos estado cortos de personal durante varios meses) y solo podía ayudarlo con cosas que deben hacerse perfectamente AHORA (es decir, cosas que iban fuera de la empresa al cliente y proveedores). De manera proactiva, se encargó de preparar la lista de materiales para uso interno de la empresa para el proyecto (no en el formulario de la empresa, ya que no se le mostró dónde estaba). Su formato resultó ser una gran mejora en el formulario de la empresa, por lo que Le dije que siguiera adelante pero que hiciera algunos ajustes en el contenido. Ahora tiene varios proyectos en los que trabajar para que el problema se resuelva; de hecho, solo un par de semanas después,

El punto es que debes averiguar si lo que está sucediendo es una situación temporal o si es lo que siempre hacen allí. Claramente sienten que escribir "su código" es su responsabilidad y más importante que revisar "su código", que es claramente incorrecto. Documente lo que está sucediendo para que cuando alguien se queje de que su código no funciona o no cumple con los estándares de la empresa, pueda responder con "Era nuevo en la empresa y nadie me dio ninguna orientación". Eso es lo mejor que puedes hacer.

¿Es un problema que las solicitudes de extracción se aprueben sin ningún comentario?
RespuestasAquíPolítica de privacidad1y, 0v