JackosKing (./97) :
Nil> Il ne s'agit pas de tout savoir à l'avance, mais de pouvoir modifier le code facilement.

On est d'accord, justement, modifier le code facilement revient à prendre en compte le fait qu'il est possible qu'on ne sache rien à l'avance ou presque (ou que certaines chose aient été oubliées).

Mais bon, dire qu'il y a *une* bonne façon de développer en POO, ça revient à dire qu'il n'y a qu'une bonne façon d'organiser des objets LDAP (je parle de ce que je connais mieux, j'avoue avoir fait ces dernières années plus d'analyse OO que de POO à proprement parlé puisque je ne travaillais que sur l'organisation des données et pas - ou peu - sur du développement). Il y a énormément de techniques qui se valent, toutes ont leurs points forts et toutes ont leurs points faibles. Certaines sont plus adaptées à de gros ou très gros projets, d'autres moins.

HS : Je ne sais pas chez vous, mais on est vraiment revenu du code totalement souple et évolutif (à mon grand malheur, d'ailleurs, mais vu l'historique de chacun de nos produits, on s'est rendu compte que c'était en partie du temps presque perdu... on développe du jetable qui dure 4 à 5 ans, ce qui est finalement à peine moins que du définitif qui dure 6 ans). On sait qu'un code fera une version majeure et qu'après il aura toutes les chances d'être réécrit totalement (parce que le langage aura grandement évolué (je prend l'exemple du Java, de .NET ou, pire, du PHP) parce que la structure de données aussi, parce que la plateforme cible aussi...).
On évite de reprendre du code qui a plus de 4 ans. Par contre (enfin, c'est pas vrai pour toute l'équipe, malheureusement), on essaye de documenter le plus possible pour pouvoir se baser sur les travaux d'analyse précédents et pour pouvoir intégrer des ressources étrangères plus facilement (quand on a un prestataire extérieur qui vient développer une appli ou mettre en place un service, il préfère avoir accès à une bonne analyse qu'à du code évolutif).