En muchos años escribiendo y revisando código, aprendí algunos secretos para crear mejores solicitudes de extracción y revisar código de manera más eficiente.
He incluido todos estos secretos en mi nuevo libro Pull Requests and Code Review , pero aquí encontrarás una vista previa de estos 13 consejos, que ya puedes utilizar en tu actividad de desarrollador.
¿Se te ocurren más consejos? Compártelos en comentarios 😉
Un borrador de relaciones públicas te ayuda a organizar tus ideas y documentar tu progreso, mientras sigues trabajando en tu función.
La mejor manera de obtener una revisión rápida y eficiente es mantener sus relaciones públicas pequeñas y bien documentadas (con todo el contexto necesario). ¡También aumentará sus posibilidades de obtener relaciones públicas en el futuro al entregar un código excelente ahora!
Encuentre todos estos consejos y más, con más ejemplos de la vida real e información útil en mi libro gratuito Solicitudes de extracción y revisión de código: mejores prácticas para desarrolladores, desde junior hasta líder de equipo .
Ponte en el lugar de tu revisor, anticípate a las preguntas y comenta tu propio código cuando creas que puede ayudarle.
No asigne sus relaciones públicas al mundo entero. Elija a sus revisores cuidadosamente para obtener una reseña relevante, sin esperar demasiado para la aprobación.
Esté abierto a recibir comentarios, solicite aclaraciones, diga cuando no esté de acuerdo (con respeto) y responda siempre a los comentarios.
Todo el mundo tiene muchos RP que revisar y poco tiempo libre para hacerlo. Si revisa otros RP, aumenta las posibilidades de que el suyo también sea revisado.
Como desarrollador junior, puede informar a los demás cuando no comprende parte del código, ya que debería ser comprensible para cualquier desarrollador del equipo.
Más sobre esto en mi publicación ¿Cómo revisar el código como desarrollador junior? .
El objetivo de la revisión del código es detectar errores y casos extremos, y cuestionar la implementación. No debe usarse para criticar preferencias menores de formato o estilo, ni para discusiones arquitectónicas a gran escala.
Utilice “por qué no” en lugar de “debería”, sea abierto y positivo y sugiera siempre una alternativa cuando solicite un cambio.
No todos los comentarios requieren un cambio y no todos los cambios solicitados son necesarios para que se apruebe el RP. Sea claro en su comentario si el cambio no es urgente.
Antes de hacer pública su reseña, vuelva a leer cada comentario: verifique el tono que utiliza y asegúrese de brindar todo el contexto para ayudar al remitente de relaciones públicas.
No desea que el revisor espere su aprobación dos días después de realizar todos los cambios que solicitó. Cuando lo revise, asuma que lo aprobará tan pronto como se realicen todas las correcciones.
Cuando un hilo de comentarios se convierte en un debate en tu PR, será mejor que lo cortes y sugiera continuar la discusión en otro lugar, por ejemplo, en un hilo de Slack. Si es necesario, dedicarle una reunión y/o involucrar a un tercero.
¡Eso es todo! ¿Qué te parecieron estos consejos? ¿Se te ocurre algún consejo que te gustaría dar a otros desarrolladores?
Compártelos aquí en comentarios 👇
Si te gustaron estos consejos y quieres aprender más, consulta mi libro Pull Requests and Code Review , ¡es gratis!
También publicado aquí .