Le danger avec cette approche c'est que tu te retrouves vite à ne plus faire de documentation.
La doc, les specs, ce n'est pas uniquement pour préparer l'étape développement, c'est aussi pour communiquer. Avec les utilisateurs, et valider ce que tu vas faire. Avec tes pairs, pour discuter/valider tes choix. Avec les autres développeurs, qui feront le support/la maintenance. Etc.
Alors évidemment, il y a l'approche "j'ai mis plein de commentaires, les variables et noms des méthodes sont explicites, pas besoin de doc", mais sur des projets complexes impliquant plein de règles "métier", ça ne marche pratiquement jamais.
D'ailleurs, c'est pour ça que j'aime pas UML, qui était pensé au début pour pouvoir communiquer avec les utilisateurs, mais qui est illisible pour qui n'est pas dans l'informatique et déjà un peu versé en UML.
[^] # Re: [HS] Diagramme de séquence
Posté par Dring . En réponse au journal Webcrise: ébauche d'architecture. Évalué à 1.
Le danger avec cette approche c'est que tu te retrouves vite à ne plus faire de documentation.
La doc, les specs, ce n'est pas uniquement pour préparer l'étape développement, c'est aussi pour communiquer. Avec les utilisateurs, et valider ce que tu vas faire. Avec tes pairs, pour discuter/valider tes choix. Avec les autres développeurs, qui feront le support/la maintenance. Etc.
Alors évidemment, il y a l'approche "j'ai mis plein de commentaires, les variables et noms des méthodes sont explicites, pas besoin de doc", mais sur des projets complexes impliquant plein de règles "métier", ça ne marche pratiquement jamais.
D'ailleurs, c'est pour ça que j'aime pas UML, qui était pensé au début pour pouvoir communiquer avec les utilisateurs, mais qui est illisible pour qui n'est pas dans l'informatique et déjà un peu versé en UML.