Estoy trabajando como desarrollador frontend y un nuevo colega se unió a mi equipo. Él tiene más experiencia que yo, pero tengo más conocimiento sobre la aplicación en la que estamos trabajando.
Así que estamos haciendo la revisión del código de cada uno de los demás y sé que él está muy interesado en diseñar el código y ser consistente en toda la aplicación.
Ahora revisé su código e hice algunas sugerencias sobre algunas convenciones y estilos de código y siempre di la razón por la que creo que esto es mejor.
Respondió a mis sugerencias básicamente diciendo que no está de acuerdo y dando algunos ejemplos.
Luego respondí su declaración nuevamente usando estos ejemplos y tratando de explicar nuevamente por qué lo prefiero de la manera que sugerí.
Luego respondió que le gustaría posponer esta discusión. Supongo que todavía no está de acuerdo conmigo y nunca lo adivinaré. Y creo que esta discusión nunca volverá a surgir.
Mi pregunta es ¿cómo puedo hacer que esté de acuerdo conmigo sin forzarlo? ¿Y qué debo hacer cuando él nunca estará de acuerdo con mis puntos? Tampoco me gusta que haya decidido posponer esta discusión. ¿Debería preguntarle cuándo lo discutiríamos entonces?
Esto sucede en casi todas partes (para que no estés solo), te daré el consejo que les doy a todos:
Deje de comentar sobre ideales estilísticos/cosméticos en sus revisiones de código.
Sí, sería bueno si una base de código fuera estilísticamente consistente, pero la realidad es que eso nunca sucederá cuando dos o más personas trabajen en un proyecto. Puede comenzar de esa manera, pero nunca terminará de esa manera. Aquí hay una lista de lo que busco al hacer una revisión de código en orden de importancia:
Si paso por todo el proceso de revisión de código y no encuentro nada que no se ajuste a esas 4 cosas, entonces podría comentar sobre el estilo y dejar muy claro que es solo mi preferencia. Hago esto porque no creo que una revisión de código deba contener sugerencias para el autor. Mientras el código tenga sentido, no comentes sobre el estilo a menos que literalmente no haya nada más que comentar.
Incluso entonces, esto es realmente solo para mostrar que, de hecho, leyó el código y es capaz de hacer sugerencias. Si el compañero de trabajo no quiere implementar el enfoque estilístico que recomendó, déjelo en paz (a menos que cause problemas de legibilidad o sea confuso hasta el punto de refactorizar).
En mi opinión, si la revisión de su código consiste principalmente en diseñar, es posible que no lo esté revisando lo suficiente. Puedo contar con los dedos de una mano la cantidad de veces que solo pude comentar sobre el estilo.
El aspecto importante es eliminar la discusión 'él dijo, yo dije' fuera de la ecuación.
Necesita algunas cosas en su lugar;
Los estándares de codificación son importantes. Todavía hay espacio para la individualidad en la forma en que se escribe el código, pero tener un conjunto básico de estándares de codificación significa que los futuros desarrolladores pueden ponerse al día con la base del código rápidamente.
Tendrá una gran deuda técnica en la base de código existente, pero eso está hecho y funcionando: avance, no retroceda . Esa deuda técnica existirá como un proyecto de "mojarse los pies" para cualquier futuro desarrollador que se una al equipo.
adam cooney
anonimoSO
nathan cooper