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 , pero aquí encontrarás una vista previa de estos 13 consejos, que ya puedes utilizar en tu actividad de desarrollador. Pull Requests and Code Review ¿Se te ocurren más consejos? Compártelos en comentarios 😉 1. Cree su PR antes de que el código esté listo para su revisión. Un borrador de relaciones públicas te ayuda a organizar tus ideas y documentar tu progreso, mientras sigues trabajando en tu función. 2.Haz que la gente quiera revisar tus relaciones públicas 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 3. Sea el primer revisor de sus relaciones públicas Ponte en el lugar de tu revisor, anticípate a las preguntas y comenta tu propio código cuando creas que puede ayudarle. 4. Asigne los revisores adecuados a su PR 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. 5. Sea receptivo a los comentarios Esté abierto a recibir comentarios, solicite aclaraciones, diga cuando no esté de acuerdo (con respeto) y responda siempre a los comentarios. 6. Si quieres que la gente revise tus relaciones públicas, debes revisar las de ellos. 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. 7. Puedes revisar el código incluso si eres un desarrollador junior. 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? 8. Verifique lo correcto durante la revisión del código 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. 9. Utiliza el tono adecuado en tus comentarios Utilice “por qué no” en lugar de “debería”, sea abierto y positivo y sugiera siempre una alternativa cuando solicite un cambio. 10. Sea claro sobre si se requiere un cambio para aprobar el RP o no. 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. 11. Revise su reseña antes de enviarla. 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. 12. Apruebe el PR cuando el remitente haya realizado todos los cambios que usted solicitó. 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. 13. Algunos conflictos no se pueden resolver en comentarios. 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 , ¡es gratis! Pull Requests and Code Review También publicado . aquí
