Tal vez leyó la primera parte del artículo sobre el código de revisión por parte del revisor (por cierto, ya logramos discutirlo en el último número del podcast Zinc Prod ).
Por otro lado, dado que el artículo ganó muchos `` me gusta '', escribo la continuación prometida sobre la revisión del código: del autor de los cambios en el código
Como de costumbre, diremos MR (Solicitud de fusión) en lugar de CL, porque pocas personas entienden el término CL.
Las instrucciones originales para los autores de MR según Google se pueden encontrar aquí , y daré un breve resumen.
Así que vamos
Descripción de MR
En Google, la descripción de los cambios se almacena en el historial del sistema de control de versiones, y con mucha probabilidad será leída por mucha gente en el futuro. Por lo tanto, la descripción de MR es muy importante.
La primera línea (en el título) debe contener una frase que describa lo que se hizo en MR. Además, según la tradición, se usa un estilo imperativo (imperativo), es decir Eliminar blablabla , no eliminar blablabla
La descripción en sí misma debe ser informativa, contener una breve descripción del problema que se está resolviendo, enlaces a los documentos necesarios (si es necesario), tareas de seguimiento de tareas y otro contexto. Incluso en el pequeño MR, algo así debería ser.
Una descripción del tipo "Fix bug", por supuesto, se considera inadecuada.
MR debe ser lo más pequeño posible
- Little MR puede ser revisado rápidamente
- La verificación será más significativa
- Menos probabilidades de perder un error.
- No es tan ofensivo si se rechaza todo el MR. Es muy malo cuando se hace mucho trabajo, y luego resulta que todo esto no era necesario en absoluto
- Más fácil impulsar cambios, menos conflictos
- Es más fácil obtener un código de buena calidad.
- Cuantos más cambios a la vez, más difícil será deshacer el código si es necesario.
Es muy raro que no pueda reducir el tamaño del MR, rompiéndolo en pedazos. El revisor tiene derecho a rechazar MR si es demasiado grande
Por supuesto, no puede haber una regla dura y rápida, qué MR se considerará grande, qué pequeño. ¿Son 100 líneas de código grandes o no? Quien sabe
- MR debe hacer una cosa. Por lo general, esta no es la característica completa, sino parte de ella.
- Refactorización separada en un MR separado
La RM debe ser pequeña pero autosuficiente
- Todo lo que un revisor necesita para comprender MR debe estar en ese MR
- Después de inyectar el código, el sistema debería funcionar normalmente.
- Si se agrega un método API, los métodos para usarlo deben demostrarse en el mismo MR. En otras palabras, la RM no debería ser tan pequeña que sería difícil entender cómo se usará y qué consecuencias tendrá.
- Cubra el código con las pruebas, y las pruebas deben estar en el mismo MR
No tomes en serio
A veces los revisores no son muy educados, pueden escribir algo malo sobre su código. Esto no es muy profesional por su parte, pero a menudo todavía hay un grano de verdad en tales comentarios, y esto debe tenerse en cuenta. No respondas con demasiada dureza. Esto solo agravará la situación.
Si no le gusta el tono de la conversación en los comentarios, es mejor encontrar a esta persona y hablar con él personalmente, para explicarle lo que no le conviene.
Si esto no ayuda, Google aconseja contactar al gerente.
Desde mi experiencia, quiero agregar que, a menudo, una persona que escribe un comentario descortés a menudo no da cuenta de que puede parecer agresiva. El texto esconde la mitad de las emociones; Por ejemplo, lo que se dice en tono de broma en forma de texto puede parecer un duro golpe. Por lo tanto, estoy completamente de acuerdo con Google: en caso de malentendido, ¡comuníquese solo en persona!
Explica el código
Si se le pide que explique un punto en el código, considere si puede corregir el código para que sea comprensible sin explicación. Porque si uno no entiende, entonces otros pueden no entender.
Respuesta a los comentarios de los revisores
A menudo, cuando el trabajo se realiza y se envía al código de revisión, es psicológicamente difícil aceptar el hecho de que algo también tendrá que repararse. Por lo tanto, trate de no percibir los comentarios del revisor con hostilidad, piense, tal vez tenga razón, y como resultado el código mejorará.
Sin embargo, si el revisor sigue equivocado, siéntase libre de escribir al respecto, proporcionando la respuesta con argumentos y hechos.
Conclusiones
En general, como entendí de un documento de Google, el autor de MR debe hacer todo lo posible para que el revisor sea más fácil; para que el revisor entienda por qué se hizo el código, cómo se hizo, debe haber todo el contexto necesario para comprender, etc.
Es inevitable que los desacuerdos se resuelvan llegando a un consenso de forma profesional y educada.
En el próximo número de Zinc Selling, definitivamente discutiremos este artículo (y mucho más), así que asegúrese de suscribirse a nuestro podcast , ¡de lo contrario, omita la parte divertida!