Moi je rajouterai:
1.5) on écrit les tests unitaires d'après ce qu'on sait du projet (diagramme UML/ Merise, gribouillage sur une nappe de pizzeria...)
Une fois que tes classes/modules passent les tests unitaires, tu arrêtes de les coder et tu passes à la suite. ça te donne un prototype plus rapidement, et tu optimise ensuite en étant sûr de rien casser d'existant.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par __caffeine__ . En réponse au journal Et si ce qu'on apprenait ne marchait pas ?. Évalué à 1.
1.5) on écrit les tests unitaires d'après ce qu'on sait du projet (diagramme UML/ Merise, gribouillage sur une nappe de pizzeria...)
Une fois que tes classes/modules passent les tests unitaires, tu arrêtes de les coder et tu passes à la suite. ça te donne un prototype plus rapidement, et tu optimise ensuite en étant sûr de rien casser d'existant.
Lisez le chapitre "Unit Testing" de http://www.diveintopython.org(...) , c'est très bien expliqué.