Cómo trabajar con un desarrollador que siempre critica su código solo por una cuestión de estilo y diseño cuando realiza la revisión del código

Answer 1

Tu pregunta es un poco corta de detalles, así que voy a tener que asumir que tu código es el único que está siendo criticado de esta manera. Si planea trabajar en un entorno de grupo, tendrá que aprender a usar las convenciones de codificación que usa el resto del grupo.

Esto es parte de la razón por la cual las personas usan las convenciones de codificación. Una vez trabajé en un proyecto grupal para la escuela, donde se nos asignó la tarea de expandir otro proyecto mediante una GUI. Nos dieron el código fuente del otro proyecto y eso fue todo. No había ninguna documentación de ningún tipo (ni siquiera comentarios). Uno de los mayores problemas que tuvimos fue leer el código fuente. Conté cinco convenciones de codificación diferentes en el código fuente que se nos dio.

Mantener una convención de codificación constante para un proyecto de grupo debería facilitar la lectura del código. Te permite decir cosas sobre el código con solo echarle un vistazo (una vez que te acostumbras a la convención). Mantener sus “if”, “else”, “for”, etc., etc., bajo la misma convención, hará que sea más fácil para su cerebro recoger dónde comienzan y terminan sin leer el código real. Si está trabajando en un proyecto de grupo y su convención de codificación no coincide con el resto del grupo, entonces el resto del grupo tendrá que detenerse un poco en cada ubicación que no coincida con su convención de codificación. Esto se debe a que pueden necesitar un poco de tiempo adicional para analizar su código en esos lugares. Esto desperdiciará su tiempo, y realmente puede molestarlos, si se toman el tiempo para escribir su código para que coincida con la convención de codificación que está en uso.

Dicho esto, he conocido gente que no ajustará su convención de codificación para nadie porque su código ya está escrito de la forma en que quieren que se vea su código. Estas personas no siempre son las más fáciles de trabajar. He trabajado con alguien que era un poco así. No estaba tan dispuesto a usar las convenciones de codificación que no le gustaban, pero no criticaba a nadie (a menos que usted estuviera comparando el código) por usar una convención de codificación diferente. Una cosa que criticaría es si una persona cambiara las convenciones de codificación en medio de su código fuente.

Answer 2

Yo diría, introducir la técnica de código de programación de pares en el equipo que puede eliminar esta condición.

En esta técnica, dos programadores trabajan juntos en una misma estación de trabajo. Uno escribe código mientras que el otro, el observador , el puntero o el navegador , revisa cada línea de código a medida que se escribe. Los dos programadores cambian de rol con frecuencia.
De esta manera, la codificación y su revisión se realizan al mismo tiempo por 2 programadores simultáneamente.
Algunos dicen que 2 desarrolladores que trabajan en el mismo código al mismo tiempo no tienen ningún sentido, ya que terminarán gastando el doble de horas. Puede llevar a problemas con la implementación práctica de la técnica.
Pero lo bueno es que no necesitan pasar más tiempo para comprender y realizar la revisión del código. Se quita la comunicación entre desarrolladores. Ni siquiera necesita otra herramienta para obtener ayuda adicional para enviar un parche.

Answer 3

Las pautas de revisión deben incluir estar familiarizado con el libro de Jerry Weinberg sobre revisiones (me olvido del título).

Si percibes los comentarios del desarrollador como una crítica, o hay algo mal con sus comentarios o hay algo mal con tu percepción.

Las revisiones de código siempre deben ser eventos positivos. Si un desarrollador no entiende que no debería ser un revisor.

Conocer

Answer 4

Sí, es frustrante cuando el revisor se enfoca en las cosas insignificantes como el espacio que falta entre el refuerzo de apertura y el de apertura y falla al apreciar el bloque de código que escribiste para resolver el problema de una vez por todas.
El código que usted escribió es totalmente legible para usted, sin embargo, el revisor le pide que difiera, ya que tiene el contexto del código que usted escribió, que su revisor podría o no tener. Si lees tu propio código después de 6 meses, estoy seguro de que no será tan aparente como lo es para ti ahora.
Imagina que mantienes o intentas corregir un error en otro código que tiene un bloque de código igualmente bueno para resolver el problema, pero los nombres de las variables utilizadas no son significativos, el código no está formateado, es extremadamente difícil para ti leer el código, y como el código no está bien documentado, no tiene idea de cómo el bloque de código “cool” resuelve el problema para la mayoría de los casos y para algunos casos no es lo que está intentando solucionar. ¿Ves el problema?
El truco aquí es que no te adjuntes a tu código. Tú y yo queremos ser buenos desarrolladores, si nos unimos al código que escribimos, estamos inclinados hacia él, no queremos ver nuestras fallas, si ni siquiera admitimos que hay fallas, ¿cómo vamos a hacerlo? mejorarlo y ser el desarrollador genial que pretendemos ser.
Si está utilizando IDE, es posible que también desee verificar los complementos de estilo de verificación y dejar el trabajo de formatear su código en el IDE y centrarse en escribir el bloque de código que usted escribe.
¡Espero eso ayude!

Answer 5

Necesita tener algunas pautas de codificación y revisión de código.

En algunos lugares podrían ser “simplemente escribir código que funcione, no nos importa cómo, siempre y cuando funcione”.

Otros lugares tendrán un manual de estilo de 50 páginas que especifica la posición de cada coma, espacio y tabulador.

Luego habrá menos sorpresas a la hora de revisar el código.