¿Deberían mis colegas revisar el código del sistema de control de origen?

Esa es mi historia: uno de mis colegas lo utiliza para revisar todo el código, alojado en el sistema de revisión. No estoy hablando de una revisión adecuada de los cambios en las partes a las que pertenece. Él mira el código archivo a archivo, línea a línea. Cada archivo nuevo y cada modificado. ¡Tengo ganas de ser espiado!

Supongo que si el código ya estaba alojado para controlar el sistema, al menos debería confiar en que sea viable. Mi pregunta es, ¿tal vez soy demasiado paranoico y la práctica de revisar el código de los demás es buena?

PD: Somos un equipo de solo tres desarrolladores, y me temo que si hay más de nosotros, el colega simplemente no tendrá tiempo para revisar todo el código que escribiremos.

¡Yo diría que sí!

Dos razones rápidas para ello:

1) Si el código está en producción, no puede asumir que es correcto. Cualquier cambio en otra parte del sistema puede introducir errores. Creo que es muy importante que el código se verifique regularmente. De esta manera, la refactorización se realiza de forma regular, manteniendo el código ordenado y "más" correcto (probablemente la actualización sea mejor).

2) Poder leer código es una habilidad muy importante si vas a ser programador. Y es una habilidad, algo en lo que necesitas trabajar. Para cualquier programador que comience a trabajar en una base de código existente, si no está acostumbrado a leer el código de otras personas, hay una curva de aprendizaje empinada que intenta ponerse al día con lo que está sucediendo.

No creo que debas sentirte espiado. Acepta cualquier crítica que alguien te haga (si es válida, por supuesto). Y siéntase libre de dar una crítica VÁLIDA a otras personas. Es la forma en que aprendemos. Una vez que dejamos de aprender (o queremos parar), entonces hay grandes problemas.

Si dicho colega proporciona comentarios buenos y constructivos, esto es algo fantástico y usted debería apreciarlo mucho.

Este SERÁ atrapar insectos que no piensa cuando escribirlo. Esto dará como resultado que escriba un código mejor porque sabe que otros lo verán.

Sería saludable si todo el equipo realiza revisiones de código en lugar de una sola persona. Idealmente, todos invitarían a alguien a revisar su código una vez completado. Es útil mantenerlo informal (mantener alejados a los gerentes) y dejar que el revisor le cuente sobre sus hallazgos. Idealmente, el revisor solo ofrece comentarios y no realiza cambios en el código, por supuesto, podría emparejarlo un poco.

Realmente ayuda tener estándares de codificación para evitar que las discusiones de revisión sean sobre espacios en blanco y estilo de código constantemente. Tener un análisis de código estático en una máquina de compilación puede ser útil para mantener algunas discusiones también.

Sobre el aspecto del tiempo, la teoría es que le ahorrará tiempo. Las fallas posteriores se encuentran cuanto más caras se vuelven, el principio de falla rápida. La revisión del código de pares puede detectar bastantes problemas.

Su colega suena como un desarrollador diligente, debe seguir su ejemplo.

Miro nuestro sistema de control de versiones de manera similar. Nuestra base de código es demasiado grande para ver todas las líneas, pero trato de obtener una sensación de alto nivel para la mayoría de los cambios. También miro los registros que tienen más probabilidades de tener efectos secundarios y los reviso línea por línea. Por el tiempo mínimo que paso haciendo esto, la recompensa es enorme. (También tenga en cuenta: no soy el único desarrollador en nuestro equipo con este hábito).

Este tipo de revisión tiende a detectar errores o invocar debates semanalmente. Eso ahorra tiempo al hacer QA. Las discusiones abarcan desde las mejores prácticas hasta el diseño de algoritmos y más. La clave en este frente es que todos lo ven como constructivo.

Personalmente, también me da una mejor comprensión de lo que está sucediendo en otras partes de la base de código que no toco regularmente. Cuando otros necesitan ayuda, puedo saltar más rápido. Además, cuando aparecen nuevas ideas, puedo aprovecharlas antes.

¿Sientes que te espían (!)? Pero desde la perspectiva de su colega, diría que está haciendo lo correcto para el desarrollo de su carrera. Lea el código de otros y descubra cómo diseñan e implementan la lógica, ¡esto le hará ganar mucho!

En mi humilde opinión, si alguien señala algo mal en su código, debe aceptarlo y aprender de ellos sobre cómo escribir un buen código

Durante 6-7 meses estuve haciendo lo mismo. No para espiar, sino para controlar la calidad. Cada línea del código para una aplicación desarrollada activamente, comprometida con el repositorio central, 2 idiomas principales, algunos otros idiomas, enormes archivos MAKE para 4 plataformas.

Es muy mala práctica . Algún día descubrí que no puedo capturar todo debido a la robustez. El otro argumento en contra de esto es la subjetividad: todos pueden equivocarse.

Es mejor cuando los desarrolladores revisan los códigos de los demás y hay alguien con experiencia para tomar decisiones finales y definir direcciones.

Las revisiones de código dentro de un equipo (usando ojo de pez , crisol u otras herramientas) son extremadamente importantes y útiles. Lo único mejor es la programación directa de pares para asegurarse de que el código que ingresa al sistema la primera vez esté bien pensado y haya pasado por el cerebro de más de una persona.

Esto sucedió en mi equipo una vez. Lamentablemente resultó en un juego de culpa. La gente continuamente esperaba que otros revisaran el código y siempre intentaban encontrar algo incorrecto y jugaban al juego de la culpa todo el tiempo.

Espero que tengas una audiencia más madura.

Esta es una práctica bastante estándar en la industria. Las compañías en las que he trabajado tienen pautas de revisión de código muy estrictas. Incluso uno no le permitiría comprometerse a menos que se haya revisado el código.

No te ofendas ni te sientas vigilado. Piense en ello como una red de seguridad y una experiencia de aprendizaje.

En un trabajo anterior, el desarrollador senior observaba y revisaba todos los registros y con frecuencia recibía excelentes comentarios que me ayudaban a ser un mejor desarrollador.

En mi trabajo actual, miro muchos de los registros y hace tres días encontré un error y notifiqué al desarrollador.

Esta práctica atrapará errores y mejorará a todo su equipo, si lo acepta.