Cómo decirle a un compañero de trabajo que su código es malo y / o anticuado

Estoy de acuerdo con los otros colaboradores que han dicho que esto es principalmente un problema de estilo, en lugar de un código malo o anticuado. Y estoy de acuerdo en que puede haber beneficios al discutirlo con su compañero de trabajo.

Por mi parte, puedo ver al menos una ventaja clave de este estilo. Si se va a acceder a la matriz mediante un índice, lo cual es probable, la correspondencia entre el idex y el valor es bastante evidente. En comparación, el estilo que prefiera requiere contar las entradas, desde cero, para encontrar el índice de una entrada.

También evita que el texto salga del borde derecho de la ventana, donde debe desplazarse para poder verlo. Con los IDE modernos, todo el bloque de líneas se puede envolver en una directiva de plegado de código para que pueda colapsarla.

Mantener estas declaraciones en un archivo separado significa que los cambios en ellas se rastrearán por separado en el sistema de control de origen desde los cambios a la lógica. Por lo tanto, puede ver en el registro si se cambió la lógica o se cambiaron las constantes, y por quién y cuándo, sin tener que pasar por la tediosa tarea de comparar versiones en el nivel de origen para determinar qué se cambió.

En cuanto al tamaño del archivo, aunque el estilo de su compañero de trabajo requiere más líneas, no requiere más bytes. Un separador de línea requiere 2 caracteres en Windows (solo uno en Unix), mientras que una lista de inicializadores requiere 2 caracteres (uno para la coma y otro para el espacio) en ambas plataformas.

Un inconveniente de este estilo es que es más lento de analizar, pero la diferencia es, en el mejor de los casos, marginal, a menos que haya miles de elementos de matriz.

Uno de los colaboradores sugirió que debería tener derecho a cambiar el estilo de codificación una vez que sea responsable del código. Estoy de acuerdo con eso, pero con restricciones.

  • Primero, si hay un conjunto de estándares de codificación que debe cumplir, entonces debe seguirlos. Si no estás de acuerdo con ellos, entonces trabaja para cambiarlos.
  • Segundo, tenga en cuenta que tener estilos de codificación mixtos en el mismo cuerpo de código es el equivalente cognitivo de pasar de un camino pavimentado a un camino de grava. Es mejor ser consistente. Personalmente, no me importa demasiado si el estilo cambia incluso entre archivos, pero, por favor, ¡¡¡no dentro del mismo archivo !!! Entonces, si va a cambiar el estilo, cámbielo uniformemente dentro de un cuerpo cohesivo de código relacionado.

Además, sea sensible al hecho de que cambiar de estilo crea una incoherencia indeseable, para lo cual el remedio consiste en cambios más generalizados, cuyo resultado es mucho trabajo con quizás poco beneficio real, y con el riesgo adicional de introducir errores.

He estado en ingeniería de software durante cuarenta años y he administrado equipos de hasta 120 personas. Honestamente puedo decir que en todo ese tiempo no creo que me haya encontrado con un ingeniero que pensara que el código de otra persona estaba escrito de forma más limpia de lo que él o ella podría escribirlo. De hecho, como gerente, a menudo era bastante difícil lograr que los ingenieros resistieran la tentación de cambiar el estilo o el código de refactorización simplemente porque no les gustaba la forma en que estaba escrito. Y he tenido que lidiar con las consecuencias de tales cambios de código cuando resultaron en nuevos errores, o peor, la reaparición de errores viejos.

Esto se pone de moda y se trata menos de que esté desactualizado y más de que seas verde.

Con el tiempo, madurará y aprenderá que los estilos de codificación son altamente personales y que rara vez hay una “manera correcta” de codificar.

La otra cosa que aprenderás a medida que maduras es que muchas peleas no valen la pena.

Si está organizado y claramente entendido, está bien. Si ya existe y funciona, no te metas con él. O, para ponerlo en el lenguaje coloquial común, “si no se rompe, no intentes arreglarlo”.

Dicho esto, si usted tiene la responsabilidad total de una sección de código, entonces debería tener derecho a refactorizarlo como mejor le parezca. Cuando entrego las cosas como arquitecto jefe en un proyecto, * siempre * le digo al ingeniero que se lo entrego para que puedan reorganizarlo o recodificarlo cuando lo consideren necesario.

Lo primero que haría es escribir (o elegir uno existente) un conjunto de pautas y una guía de estilo para estandarizar la forma en que su equipo debe escribir el código. Le dirá a sus compañeros de equipo que para lograr una buena calidad de código y para facilitar la lectura a todos, debe seguir estas pautas en la misma medida que todos. Aceptará recomendaciones y cambios si alguien se lo pide, y elegirá democráticamente el camino a seguir. Creo que esta es la forma en que quiero que mi jefe maneje tal cosa.

Si funciona y no causa problemas a nadie, entonces déjalo en paz .

Todo el código se vuelve anticuado y todos los estilos terminan siendo preferencias personales. Por lo tanto, es mejor no imponer a los demás si hacen el trabajo.

Sin embargo, para su ejemplo anterior, parece que él puede no tener una preferencia. Así que es posible que desee compartirlo como un consejo amistoso.

No soy programador, pero dos programadores han dicho que esto es un problema de estilo y no un problema de calidad, y confío en eso.

Sin embargo, no soy malo para hablar con la gente, así que responderé a tu pregunta directamente.

Siéntate con él y dile: “Lo estás haciendo de esta manera. Lo haría de otra manera. ¿Me enseñarías las ventajas de tu camino? ¿Ves alguna ventaja en cómo lo hago?”

Al menos uno de ustedes aprenderá algo. Quizás ambos lo hagan.

No hay nada de malo en su código. Es sólo una cuestión de estilo. De hecho personalmente encuentro su código más legible.