¿Cómo "neutralizar" a los que escriben códigos incorrectos en el equipo?

Siempre me ha encantado este artículo sobre JoelOnSoftware llamado "Cómo hacer las cosas cuando solo eres un gruñido". Especialmente podría relacionarme cuando era novato (y todavía siento que SIEMPRE seré uno).

Sobre el # 4, neutralizando los bozos. ¿Qué consejo tiene para implementar esto en situaciones reales en el trabajo? No parece ser tan fácil (al menos en nuestro equipo) como simplemente registrar un error contra el código incorrecto de alguien. ¿Qué funciona para todos los demás?

team bug

— C Johnson
fuente

Pistolas Muchos de ellos.

— CodesInChaos

Respuestas:

Evaluación permanente

Al final de cada día, dedique 30 minutos a revisar lo que han escrito. Si han hecho algo mal, haga que lo reescriban.

A menos que haga esto, un día se dará cuenta de que una parte de su aplicación, aunque aparentemente es capaz de hacer el trabajo, es totalmente imposible de mantener, está diseñada incorrectamente y causará muchos problemas en el futuro, o incluso mañana.

Incluso si los hará menos productivos, aún será mucho mejor si producen un buen código contra dos veces más de tamaño pero una gran cantidad de errores insostenibles.

— P Shved
fuente

Gran respuesta. Si puedo añadir eso, si esta persona es un compañero, entonces es mejor que lo haga el líder del equipo. De esa manera, la respuesta de "no es bueno hacerlo de nuevo" sería mucho más efectiva si lo ordenara la jerarquía de la tienda.

@Surfer, es exactamente lo contrario. Te conviertes en un líder de equipo haciendo cosas como esta, proponiendo mejores soluciones, cuidando lo que hace el equipo. No viceversa. (Pero, por supuesto, obtener ayuda de niveles jerárquicos más altos ayuda).

— P Shved

Entonces la pregunta es, ¿quién tiene la autoridad para hacer que lo reescriban? Supongo que la respuesta es, la autoridad moral de todo el equipo, si los problemas se transmiten a todo el equipo.

— C Johnson

En ausencia de un mecanismo robusto de revisión de código para cada miembro del equipo, esto es apropiado. También es apropiado asegurarse de que el bozo no cava un hoyo realmente profundo (incluso si no vale la pena el costo de la reparación) antes de que le digan que lo vuelva a trabajar.

— mattnz

Si la persona simplemente no conoce mejor, pero quiere aprender, proporcione algún tipo de tutoría y revisión de código. Asegúrese de que estén expuestos a un buen código.

Los desarrolladores realmente pobres son aquellos que están mal encaminados y luchan por aprender algo nuevo. Su única esperanza es dejarlos sufrir manteniendo su propio desorden o algunas de las cosas más simples. Idealmente, alguien con autoridad se pone de pie y dice conformarse o irse.

— JeffO
fuente

La actitud realmente cuenta. Por lo general, encuentro que los novatos son más humildes y están abiertos a críticas y críticas de códigos. Es fácil hablar con estas personas. Y puedes hablarles fácilmente sobre sus debilidades. Son los veteranos arrogantes, que se romperán como un millón de pedazos de vidrio cuando son criticados por su trabajo.

— C Johnson