Tenemos un programador junior que simplemente no escribe suficientes pruebas.
Tengo que regañarlo cada dos horas, "¿tienes exámenes escritos?"
Hemos intentado:
- Mostrando que el diseño se vuelve más simple
- Mostrarlo previene defectos
- Haciendo que sea una cosa del ego diciendo que solo los malos programadores no lo hacen
- Este fin de semana 2 miembros del equipo tuvieron que venir a trabajar porque su código tenía una referencia NULL y no lo probó
Mi trabajo requiere un código estable de alta calidad y, por lo general, todos "lo entienden" y no hay necesidad de hacer pruebas. Sabemos que podemos obligarlo a escribir pruebas, pero todos sabemos que las pruebas útiles son las que se escriben cuando te gustan.
¿Conoces más motivaciones?
unit-testing
testing
abyx
fuente
fuente
Respuestas:
Ésta es una de las cosas más difíciles de hacer. Conseguir que su gente lo entienda .
A veces, una de las mejores formas de ayudar a los programadores de nivel junior a "entenderlo" y aprender las técnicas correctas de los seniors es hacer un poco de programación por parejas.
Intente esto: en un próximo proyecto, empareje al chico junior con usted u otro programador senior. Deben trabajar juntos, turnándose para "conducir" (siendo el que escribe en el teclado) y "entrenando" (mirando por encima del hombro del conductor y señalando sugerencias, errores, etc. a medida que avanzan). Puede parecer una pérdida de recursos, pero encontrará:
Tal vez también pida a alguien en su grupo que dé la presentación de Pruebas unitarias 101 de Kate Rhodes. Creo que es una excelente manera de hacer que la gente se entusiasme con las pruebas, si se realizan bien.
Otra cosa que puede hacer es hacer que sus desarrolladores Jr. practiquen el juego de bolos Kata que les ayudará a aprender el desarrollo basado en pruebas. Está en Java, pero se puede adaptar fácilmente a cualquier idioma.
fuente
Haga una revisión del código antes de cada confirmación (incluso si es un minuto "He cambiado el nombre de esta variable") y, como parte de la revisión del código, revise las pruebas unitarias.
No firmes la confirmación hasta que las pruebas estén en su lugar.
(Además, si su trabajo no fue probado, ¿por qué estaba en una construcción de producción en primer lugar? Si no está probado, no lo deje entrar, entonces no tendrá que trabajar los fines de semana)
fuente
Por mi parte, he comenzado a insistir en que cada error que encuentre y solucione se exprese como una prueba:
Intento hacer esto incluso mientras estoy golpeando cosas, y termino casi al mismo tiempo, solo que con un conjunto de pruebas parcial ya implementado.
(No vivo en un entorno de programación comercial y, a menudo, soy el único programador que trabaja en un proyecto en particular).
fuente
Imagina que soy un programador simulado, llamado ... Marco. Imagínese que me gradué de la escuela no hace mucho tiempo y nunca tuve que escribir exámenes. Imagínese que trabajo en una empresa que realmente no lo hace cumplir o lo solicita. ¿De acuerdo? ¡bueno! Ahora imagine que la empresa está cambiando a usar pruebas y están tratando de ponerme en línea con esto. Daré una reacción algo sarcástica a los elementos mencionados hasta ahora, como si no hubiera investigado esto.
Empecemos con el creador:
¿Cómo se puede escribir más, simplificar las cosas? Ahora tendría que vigilar la obtención de más casos, etc. Esto lo hace más complicado si me preguntas. Dame detalles sólidos.
Yo sé eso. Por eso se denominan pruebas. Mi código es bueno y lo verifiqué en busca de problemas, por lo que no veo en qué ayudarían esas pruebas.
Ohh, entonces crees que soy un mal programador solo porque no hago tantas pruebas usadas. Estoy insultado y enfadado contigo. Prefiero tener ayuda y apoyo que dichos.
Oh, esto es tan importante que se gastarán recursos para asegurarme de que veo cómo se hacen las cosas y de que alguien me ayude a hacerlo. Esto es útil y podría empezar a hacerlo más.
Ahh, esa fue una presentación interesante y me hizo pensar en las pruebas. Golpeó algunos puntos que debería considerar, y podría haber influido un poco en mis puntos de vista.
Me encantaría ver artículos más atractivos y otras herramientas que me ayuden a ponerme en línea para pensar que esta es la forma correcta de hacer las cosas.
Ahh, esto me ayuda a comprender lo que se espera de mí en cuanto a técnicas, y pone más elementos en mi bolsa de conocimientos, que podría volver a utilizar.
Tener una persona clave (personas) para responder la pregunta es útil, podría hacer que sea más probable que lo intente. Los buenos ejemplos son geniales y me dan algo a lo que apuntar y algo en lo que buscar como referencia. Los libros que son relevantes para esto directamente son una gran referencia.
Di qué, surgiste algo para lo que no estoy preparado. Me siento incómodo con esto, pero haré lo mejor que pueda. Ahora estaré asustado y un poco aprensivo de que esto vuelva a ocurrir, gracias. Sin embargo, la táctica del miedo podría haber funcionado, pero tiene un costo. Sin embargo, si nada más funciona, este podría ser el empujón que se necesita.
Oh, interesante. Veo que realmente tengo que hacer esto ahora, de lo contrario no voy a completar nada. Esto tiene sentido.
miradas, miradas, miradas : existe la posibilidad de que aprenda y, con apoyo y ayuda, puedo convertirme en una parte muy importante y funcional de los equipos. Esta es una de mis desventajas ahora, pero no lo será por mucho tiempo. Sin embargo, si no lo consigo, entiendo que iré. Creo que lo conseguiré.
Al final, el apoyo de mi equipo jugó un papel importante en todo esto. Siempre es bienvenido que una persona se tome su tiempo para ayudarme y hacerme comenzar con buenos hábitos. Entonces, después, tener una buena red de apoyo sería genial. Siempre se agradecería que alguien viniera un par de veces después y revisara algún código, para ver cómo fluye todo, no en una revisión per se, sino más bien como una visita amistosa.
Razonamiento, preparación, enseñanza, seguimiento, apoyo.
fuente
He notado que muchos programadores ven el valor de realizar pruebas a un nivel racional. Si has escuchado cosas como "sí, sé que debería probar esto, pero realmente necesito hacerlo rápidamente", entonces sabes a qué me refiero. Sin embargo, a nivel emocional, sienten que hacen algo solo cuando están escribiendo el código real.
El objetivo, entonces, debería ser hacerles entender de alguna manera que las pruebas son de hecho la única forma de medir cuando algo está "hecho", y así darles la motivación intrínseca para escribir pruebas.
Sin embargo, me temo que eso es mucho más difícil de lo que debería ser. Escucharás muchas excusas como "Tengo mucha prisa, reescribiré / refactorizaré esto más tarde y luego agregaré las pruebas" y, por supuesto, el seguimiento nunca ocurre porque, sorprendentemente, Estás igual de ocupado la próxima semana .
fuente
Esto es lo que haría:
Primera vez ... "vamos a hacer este proyecto juntos. Voy a escribir las pruebas y tú vas a escribir el código. Presta atención a cómo escribo las pruebas, porque así es como hacemos las cosas por aquí y eso es lo que espero de ti ".
Después de eso ... "¿Terminaste? ¡Genial! Primero echemos un vistazo a las pruebas que están impulsando tu desarrollo. Oh, ¿ninguna prueba? Avísame cuando haya terminado y reprogramaremos la revisión de tu código. Si ' Necesitas ayuda para formular las pruebas, avísame y te ayudaré ".
fuente
Ya está haciendo esto. De Verdad. Simplemente no lo escribe. ¿No convencido? Míralo pasar por el ciclo de desarrollo estándar:
El paso 3 es la prueba. Él ya hace pruebas, simplemente las hace manualmente. Hágale esta pregunta: "¿Cómo sabe mañana que el código de hoy todavía funciona?" Él responderá: "¡Es una pequeña cantidad de código!"
Pregunte: "¿Qué tal la semana que viene?"
Cuando no tenga una respuesta, pregúntele: "¿Cómo le gustaría que su programa le avisara cuando un cambio rompe algo que funcionó ayer?"
De eso se tratan las pruebas unitarias automáticas.
fuente
Como programador junior, todavía estoy tratando de acostumbrarme a escribir pruebas. Obviamente, no es fácil adquirir nuevos hábitos, pero pensando en lo que haría que esto funcione para mí, tengo que hacer +1 en los comentarios sobre revisiones de código y programación de coaching / pares.
También puede valer la pena enfatizar el propósito a largo plazo de las pruebas: asegurarse de que lo que funcionó ayer siga funcionando hoy, la semana que viene y el mes que viene. Solo digo eso porque al hojear las respuestas no vi que se mencionara.
Al hacer revisiones de código (si decide hacer eso), asegúrese de que su joven desarrollador sepa que no se trata de menospreciarlo, sino de mejorar el código. Porque de esa manera es menos probable que se dañe su confianza. Y eso es importante. Por otro lado, también lo es saber lo poco que sabe.
Por supuesto, realmente no sé nada. Pero espero que las palabras hayan sido útiles.
fuente
Francamente, si tienes que esforzarte tanto para que él haga algo, es posible que tengas que aceptar la idea de que puede que no sea una buena opción para el equipo y que tenga que irse. Ahora, esto no significa necesariamente despedirlo ... puede significar encontrar otro lugar en la empresa donde sus habilidades sean más adecuadas. Pero si no hay otro lugar ... ya sabes qué hacer.
Supongo que también es un empleado bastante nuevo (<1 año) y probablemente acaba de salir de la escuela ... en cuyo caso es posible que no esté acostumbrado a cómo funcionan las cosas en un entorno corporativo. Cosas así la mayoría de nosotros podríamos salirse con la nuestra en la universidad.
Si este es el caso, una cosa que he encontrado que funciona es tener una especie de "revisión sorpresa de nuevos empleados". No importa si nunca lo has hecho antes ... él no lo sabrá. Simplemente siéntelo y dígale que va a repasar su desempeño y mostrarle algunos números reales ... tome su hoja de revisión normal (tiene un proceso de revisión formal, ¿verdad?) Y cambie el título si lo desea para que se vea oficial y mostrarle su posición. Si le muestra en un entorno muy formal que no hacer exámenes está afectando negativamente su calificación de desempeño en lugar de simplemente "regañarlo" por eso, con suerte entenderá el punto. Tienes que demostrarle que sus acciones realmente lo afectarán, ya sea en términos de pago o de otra manera.
Lo sé, es posible que desee evitar hacer esto porque no es oficial ... pero creo que está dentro de lo razonable para hacerlo y probablemente será mucho más barato que tener que despedirlo y reclutar a alguien nuevo.
fuente
Como programador junior, pensé que revelaría cómo era cuando me encontraba en una situación similar a la de su desarrollador junior.
Cuando salí de la universidad por primera vez, descubrí que me había desquiciado gravemente para lidiar con el mundo real. Sí, sabía algunos conceptos básicos de JAVA y algo de filosofía (no preguntes) pero eso fue todo. Cuando conseguí mi trabajo por primera vez fue un poco abrumador por decir lo menos. Déjame decirte que probablemente era uno de los vaqueros más grandes del mundo, piratearía un pequeño algoritmo / corrección de errores sin comentarios / pruebas / documentación y lo enviaría por la puerta.
Tuve la suerte de estar bajo la supervisión de un programador senior amable y muy paciente. Por suerte para mí, decidió sentarse conmigo y pasar de 1 a 2 semanas revisando mi código muy pirateado. Me explicaba dónde me había equivocado, los puntos más finos de cy los indicadores (¡chico, eso me confundió!). Logramos escribir una clase / módulo bastante decente en aproximadamente una semana. Todo lo que puedo decir es que si el desarrollador senior no hubiera invertido el tiempo para ayudarme en el camino correcto, probablemente no hubiera durado mucho.
Felizmente, 2 años después, espero que algunos de mis colegas incluso me consideren un programador promedio.
Llévate puntos a casa
fuente
Asígnelos a proyectos que no requieran "código estable de alta calidad" si ese es su problema y deje que el jr. desarrollador falla. Haga que sean ellos los que 'vengan el fin de semana' para corregir sus errores. Almuerce mucho y hable sobre las prácticas de desarrollo de software (no conferencias, sino debates). Con el tiempo adquirirán y desarrollarán las mejores prácticas para realizar las tareas que se les asignen.
Quién sabe, incluso podrían encontrar algo mejor que las técnicas que usa su equipo actualmente.
fuente
Si el programador junior, o cualquier otra persona, no ve el valor de las pruebas, será difícil conseguir que lo hagan ... punto.
Habría hecho que el programador junior sacrificara su fin de semana para corregir el error. Sus acciones (o la falta de ellas) no lo están afectando directamente. Además, haga evidente que no verá avances ni aumentos salariales si no mejora sus habilidades en las pruebas.
Al final, incluso con toda su ayuda, estímulo, tutoría, es posible que no sea adecuado para su equipo, así que déjelo ir y busque a alguien que lo entienda.
fuente
Segundo el comentario de RodeoClown sobre el código que revisa cada confirmación. Una vez que lo haya hecho un par de veces, se acostumbrará a probar cosas.
Sin embargo, no sé si necesitas bloquear confirmaciones como esa. En mi lugar de trabajo, todos tienen un compromiso libre con todo, y todos los mensajes de compromiso de SVN (con diferencias) se envían por correo electrónico al equipo.
Nota: realmente desea el complemento thunderbird color-diffs si planea hacer esto.
Mi jefe o yo (los 2 programadores 'senior') terminaremos leyendo las confirmaciones, y si hay algo como "olvidó agregar pruebas unitarias", simplemente pasamos un correo electrónico o vamos a charlar con la persona, explicando por qué pruebas unitarias necesarias o lo que sea. Se anima a todos los demás a leer las confirmaciones también, ya que es una excelente manera de ver lo que está sucediendo, pero los desarrolladores junior no comentan tanto.
Puedes ayudar a animar a las personas a que adquieran el hábito de esto diciendo periódicamente cosas como "Oye, Bob, ¿viste el compromiso que hice esta mañana? Encontré este buen truco en el que puedes hacer bla, bla, lo que sea, lee el compromiso y verás ¡cómo funciona!"
NB: Tenemos 2 desarrolladores 'senior' y 3 junior. Es posible que esto no se amplíe o que necesite ajustar un poco el proceso con más desarrolladores.
fuente
fuente
Mucha psicología y técnicas útiles de "tutoría" pero, honestamente, esto se reduce a "escribir exámenes si todavía quieres tener un trabajo, mañana".
Puede colocarlo en los términos que considere apropiados, duros o suaves, no importa. Pero el hecho es que a los programadores no se les paga por simplemente armar el código y verificarlo, sino que se les paga por armar el código cuidadosamente, luego hacer pruebas, luego probar su código, LUEGO verificar todo. (Al menos eso es lo que parece, según tu descripción).
Por lo tanto, si alguien se va a negar a hacer su trabajo, explíquele que puede quedarse en casa mañana y que usted contratará a alguien que lo hará.
Una vez más, puedes hacer todo esto con cuidado, si crees que es necesario, pero mucha gente simplemente necesita una gran bofetada de Life In The Real World , y tú les estarías haciendo un favor dándoselo.
Buena suerte.
fuente
Cambie la descripción de su trabajo por un tiempo para que solo escriba pruebas y mantenga pruebas. Escuché que muchas empresas hacen esto para personas nuevas y sin experiencia durante un tiempo cuando comienzan.
Además, emita un desafío mientras está en ese rol: escriba pruebas que a) fallarán en el código actual a) cumplirán los requisitos del software. Con suerte, hará que cree algunas pruebas sólidas y exhaustivas (mejorando el proyecto) y lo hará mejor escribiendo pruebas para cuando se vuelva a integrar en el desarrollo central.
editar> Cumplir con los requisitos del software, lo que significa que no solo está escribiendo pruebas para romper el código a propósito cuando el código nunca tuvo la intención o la necesidad de tener en cuenta ese caso de prueba.
fuente
Si su colega carece de experiencia en la redacción de pruebas, es posible que tenga dificultades para realizar pruebas más allá de situaciones simples, y eso se manifiesta como pruebas inadecuadas. Esto es lo que probaría:
No enfatizaría especialmente el factor de vergüenza / culpa. Vale la pena señalar que las pruebas son una buena práctica ampliamente adoptada y que escribir y mantener buenas pruebas es una cortesía profesional para que sus compañeros de equipo no tengan que pasar los fines de semana en el trabajo, pero no insistiría en esos puntos.
Si realmente necesita "ponerse duro", entonces instituya un sistema imparcial; a nadie le gusta sentirse señalado. Por ejemplo, su equipo puede requerir código para mantener un cierto nivel de cobertura de prueba (se puede jugar, pero al menos se puede automatizar); requerir código nuevo para realizar pruebas; exigir a los revisores que consideren la calidad de las pruebas al realizar revisiones de código; y así. La institución de ese sistema debe provenir del consenso del equipo. Si modera la discusión con cuidado, podría descubrir otras razones subyacentes por las que las pruebas de su colega no son lo que esperaba.
fuente
Es responsabilidad de su mentor enseñarle. ¿Qué tan bien le está enseñando CÓMO realizar la prueba? ¿Estás programando en pareja con él? Es muy probable que el Junior no sepa CÓMO configurar una buena prueba para xyz.
Como estudiante de tercer año recién salido de la escuela, conoce muchos conceptos. Alguna técnica. Alguna experiencia. Pero al final, todo un Junior es POTENCIAL. Casi todas las funciones en las que trabajan, habrá algo nuevo que nunca antes habían hecho. Seguro que el Junior puede haber hecho un patrón de estado simple para un proyecto en clase, abriendo y cerrando "puertas", pero nunca una aplicación del mundo real de los patrones.
Él / ella será tan bueno como usted enseñe. Si fueran capaces de "conseguirlo", ¿crees que habrían tomado una posición junior en primer lugar?
En mi experiencia, se contrata a los juniors y se les da casi la misma responsabilidad que a los seniors, pero simplemente se les paga menos y luego se los ignora cuando comienzan a fallar. Perdóname si parezco amargado, es porque lo soy.
fuente
@ jsmorris
Una vez el desarrollador senior y el "arquitecto" me regañaron a mí ya un evaluador (fue mi primer trabajo después de la universidad) por correo electrónico por no quedarme hasta tarde y terminar una tarea tan "fácil" la noche anterior. Habíamos estado trabajando todo el día y lo dejamos a las 7 pm, había estado luchando desde las 11 am antes del almuerzo ese día y había molestado a todos los miembros de nuestro equipo para que ayudaran al menos dos veces.
Respondí y escribí al equipo con: "He estado decepcionado contigo durante un mes. Nunca recibo ayuda del equipo. Estaré en la cafetería al otro lado de la calle si me necesitas. lo siento, no pude depurar el método de 12 parámetros y 800 líneas del que todo depende ".
Después de refrescarme en la cafetería durante una hora, volví a la oficina, agarré mi mierda y me fui. Después de unos días me llamaron preguntando si iba a entrar, dije que sí, pero tenía una entrevista, tal vez mañana.
"Entonces, ¿estás renunciando?"
fuente
En su repositorio de origen: use ganchos antes de cada confirmación (gancho de confirmación previa para SVN, por ejemplo)
En ese gancho, verifique la existencia de al menos un caso de uso para cada método. Utilice una convención para la organización de pruebas unitarias que pueda aplicar fácilmente mediante un enlace previo a la confirmación.
En un servidor de integración, compile todo y verifique regularmente la cobertura de prueba utilizando una herramienta de cobertura de prueba. Si la cobertura de prueba no es del 100% para un código, bloquee cualquier confirmación del desarrollador. Debería enviarte el caso de prueba que cubre el 100% del código.
Solo las verificaciones automáticas pueden escalar bien en un proyecto. No se puede comprobar todo a mano.
El desarrollador debe tener un medio para verificar si sus casos de prueba cubren el 100% del código. De esa manera, si no confirma un código probado al 100%, es su propia culpa, no una falla de "oops, lo siento, lo olvidé".
Recuerde: la gente nunca hace lo que espera, siempre hace lo que usted inspecciona.
fuente
En primer lugar, como la mayoría de los encuestados señalan aquí, si el chico no ve el valor de las pruebas, no hay mucho que puedas hacer al respecto y ya has señalado que no puedes despedirlo. Sin embargo, el fracaso no es una opción aquí, entonces, ¿qué pasa con las pocas cosas que puede hacer?
Si su organización es lo suficientemente grande como para tener más de 6 desarrolladores, le recomiendo encarecidamente tener un departamento de Control de calidad (incluso si es solo una persona para comenzar). Idealmente, debería tener una proporción de 1 evaluador por cada 3-5 desarrolladores. Lo que pasa con los programadores es ... son programadores, no probadores. Todavía tengo que entrevistar a un programador al que se le hayan enseñado formalmente las técnicas adecuadas de control de calidad.
La mayoría de las organizaciones cometen el error fatal de asignar los roles de prueba al nuevo empleado, la persona con la MENOR exposición a su código; idealmente, los desarrolladores senior deben pasar al rol de QA ya que tienen la experiencia en el código. y (con suerte) han desarrollado un sexto sentido para los olores del código y los puntos de falla que pueden surgir.
Además, el programador que cometió el error probablemente no encontrará el defecto porque normalmente no es un error de sintaxis (los que se recogen en la compilación), sino un error lógico, y la misma lógica está en funcionamiento cuando escriben el prueba como cuando escriben el código. No pida a la persona que desarrolló el código que pruebe ese código, encontrará menos errores que cualquier otra persona.
En su caso, si puede permitirse el esfuerzo de trabajo redirigido, convierta a este nuevo chico en el primer miembro de su equipo de control de calidad. Haga que lea "Pruebas de software en el mundo real: Mejorando el proceso", porque obviamente necesitará algo de capacitación en su nuevo rol. Si no le gusta, lo dejará y su problema aún estará resuelto.
Un enfoque un poco menos vengativo sería dejar que esta persona haga lo que se le da bien (supongo que esta persona fue contratada porque en realidad es competente en la parte de programación del trabajo) y contratar a uno o dos probadores para hacer las pruebas ( Los estudiantes universitarios a menudo tienen prácticas o términos "cooperativos", les encantaría la exposición y son baratos)
Nota al margen: Eventualmente, querrá que el equipo de control de calidad informe a un director de control de calidad, o al menos no a un gerente de desarrollo de software, porque hacer que el equipo de control de calidad informe al gerente, cuyo objetivo principal es hacer el producto, es un conflicto de interesar.
Si su organización tiene menos de 6, o no puede salirse con la suya creando un nuevo equipo, le recomiendo la programación emparejada (PP). No soy un converso total de todas las técnicas de programación extremas, pero definitivamente soy un creyente en la programación emparejada. Sin embargo, ambos miembros del equipo de programación emparejado tienen que estar dedicados, o simplemente no funciona. Deben seguir dos reglas: el inspector debe comprender completamente lo que se codifica en la pantalla o debe pedirle al codificador que se lo explique; el codificador sólo puede codificar lo que puede explicar: no se tolerará ningún "verás" o "confía en mí" o agitar las manos.
Solo recomiendo PP si su equipo es capaz de hacerlo, porque, al igual que las pruebas, ninguna cantidad de vítores o amenazas persuadirá a un par de introvertidos llenos de ego a trabajar juntos si no se sienten cómodos haciéndolo. Sin embargo, encuentro que entre la elección de escribir especificaciones funcionales detalladas y hacer revisiones de código frente a la programación emparejada, el PP generalmente gana.
Si PP no es para usted, entonces TDD es su mejor opción, pero solo si se toma literalmente. Test Driven Development significa que usted escribe las pruebas PRIMERO, ejecuta las pruebas para demostrar que realmente fallan y luego escribe el código más simple para que funcione. La compensación es que ahora (debería) tener una colección de miles de pruebas, que también es código, y es tan probable que contenga errores como el código de producción. Seré honesto, no soy un gran admirador de TDD, principalmente por esta razón, pero funciona para muchos desarrolladores que prefieren escribir scripts de prueba que documentos de casos de prueba; algunas pruebas son mejores que ninguna. Combine TDD con PP para una mejor probabilidad de cobertura de prueba y menos errores en el script.
Si todo lo demás falla, pida a los programadores la equivalencia de un frasco de juramentos: cada vez que el programador rompe la compilación, tienen que poner $ 20, $ 50, $ 100 (lo que sea moderadamente doloroso para su personal) en un frasco que va a su favorito ( registrado!) caridad. Hasta que paguen, evítelos :)
Dejando de lado las bromas, la mejor manera de hacer que su programador escriba pruebas es no dejar que programe. Si desea un programador, contrate a un programador: si desea pruebas, contrate a un probador. Comencé como programador junior hace 12 años haciendo pruebas, y se convirtió en mi trayectoria profesional, y no lo cambiaría por nada. Un departamento de control de calidad sólido que se nutre adecuadamente y se le da el poder y el mandato para mejorar el software es tan valioso como los desarrolladores que escriben el software en primer lugar.
fuente
Esto puede ser un poco cruel, pero por la forma en que describe la situación, parece que necesita despedir a este tipo. O al menos déjelo claro: negarse a seguir las prácticas de desarrollo de la casa (incluidas las pruebas de escritura) y verificar el código defectuoso que otras personas tienen que limpiar eventualmente lo despedirán.
fuente
La razón principal por la que los ingenieros / programadores junior no se toman mucho tiempo para diseñar y realizar scripts de prueba, es porque la mayoría de las certificaciones de CS no requieren mucho esto, por lo que otras áreas de la ingeniería se cubren más en los programas universitarios, como los patrones de diseño.
En mi experiencia, la mejor manera de hacer que los profesionales jóvenes adquieran el hábito es hacerlo parte del proceso de manera explícita. Es decir, al estimar el tiempo que debe tomar una iteración, el tiempo de diseño, escritura y / o ejecución de los casos debe incorporarse en esta estimación de tiempo.
Finalmente, revisar el diseño del script de prueba debe ser parte de una revisión del diseño, y el código real debe revisarse en la revisión del código. Esto hace que el programador sea responsable de realizar las pruebas adecuadas de cada línea de código que escriba, y que el ingeniero senior y sus compañeros sean responsables de proporcionar comentarios y orientación sobre el código y la prueba escrita.
fuente
Basado en su comentario, "Demostrar que el diseño se vuelve más simple" Asumo que ustedes practican TDD. Hacer una revisión del código después de los hechos no va a funcionar. Todo acerca de TDD es que es un diseño y no una filosofía de prueba. Si él no escribió las pruebas como parte del diseño, no obtendrá muchos beneficios al escribir las pruebas después del hecho, especialmente de un desarrollador junior. Terminará perdiendo un montón de casos de esquina y su código seguirá siendo una mierda.
Su mejor opción es tener una muy desarrollador senior paciente que se siente con él y haga una programación en pareja. Y sigue así hasta que aprenda. O no aprende, en cuyo caso debe reasignarlo a una tarea para la que se adapta mejor porque terminará frustrando a sus verdaderos desarrolladores.
No todo el mundo tiene el mismo nivel de talento y / o motivación. Los equipos de desarrollo, incluso los ágiles, están formados por personas en el "Equipo A" y personas en el "Equipo B". Los miembros del A-Team son los que diseñan la solución, escriben todo el código de producción no trivial y se comunican con los propietarios de negocios, todo el trabajo que requiere pensar de manera innovadora. El B-Team se encarga de cosas como la administración de la configuración, la escritura de scripts, la corrección de errores y el trabajo de mantenimiento, todo el trabajo que tiene procedimientos estrictos que tienen pequeñas consecuencias por fallas.
fuente