¿Cómo me acerco a un compañero de trabajo sobre la calidad de su código? [duplicar]

47

Trabajo en una nueva empresa en una gran empresa de software empresarial (más de 3000 programadores). En mi grupo, tenemos un montón de proyectos y la gente suele trabajar en varios proyectos en el transcurso de un año.

Acabo de comenzar a trabajar en un proyecto que ha sido mantenido anteriormente por un amigo mío (consultor que ha estado con nosotros durante más de 3 años) para agregar algunas características. Me metí en el código, y la calidad era bastante mala. Ya sea en la interfaz de usuario de la interfaz de usuario o en el de servicios, el código simplemente no tenía sangría, había cientos de líneas comentadas sin razón aparente, la documentación era básicamente inexistente, los estándares de codificación no se aplicaban de manera consistente (por ejemplo, mezcla camelCase y under_scored_variables ), los nombres de las variables fueron ininteligibles, las opciones de tipo de datos fueron incorrectas, etc. etc.

Soy una persona muy poco conflictiva, por lo que no quiero atacar a mi compañero de trabajo, pero tampoco quiero ir a mi jefe y quejarme de su desempeño. ¿Qué tipo de cosas puedo decir para mencionar educadamente que el código está mal estructurado?

EDIT:

Quiero aclarar que si bien entiendo que hay un elemento de "el código de todos los demás apesta" para todos los programadores, cuando veo algo como esto (los nombres se eligen a propósito y algunos detalles se omiten / se modifican en este ejemplo):

public void doCalculate(Object argument) {
  if (argument instanceof String) {
    String argument2 = (String) argument;
    if (argument2 == "DataBase") {
      // do something
    } else {
      long argument3;
      try {
        argument3 = Long.parseLong(argument2);
      } catch (Exception e) {
        argument3 = -1;
      }
      // do something completely unrelated
    }
  }
}

Creo que es objetivamente justo decir que esto no es una buena idea no . Además, no estoy tratando con un novato aquí (solo estoy codificando 3 años ahora). Él tiene tal vez 20 años de experiencia en mí. El consejo que ustedes han dado hasta ahora es genial; solo quiero asegurarnos de que no estamos hablando de una "línea fina" aquí.

    
pregunta daveslab 11.01.2012 - 18:27

11 respuestas

44

Pídale que le explique su código

Dígale que nunca ha visto a X programado de esa manera, y pregúntele por qué lo codifica de esa manera. Muéstrale cómo lo codificas y explica por qué lo haces de esa manera (mejores prácticas, mejor rendimiento, menos posibilidades de errores, más fácil de leer / mantener para otros programadores, etc.).

Asegúrese de preparar todos sus argumentos por adelantado y concéntrese en por qué su método es mejor en lugar de por qué su método es peor. Luego, ve si aún apoya su método sobre el tuyo.

Si está abierto a la mejora, es probable que cambie su forma de codificación. Si aún prefiere usar su estilo de codificación sobre el tuyo, es probable que no cambies su opinión.

Esta es exactamente la misma respuesta que di a la pregunta ¿Cómo decirle a su jefe que su estilo de programación es realmente malo? . Originalmente voté para cerrar esta pregunta por duplicado, sin embargo, suficientes personas pensaron que era lo suficientemente diferente como para justificar su reapertura. Sin embargo, mi respuesta sigue siendo la misma, independientemente de si está hablando con un jefe o un compañero de trabajo.

    
respondido por el Rachel 11.01.2012 - 20:02
14

¿Qué pasaría si, en lugar de acercarse a él personalmente, se acerque al equipo y de manera totalmente neutral proponga que el "equipo" cree una norma / directrices de codificación para que los diferentes miembros del equipo trabajen de manera más eficiente con el código de cada uno?

Una vez que esté en su lugar, creo que el código que le preocupa subirá a la cima por sí solo.

Las revisiones de código de pares también ayudan en esta área. Los estándares de codificación no tienen mucho beneficio si nadie mira el código. Pero las revisiones de código de pares tienen muchos otros beneficios, la transferencia de conocimiento principal, por lo que debe presionar para introducirlos en cualquier caso.

Supongo que incluso si tiene más de 3000 ingenieros, tienen sub equipos MUCHO más pequeños que trabajan juntos como una unidad

    
respondido por el DXM 11.01.2012 - 20:01
11

Primero, todos piensan que el código de otras personas apesta.

Segundo, tal vez heredó el código de alguien / en otro lugar O este era un prototipo que nunca pretendió ser el código utilizado para el proyecto real, pero por supuesto, eso fue lo que terminó siendo usado.

Tercero, tal vez su código realmente apesta pero ¿es tu trabajo hablar mal de los desarrolladores anteriores? A menos que haya adquirido una reputación que genere respeto en la empresa, sospecho que si se queja del código de la otra persona, será usted quien terminará viéndose mal y no su amigo. El momento para hacer que las personas se preocupen por su código es cuando se llevan a cabo las revisiones del código. Al menos entonces es parte de sus responsabilidades laborales.

Recomiendo que si no te gusta su código, lo arregles a tu gusto. Luego, el siguiente desarrollador vendrá y se quejará de tu código y probablemente lo modificará para que se parezca más a lo que hizo tu amigo.

    
respondido por el Dunk 11.01.2012 - 20:14
11

Es probable que su compañero de trabajo no sea la causa raíz del problema en su empresa. La razón por la que el código de baja calidad entra en producción es la falta de estándares de codificación medibles automáticamente en su empresa. En este caso, la luz solar es la mejor medicina.

Debe hablar con su líder técnico sobre la implementación de métricas de calidad de código fuente automatizadas en su grupo. El sistema debe ejecutarse por lo menos semanalmente, enviar por correo electrónico a todos los integrantes del equipo una lista archivo por archivo de violaciones de codificación estándar y enviar un resumen ejecutivo a su jefe. El resumen debe contener el número de violaciones por proyecto.

En mi experiencia, todo lo que se mide y se reporta a un jefe mejora con el tiempo.

    
respondido por el dasblinkenlight 11.01.2012 - 20:16
11
  

... el código simplemente no tenía sangría, había cientos de líneas comentadas sin razón aparente, la documentación era básicamente inexistente, los estándares de codificación no se aplicaban de manera consistente (por ejemplo, mezclando camelCase y under_scored_variables) , los nombres de las variables eran ininteligibles, las opciones de tipo de datos eran incorrectas ...

Por lo que puedo decir, las coincidencias anteriores # 12, # 9, # 5, # 2 y probablemente # 7 de Top 12 cosas que probablemente se escucharán si tienes un Programador Klingon (archivo) [ enlace original ] :

  

12. ¡Las especificaciones son para los débiles y tímidos!
  11. ¡Esta máquina es una pieza de GAGH! ¡Necesito procesadores Pentium duales para luchar con este código!
  10. Realmente no puedes apreciar a Dilbert a menos que lo hayas leído en el original Klingon.
  9. ¿Sangría? - ¡Te mostraré cómo sangrar cuando sangre tu cráneo!
  8. ¿Qué es esta charla de 'liberación'? Los klingons no hacen "lanzamientos" de software. Nuestro software "escapa", dejando tras de sí un sangriento rastro de diseñadores y personas de garantía de calidad.
  7. Las llamadas a la función Klingon no tienen 'parámetros', tienen 'argumentos', y SIEMPRE LOS GANAN.
  6. ¿Depurando? Los klingons no se depuran. Nuestro software no mima a los débiles.
  5. He desafiado a todo el equipo de control de calidad a un concurso de Bat-Leth. No nos volverán a preocupar.
  4. ¡UN VERDADERO guerrero klingon no comenta su código!
  3. Al presentar esta PTR, ha desafiado el honor de mi familia. Prepárate para morir!
  2. ¿Cuestionas el valor de mi código? ¡Debería matarte donde estás!
  1. ¡Nuestros usuarios conocerán el miedo y se encogerán ante nuestro software! ¡Envíalo! ¡Envíalo y déjalos huir como los perros que son!

Es bastante probable que la única forma de evitar la confrontación sea un unidad de warp en otro cuadrante espacial .

    
respondido por el gnat 12.01.2012 - 14:04
3

Obtenga información sobre lo que estaba sucediendo dentro de la empresa y el equipo cuando se escribió este proyecto. Pregúntele a este desarrollador por algún comentario sobre cómo pensó que fue el proyecto. ¿Ha cambiado su estilo? Si se le da la oportunidad, ¿qué haría de manera diferente?

Puede estar de acuerdo con sus estándares, pero no tuvo el lujo de aplicarlos durante la creación de esta aplicación o simplemente no sabía de ellos.

Su grupo no tiene normas o políticas de revisión de códigos o un problema serio con la aplicación. Puedes tener una opinión de uno.

    
respondido por el JeffO 11.01.2012 - 20:32
3

Lo admito, a veces soy ese tipo. Cuando lo esté, tendré mis razones, generalmente restricciones de tiempo, proyectos de marcha de la muerte, instrucciones como "ahora, no perfecto", etc. Muy raramente, es debido a un mal día. Me complace que me pregunten sobre cualquier problema, me da la oportunidad de convertirme en un mejor desarrollador. Siempre que: a) Usted sea razonable con respecto a lo que se cambiará (no se rompa tan mal, acepte no arreglarlo), yb) no sea un dictador loco que crea que su manera es la única.

Para acercarme a mí al respecto, no preguntes "por qué". Por qué es una palabra de lucha, un desafío y, en última instancia, es destructivo. Si te encuentras usando Por qué demasiado, cámbialo a I. "Por qué llamaste a esto" se convierte en x ", habría utilizado el índice, es más descriptivo que x".

La mejor manera es indicar lo que habrías hecho o hubiera preferido. Explique que lo que está viendo no cumple con ciertos estándares y que le gustaría verlo mejorado. Mi conjetura es que el 99% del tiempo, la respuesta será "yo también, pero ........"

    
respondido por el mattnz 11.01.2012 - 21:42
1

Es poco probable que el autor del código regrese para arreglar su código por usted de buena voluntad, o que su empleador le pague para que lo haga. Entonces, de cualquier manera, eres scr * wed.

Si cree que el desorden en el que se encuentra el código tendrá un grave efecto perjudicial en su desempeño mientras trabaja en él, asegúrese de guardar una copia de respaldo del código original en algún lugar para poder demostrar que fue un desastre cuando fue entregado a usted. Por lo tanto, si su empleador lo confronta más adelante por su bajo desempeño, puede cubrir su trasero.

Aún así, puede parecerle a tu empleador una excusa, así que trata de evitar que eso suceda, si puedes.

    
respondido por el Mike Nakis 11.01.2012 - 18:35
1

Piensa en lo bueno que es mencionarle que tiene un estilo de codificación incorrecto.

Quizás es mejor tratar de mejorar los procedimientos de control de calidad de su empresa.

    
respondido por el Kasper van den Berg 11.01.2012 - 18:35
1

Necesitas descubrir dos cosas: ¿Cuál es tu objetivo? ¿Cómo te gustaría ser abordado?

Si su colega, con más de 20 años de programación detrás de él, tiene una mentalidad realmente abierta, puede hablar con él y señalarle ejemplos específicos, decirle por qué le parecieron mal y discutir alternativas. Debido a que tiene una mente muy, muy abierta y con ganas de aprender, escuchará, se desarrollará una discusión, entenderá sus puntos y ambos vivirán felices para siempre.

Sin embargo, en mi experiencia, el colega es más probable que esté programando así porque a él simplemente no le importa el estilo. Podría ser porque realmente está en el trabajo equivocado, o podría ser porque, en más de 20 años de programación, nunca encontró una razón para preocuparse por eso, tal vez su código simplemente funciona y continúa.

Si este último es el caso, simplemente perderá su tiempo y el suyo, y puede hacer mella en su relación si se convierte en una discusión. Entonces, ¿cuál es tu objetivo aquí?

¿Desea que él limpie su código para que pueda trabajar en un código más agradable? ¿Quieres que aprenda y mejore? ¿Quieres sentirte bien por ser un mejor programador? ¿Quieres que tu jefe sepa que eres un mejor programador que él?

El primero no va a suceder y el tercero ya está establecido, aunque probablemente quieras que también lo reconozca: ¿buen amigo, figura paterna?

Si realmente quiere que él aprenda y mejore, entonces averigüe cómo le gustaría que lo aborden en la situación inversa y haga lo mismo. Y averigua qué te molestaría y asegúrate de no hacer eso.

El cuarto es fácil: o quieres un mejor salario y luego lo exiges durante la próxima reunión de comentarios (no importa lo bueno que seas en esta industria) o quieres más responsabilidad y luego sigue haciendo un buen trabajo hasta que lo consigas.

    
respondido por el Carl Seleborg 18.01.2012 - 09:09
0

Sugiérale a su jefe que ha estado viendo algunos códigos locos y pídale que incluya a todo el personal posible en algunos cursos de programación. Creo que debería estar consciente de que sus aplicaciones están llenas de código de mierda.

    
respondido por el H27studio 12.01.2012 - 10:46

Lea otras preguntas en las etiquetas