Recientemente hablé con un probador de software y no pude evitar pedirle su opinión sobre desarrollo basado en pruebas (TDD) ya que es una práctica obligatoria aquí en Qumulo para nuestros equipos de ingeniería.
Parafraseando sus sentimientos, dijo:
Creo que las pruebas unitarias son importantes, pero los desarrolladores no suelen pensar desde la perspectiva de un usuario al escribir sus pruebas. En su lugar, piensan en la implementación y en cómo esperan que funcione, lo cual no es a menudo como realmente funciona.
Su parcialidad como evaluador no se pierde en mí, pero estoy de acuerdo en que alguien, cuyo trabajo es estrictamente escribir pruebas funcionales, puede aportar una mentalidad muy necesaria al ciclo de lanzamiento. También creo que es importante que los desarrolladores de funciones compartan esa mentalidad de interruptor, ya que los ingenieros de software son diseñadores primero y luego programadores. Tenemos que pensar en los casos de uso, cómo pueden salir mal las cosas y cómo mitigar el daño cuando las cosas inevitablemente van mal..
En Qumulo, creamos continuamente un proceso de integración y crecimiento para nuestros ingenieros que fortalece esas habilidades, lo que incluye el uso de TDD para facilitar ese proceso de crecimiento.
Un ingeniero es realmente solo un científico que intenta resolver problemas para los clientes. En mi experiencia, la contribución más valiosa de TDD es cómo facilita el método científico para los ingenieros que lo practican. Cuando estás escribiendo una prueba de unidad, estás haciendo una hipótesis de que si, y solo si, Si cambia el código de producción, cumplirá con las propiedades declaradas por su prueba más reciente. Esto es en realidad dos hipótesis compuestas:
- El código de producción existente no satisfará las propiedades declaradas por su nueva prueba.
- El código de producción modificado satisfará las propiedades declaradas por su nueva prueba.
Sin TDD, estás practicando la mala ciencia al olvidar realizar tu experimento en una población de control. Puede darse el caso de que su prueba hubiera pasado sin cambiar el código de producción, y esto significa que o su prueba tiene un error, o no está comunicando ninguna nueva propiedad del código de producción.
El código base de Qumulo es como un cuaderno de laboratorio; tenemos más de 55,000 pruebas que documentan todos los experimentos realizados en el código de producción. Comunica lo que sabemos sobre el código, y cada prueba es tan valiosa como lo que comunica al lector. Puede darse el caso de que nuestra comprensión de las necesidades del cliente haya cambiado, y como tal, también debería hacerlo el código y lo que sabemos sobre él. Depende de los ingenieros decidir si una prueba es valiosa y, de no ser así, se elimina.
Al facilitar el método científico, TDD permite a los ingenieros enfocarse en un problema más problemático: ¿qué pruebas nos faltan? Este es el desafío principal del proceso de diseño, ya que requiere que los ingenieros se metan dentro de las cabezas de sus clientes. Les obliga a considerar ¿Quiénes son nuestros clientes? ¿Cómo van a ejercer nuestro código? (Tenga en cuenta que los "clientes" pueden incluir otros ingenieros que utilizan su código).
¡Y el proceso de diseño es siempre colaborativo, porque es peligroso ir solo!
"Lo que un programador puede hacer en un mes, dos programadores pueden hacerlo en dos meses". - Fred Brooks
Estoy tomando las palabras de Fred fuera de contexto aquí, pero si "lo que un programador puede hacer" es escribir errores, entonces la declaración de Fred adquiere un nuevo significado: dos programadores escribirán tantos errores en dos meses como lo hará un programador en uno ¡mes! Pero en serio, cuando practicas TDD, cada error que escribes es en realidad una prueba que no escribiste, y dos ingenieros de par pensarán en más casos de prueba que un ingeniero. También tiende a producir un código más limpio con mejores nombres de funciones y variables. En general, la disciplina es más fuerte con cada persona que responsabiliza a la otra.
Así que recomendamos que par de ingenieros por defecto, y eso no se detiene en la codificación. En Qumulo, escribimos historias de usuario, escribimos tareas y resolvemos problemas en una pizarra en pares. El emparejamiento no solo reduce la tasa de errores, sino que difunde información sobre los dominios problemáticos y, como beneficio adicional, es divertido.
Es divertido si lo haces bien. Entonces, ¿cómo enseñamos a nuestros ingenieros a probar y emparejar de manera efectiva?
Recientemente agregamos un evento a nuestro proceso de incorporación llamado TDD y Taller de Emparejamiento. Hacemos presentaciones sobre TDD y el emparejamiento, discutimos los beneficios y los escollos, y practicamos todo lo que aprendimos al emparejar en un kata (un pequeño problema de práctica, que se pretende repetir con frecuencia). Utilizamos los estilos de ping-pong, controlador / navegador y mobbing para practicar TDD estricto e implementar una biblioteca para convertir números romanos a decimales y viceversa.
Los participantes a menudo hacen las mismas quejas sobre el emparejamiento y TDD:
- Estoy incómodo codificando con alguien mirando; hace que sea difícil pensar con claridad.
- A menudo me quedo atrapado en un desacuerdo con mi pareja y pierdo el tiempo.
- Me sentí como si fuera una máquina de escribir a merced del navegante; No seguí con el problema que estábamos resolviendo.
- Siento que mi pareja se distrae mientras hago todo el trabajo.
- TDD es ineficiente; Acabo de escribir código poco elegante y arreglarlo más tarde.
Hemos estado practicando estos aspectos de Programación extrema (XP) durante años en Qumulo, por lo que hemos abordado estos problemas y ofrecemos las siguientes lecciones aprendidas a los empleados nuevos:
- Establezca objetivos y procedimientos operativos claros y alcanzables para su sesión de emparejamiento antes tu empiezas
- Si nota una disminución de la productividad, tómese un descanso.
- Si no has tenido mucha experiencia en el emparejamiento, puede ser agotador. Hazle saber a tu pareja y podrás cambiar el discurso a algo menos intenso.
- Si no puede superar un desacuerdo, acuda a un tercero para que medie.
- Si está perdiendo el rumbo, dígale a su compañero que desea cambiar roles o estilos para reducir la velocidad. No es bueno quedarse atrás.
- Parte de TDD es escribir el código más simple posible en ese momento.A menudo es necesario identificar una abstracción y un refactor (ver Premisa de transformación prioritaria).
Además del taller, los equipos de ingeniería generalmente fomentan el emparejamiento y el TDD, y cada equipo tiene un entrenador técnico cuyo objetivo es comunicar los estándares de codificación y ayudar a los miembros del equipo a encontrar diseños y factorizaciones de códigos que puedan comprobarse.
Es fácil ser escéptico de XP si no lo has practicado lo suficiente como para experimentar los beneficios. Encontramos que TDD y el emparejamiento ayudan a los ingenieros a convertirse en científicos y diseñadores capacitados que se comunican de manera más efectiva y dejan sus egos en casa. Es posible que se sienta tentado a reclamar la gloria por la creación de un hermoso copo de nieve de código por sí mismo, pero al vincularlo, se ve obligado a darse cuenta de que el código es para que todos diseñen, lean y reutilicen, por lo que no tiene sentido. Adjuntarlo a tu orgullo personal.
