EDD: Error Driven Development. Volviendo a los inicios. Digamos adiós al postureo

TDD is dead. Esta afirmación fue la punta de lanza que me llevó a comenzar este manifiesto. Pensando en esos innumerables desarrolladores que no dejan de repetir con cierto postureo implícito que practican TDD, BDD e, incluso, se atreven a definir sus despliegues a producción como CI. Reconozcamos que todo esto nos impide disfrutar de la programación como tal. Y, sobre todo, frustran a nuestros compañeros que no conocen el significado de esas siglas (oh, wait).

Volvamos a los orígenes de nuestro desarrollo software. Allí dónde nos sentíamos libre sin tanta metodología ágil que sólo aporta burocracia vacía a nuestro código. Más código inservible en producción y ocupa espacio en nuestros repositorios: paquetes de test, librerías para hacer mocks, stubs, componentes dummies, etc..

El Test Driven Development ha muerto, demos la bienvenida a EDD (Error Driven Development). Dejémonos guiar por el mayor motivador para un programador el error de sintaxis, error de compilación, el error al arrancar la aplicación, el error 500, los logs en el Apache, etc..

Reglas para disfrutar del Error Driven Development

Ya nos libramos de la documentación a base de repetir que nuestro código es la mejor documentación. Incluso desterramos los comentarios de código al ridiculizarlo en decenas de Agile Conferences. Hagamos un favor a los programadores que vendrán detrás nuestro: eliminemos el paquete de test en nuestros proyectos. Que descubran por si mismos que carajo hace nuestro código. Permitamos que disfruten de una tarde de inmersión en en nuestro código legacy.

Dejemos fluir las cosas tal como son, que un resaltado en rojo o una traza de error guie nuestro desarrollo. Busquemos sin temor el error en Stackoverflow y mirando para otro lado hagamos copy-paste de la respuesta más valorada (aquel programador indio que siempre aparece con más estrellas)

Comportemonos con normalidad cuando algo falla en producción. No empecemos con la historia de que los test de integración han ido bien o que tenemos lanzandose cada noche smoke test. Reconozcamos que la mejor prueba de nuestro código es cuando apuntamos a producción y miles de usuario lo hacen por nosotros.

Olvidemos el QA jerarquizado. Dejemos de atascar la columnna de Acceptance de nuestros tablones Scrum. Si nunca hacemos un checklist o un Howto test en condiciones, dejemos de liar al chico que se encarga de las “integraciones”. Dejemos de forzarle a dar paseos hasta nuestro sitio para saber minimamente cómo arrancar la aplicación. Lo que debe hacer es sentarse a nuestro lado y ver los errores que vamos solucionando. Que vea como fluye nuestro código tapando bugs.

Hagamos un push a master sin miedo de que alguien critique nuestro código en un Pull Request. Sólo sirve para alguno bloque la tarea por ser un perezoso que no es capaz de echar un vistazo de 2 minutos o que alguien se saque un patrón de la manga vía Martin Fowler y te haga rehacer todo.

Olvidemos las palabras de “artesano del software“ para otro momento: cuando tocamos directamente en producción. Reconozcamos con orgullo y apreciemos nuestro potencial para levantar maquinas al instante, matar procesos que se atascan y cambiando un if mal puesto directamente en el servidor.

Dejemos de ir a charlas y conferencias. Ir a charlas está muy bien pero generar una tremenda frustración cuando llegas a la oficina y te das cuenta que sigues “programando” en COBOL y que no tocarás jamás ni Node, Angular, Docker y ni mucho menos eso de lo que todo el mundo habla como Big Data.

Tranquilo. No debes cumplir todas estas reglas de golpe. Simplemente deja que el error emerja y busca la solución más rápida. Cuidado con usar patrones y esas cosas impostadas, lo único que conseguirás minimizar los errores y alejarte del camino del EDD.

En Genbeta Dev | Errores comunes al hacer pruebas de software de nuestro código