- Las revisiones de código (además de escribir revisiones) requieren dos cosas: un revisor que ofrece críticas constructivas y con respeto, y un revisor que acepta las críticas con gracia y sin demasiado ego (se les permite defender una opción de codificación, pero no lo hacen) No es necesario estar a la defensiva). Esto requiere práctica por ambas partes . Piense en ello como una práctica de artes marciales. La persona que practica un lanzamiento de Aikido está perfeccionando su habilidad, pero la persona que está lanzando (el “Uke”) también está desarrollando una habilidad de ser lanzado sin lastimarse. Puede ser útil reconocer que ambas partes necesitan practicar habilidades para participar en una revisión de código. Va en ambos sentidos, por supuesto; todos tienen su turno de ser el Uke.
- El revisor nunca debe hacer una crítica personal sobre la persona que escribe el código, sino centrarse en cómo podría mejorarse el código. Nunca le digas al codificador: “No puedo creer que no sepas cómo hacerlo “. Recuerde que todos comenzaron sin saberlo, incluso usted. Sea paciente y explique por qué algún cambio es una mejora. Tendrás que explicarlo más de una vez, y está bien.
- Concéntrese en el código mejorado, no en el código incorrecto. En lugar de: “este código es horrible porque no puede verificar los estados de error”, intente: “es mejor verificar los estados de error más cercanos al lugar donde se crearon”. Mantenlo constructivo.
- Deje el estilo de codificación en la puerta. Recuerde que hay más de una forma de hacer cualquier tarea. Es posible que alguien haya usado un bucle donde usted hubiera usado la recursividad. O utilizaron argumentos opcionales donde habría utilizado firmas de métodos. La mayoría de las veces, llamar a estos problemas estilísticos no puede ser apoyado, y tratar de “corregirlos” se convierte en argumentos subjetivos. Aprenda a dejar ir algunos o la mayoría de estos. No hacen ninguna diferencia, y tiene un tiempo limitado para hacer la revisión del código, por lo que debe centrarse en algo que marque la diferencia.
- Intente usar un poco de gamificación para que la revisión del código sea más centrada. Esto puede distraer de las cosas estilísticas subjetivas y del ataque personal y mantener a todos enfocados en el código.
Por ejemplo, cree algunos tipos de mejoras de código canónicas, como la corrección , la seguridad , el rendimiento y el diagnóstico . Luego, a medida que encuentre problemas de código durante la revisión, haga que sea un juego para las personas en la mesa nombrar en cuál de estas categorías se encuentra el problema de código. Si no entran en ninguna de estas categorías, tal vez no sea realmente un problema.
Cómo evitar parecer un imbécil durante una revisión de código
Related Content
¿A qué empresa debo unirme para formarme como ingeniero mecánico?
Cómo pasar a la industria de TI desde el campo de investigación clínica
¿Conseguiré un trabajo técnico ya que conozco los conceptos básicos de Java?
¿Cómo es trabajar en el Instituto Nacional de Oceanografía? ¿Qué hacen ellos allá?
Sé que esta es la respuesta más cliché, pero todo depende de múltiples factores: su experiencia, sus estándares de codificación, su enfoque hacia la codificación en general (religión vs. practicidad), etc.
En mi opinión, la revisión de código se trata de dos cosas:
- Aprendizaje El desarrollo de software se trata de aprender cosas nuevas. Constantemente. Tener su código revisado por otro desarrollador es la mejor manera de hacerlo.
- Mejorando tu código . Mejor código significa aplicación segura y mantenible.
Sin embargo, si se hace incorrectamente, la revisión del código podría convertirse en la peor parte del trabajo de sus colegas. Entonces, ¿cómo lo evitas?
- No lo hagas personal. No se trata de ellos, se trata de su código.
- Dar opinion. Proporcione comentarios valiosos en lugar de ataques sesgados.
- No te concentres en cosas tontas. Esa pestaña faltante no es una razón para que te vuelvas loco.
- El código no es una religión. Puede ser para ti, pero no todos piensan lo mismo. Si hay ciertos estándares que desea que mantenga su equipo, DÍGALOS al respecto.
Recuerde que puede hacer muchas cosas antes de ejecutar una revisión de código de pares. Aquí hay dos cosas que creo que los buenos equipos de desarrollo de software deberían incluir en su flujo de trabajo:
- Abrazando guías de estilo . Aunquebot presentó una gran guía de estilo que realmente me gusta.
- Configuración de linters en IDEs y en CI . Porque la fijación del código comienza en su editor.
En codequest, utilizamos un sistema de revisión de código mixto. Combinamos la revisión de código manual y automatizada para obtener los mejores resultados. Puedes leer más sobre esto aquí.
Y si está buscando una gran herramienta que lo ayude con la revisión de su código, puede probar codebeat; ¡10 idiomas compatibles, integración Git, integración Slack & HipChat y más!
Las revisiones de código son sobre código; Las evaluaciones de rendimiento son sobre codificadores.
Si te encuentras pensando “este tipo es un idiota”, respira hondo, luego otro, luego un tercero, luego pregúntale al codificador “¿qué hace exactamente este fragmento de código?”
Si eso no fuera suficiente, intente guiarlos verbalmente por el código paso a paso, haciendo preguntas importantes hasta que comprendan los problemas con su código.
Si su paciencia aún se agota después de todo esto, ofrezca que revisen su código. Luego tiene la oportunidad de mostrarles cómo se debe escribir el código, guiándolos por todas las “mejores prácticas” que aplica en su código … y posiblemente comer un pastel humilde cuando detectan errores estúpidos en sus cosas. Es útil si alguien mayor para usted también participa en la revisión, para maximizar la probabilidad de humillación personal.
Prefacio cada comentario agudo que desee hacer con: “Oh, sí, he cometido ese mismo error una docena de veces, una vez que le costó a la compañía $ 300,000”. Todo el mundo está constantemente tentado a tomar atajos, evitar la verificación de errores, introducir errores 1,2,3, violar los límites de la matriz, pérdida de memoria, causar condiciones de carrera, bucles infinitos, variables no configuradas, variables globales innecesarias y todas las demás trampas. son propensos a.
También agregue “¿ve algo divertido alrededor de la línea 166?” o “¿es prudente usar excepciones de esa manera?” o “¿un pequeño factoring acortaría el código?”. Dales la oportunidad de encontrar el error ellos mismos. Nunca los llame idiotas, cobardes, novatos o tontos. Ahí, pero por la gracia de Dios ve.
Me gustan todas las respuestas hasta ahora.
Últimamente he intentado experimentar con formatos de revisión de código y ofrecer un proceso ligeramente diferente. Mi intención para cambiar el proceso de revisión del código era lograr una mayor participación de los equipos y compartir el conocimiento entre una audiencia más amplia. Encontré que el miedo a las personas de no querer ser un imbécil es un factor nuevo que limita la participación en formatos de revisión de código más tradicionales. Creo que es un artefacto de la generación de la estrella de oro Gen Y. No creo que las generaciones más antiguas de programadores hayan tenido miedo o tal vez sean lo suficientemente conscientes de sí mismos como para considerar el estado de ser un imbécil.
El experimento es hacer que el autor lidere la revisión del código. Esto es algo relativamente nuevo que he implementado en algunos equipos y parece prometedor, pero es un poco pronto para decirlo.
El revisor debe criticar su propio código, hablar sobre por qué hicieron compromisos, cómo cumplieron el SLA y los objetivos. Durante la revisión del código, pueden hablar sobre cómo el código será re-factorizado en futuros sprints y qué deuda tecnológica han contraído. Cuando presentan el código a un grupo, todos tienen el estilo de un foro y todos podemos parar y hablar sobre cualquier parte del código según sea necesario.
Cuando inicié este proceso con mi propio código, fui muy duro con mi propio código y encontré que el foro defendía mis críticas como compromisos razonables. Esto marcó la pauta de cómo iban las cosas. El autor suele ser el crítico más duro y el foro escucha y generalmente defiende las elecciones. Parece aumentar el compromiso y la gente parece más consciente de lo que hay en el repositorio. Incluimos BSA’s y soporte técnico en los foros. No participan tanto con las críticas técnicas, pero pueden escuchar qué se publica y cómo. Por lo general, están muy cerca del negocio y pueden validar los entregables desde el punto de vista comercial. Ocasionalmente, el foro presenta formas alternativas de hacer las cosas que tienen sentido y se implementan. Este parece ser un indicador de que el proceso podría estar funcionando.
Quizás este no sea un formato nuevo para todos o la diferencia es solo sutil, pero me parece novedoso.
Este es un problema que vi cuando dirigía un equipo de ingenieros en una startup en Portland, OR. Pensé que había un montón de cosas quisquillosas que tenía que hacer, como “No nombraste esto en línea en nuestra guía de estilo” o “Eliminar esta importación no utilizada”, lo que se sumó y me hizo sonar como si estuviese molestando. Dicho esto, esto es realmente útil por razones de consistencia.
Mi solución a esto fue que escribí un robot que haría una gran cantidad de nitpicking automáticamente, que está en https://betterdiff.com . Todo esto está respaldado por una biblioteca de código abierto que puede encontrar en github llamada imhotep, justinabrahms / imhotep. Los complementos son muy fáciles de escribir, así que tal vez eso te ayude.
Consulte el código como un objeto y evite los posesivos. Decir “este código no está haciendo X correctamente” es menos duro que “su código no está haciendo X correctamente”.
Dado que una revisión de código es, por definición, un procedimiento algo negativo, le irá mucho mejor con los ingenieros al mantener un poco de ficción de que el código se escribió de alguna manera al hacer comentarios duros al respecto en lugar de decir “sux de código de Kyle”. Sí, el programador que lo escribió sabe exactamente lo que está sucediendo, al igual que todos los demás en la mesa, pero mantendrá la temperatura mucho más baja si mantiene a las personas y el código separados en sus discusiones.
Y siguiendo el comentario de Quora User de que cometiste una maldad similar en el pasado es una buena manera de mantener las cosas agradables y evitar sonar acusatorio u oficioso.
More Interesting
Cómo convertirse en piloto comercial después de completar mi BTech de India
Cómo comenzar una carrera en redacción de contenidos
¿Qué cosas debo tener en cuenta antes de ir a una entrevista de trabajo?
¿Por qué el técnico sabe más que el ingeniero?
¿Cómo puede un título de MBA ayudar a un ingeniero estructural?