Tratar con un desarrollador continuamente ignorando casos extremos en su trabajo

Tengo un problema interesante, bastante común, supongo, con uno de los desarrolladores de mi equipo. El tipo es un gran desarrollador, trabaja rápido y productivo, produce un código de bastante buena calidad y todo. Buen ingeniero. Pero hay un problema con él: muy a menudo no aborda los casos límite en su código.

Hablamos con él muchas veces y lo está intentando, pero supongo que simplemente no piensa de esta manera. Entonces, lo que termina sucediendo es que el control de calidad encontraría muchos problemas con su código y lo devolvería al desarrollo una y otra vez, lo que finalmente resultaría en plazos incumplidos y todos los miembros del equipo estaban descontentos.

No sé qué hacer con él y cómo ayudarlo a superar este problema. ¿Quizás alguien con más experiencia podría aconsejar?

Requerirle que escriba pruebas unitarias automatizadas para su código. Escribir pruebas unitarias obliga a uno a pensar en los casos extremos.

Algunos detalles:

1. Para asegurarse de que no se sienta singular, esto debe instituirse para todo su equipo. Solicite a todos que escriban pruebas unitarias automatizadas para el nuevo código o código que modifiquen.
2. Exija que los nombres de las pruebas unitarias sean descriptivos del caso que están probando.
3. Cubra las pruebas unitarias automatizadas en la revisión del código a un alto nivel. Haga que los revisores busquen casos de prueba perdidos (es decir, aquellos casos extremos que él siempre pierde). Después de una cierta cantidad de comentarios de su equipo sobre casos límite perdidos, probablemente aprenderá a considerarlos antes de la revisión.
4. Haga cumplir esta regla para todo el equipo: si QA encuentra un error, el desarrollador responsable debe la prueba automatizada que confirma la falla y luego prueba que la ha solucionado. (antes de que hagan cualquier otro trabajo)

Dale una lista de verificación, por ejemplo

• entradas nulas
• entradas en extremo extremo de rango
• entradas en el extremo de rango extremadamente pequeño
• combinaciones
• entradas que violan invariantes supuestos (por ejemplo, si x = y)

La gente de QA puede ayudar a diseñar la lista de verificación

Entregue la lista de verificación a todos los desarrolladores, no solo a este.

Buen ingeniero.

Bueno.

Pero hay un problema con él: muy a menudo no aborda los casos límite en su código.

Es una calidad que los buenos ingenieros no comparten.

Observar casos extremos es una característica que está presente o no en las personas. No tiene nada que ver con ser ingeniero o programador. El desarrollo de esta característica está influenciado por los antecedentes culturales, el entorno de vida, los eventos de la infancia y las experiencias de la vida. Entonces la actitud simplemente se aplica a cualquier trabajo que un individuo esté haciendo.

Lo que necesitas es averiguar si tu chico es de ese tipo que no ha desarrollado este cierto sentido (quizás todavía). También es muy probable que simplemente no le importe por alguna razón u otra. Debe analizar toda la situación, si es feliz en su trabajo. Si no, entonces quizás deberías hacer algo para ayudarlo primero.

Si está bien con el trabajo pero aún no ha experimentado el peligro de casos extremos, entonces puede comenzar a educarlo. Si se lo toma en serio, podría cambiar su forma con el tiempo. Aunque soy escéptico con respecto a esto, aún podrías intentarlo.

Sin embargo, si resulta ser ese tipo de persona que no es buena en los casos límite, entonces es posible que no le quede más que sacarlo del equipo. Esta característica es esencial para la programación práctica. Lamentablemente, sin ella, incluso una gran persona no produciría un buen trabajo.

¿Podría hacer revisiones de código o revisiones de diseño anteriormente en el proceso?

Enséñele a programar primero la prueba. Par con él. Usted escribirá los casos de prueba y él escribirá el código para pasar las pruebas.

¿Podría involucrar a QA lo suficientemente temprano en el desarrollo de características para ayudarlo a proporcionar una lista de casos límite cerca del comienzo para cubrir? Si bien algunos pueden ver esto como que no esperan que el desarrollador cubra todo, esta puede ser una forma de evitar esto si tiende a pasar por alto esos casos límite que un probador podría detectar inicialmente.

La otra idea que tendría aquí es cómo ve este problema. ¿Está realmente molesto y molesto consigo mismo por este patrón o simplemente lo ve como algo normal y no es algo de lo que deba preocuparse para resolver? De acuerdo, esto requiere una gran confianza y lograr que sea abierto en su perspectiva, pero creo que hay un cierto grado de empatía aquí que puede ayudar si puede ver las cosas desde su perspectiva.

Hay un número infinito de casos de borde, cubriéndolos todos es inviable. ¿Qué pasa si alguien lo hace #define TRUE FALSE? Agrega casos extremos, ¿los revisarás también?

Además, no consideraría la prueba de tontos de cada función de una clase privada o función interna.

El enfoque que elijo para el código que debe ser muy sólido y estable es:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

De esta forma, obtienes volcados sólidos de aplicaciones en el control de calidad, y cuando llegas a un lanzamiento, la aplicación es sólida y segura.

Evitar errores es malo. Bien, puede guardar una función si el identificador de archivo es nulo y devuelve nulo, pero en la mayoría de los casos, hay un error de diseño en alguna parte, y el bloqueo de la aplicación es una mejor manera de obligarlo a encontrar la causa. La mayoría de los casos extremos enmascaran el error al ocultar un problema, por ejemplo, el botón dejó de funcionar. Crash te dice que algunas suposiciones sobre el producto son incorrectas, y debes revisar la lógica que causó el crash.

Si se trata de un caso límite, ¿es necesario considerarlo? Si los casos límite son importantes, entonces los casos límite deben ser alimentados a los requisitos / características / historia del usuario.

Si los casos de borde se han considerado como parte de una pieza de trabajo y se requiere que los dispositivos se coloquen en su lugar, entonces deberían ser parte del elemento de trabajo y, por definición, el elemento de trabajo no está completo hasta que el mecanismo para manejar el caso de borde esté en su lugar.

Esto le da a usted como líder del equipo algo para verificar después de que el trabajo se haya completado durante la discusión posterior al trabajo y le da al desarrollador algo para verificar mientras completa el trabajo.

La captura de casos extremos es la razón por la cual existe el control de calidad. Los programadores tienen la responsabilidad de impulsar el trabajo de manera oportuna. Pasar todo su tiempo buscando casos extremos es muy ineficiente. Si tiene un ciclo iterativo razonablemente rápido, entonces esto no debería ser ningún problema. Los casos de borde son casi infinitos en número. Si se tratara de un problema con los casos "Core", estaría un poco preocupado. Así como los desarrolladores son expertos en desarrollo, un probador debe ser un experto en pruebas. Cuando un probador encuentra un problema, lo devuelve al desarrollo. El desarrollador soluciona el problema. Problema resuelto. El tiempo para que un desarrollador rastree cada caso límite es mucho más largo que el ciclo de prueba iterativo. También tenga en cuenta que cuando estoy hablando de pruebas, no me refiero a las pruebas de unidad de caja blanca, sino estrictamente a las pruebas de caja negra.

Ese es uno de los casos en los que creo que el desarrollo impulsado por pruebas viene a rescatar porque ayuda a pensar en términos de casos extremos y cualquier cosa que pueda romper el código.