Readme Driven Development
Normalment els projectes informàtics es dissenyen > s’implementen > es proven > es documenten.
Però normalment la implementació sempre s’allarga, aleshores això treu temps a les proves i encara més temps a la documentació. I això porta a que les aplicacions estiguin:
- Poc provades
- Mal documentades.
Una solució això és utilitzar l’estratègia TDD (Test Driven Development) on els projectes es dissenyen > es creen del joc de proves > s’implementa la solució > es proven > es documenten
Amb aquest paradigma com a mínim s’assegura que hi hagi proves ben fetes. Però sol passar que el projecte no està ben documentat.
RDD (Readme Driven Development) capgira totalment la cadena del projecte. El projecte es documenta, es creen els jocs de proves i finalment s’implementa i es prova. Però això que sembla tan poc intuïtiu té molta lògica.
La documentació no només serveix per explicar com fer servir l’aplicació, sinó que permet als usuaris (i aquí usuari vol dir tant l’usuari final, com el qui haurà de mantenir el codi de l`aplicació, com qui l’hagi d’estendre,…) fer-se una idea del que acabarà sent i si els pot fer servei o no.
A continuació cal formalitzar aquesta documentació i escriure un joc de proves, per veure realment si el que s’ha descrit és realista i realitzable.
I finalment quan s’està segur del què es vol fer i de com ha de quedar aleshores es fa la implementació i es prova.
Més informació
