Selon moi, trop anticiper la conception, c'est condamné son projet à manquer de dynamisme, à être figé ... mais foncer directement dans la réalisation, c'est le condamné à partir en vrille, l'envoyer dans des impasses couteuses en temps, avancer à l'aveuglette donc ...
Ce que je veux dire, c'est que ma faible expérience de petit amateur du dimanche (=protection anti-puristes ON) me suggére que conception et réalisation doivent à la fois s'opposer et se compléter, que l'on doit avancer l'un juste de quoi avancer l'autre, que conception et réalisation doivent s'alterner fréquement, par période de taille appropriée (on avance l'un juste ce qu'il faut pour continuer l'autre, et ce en boucle). Ce qui permet de donner tout ce qu'il faut de dynamisme à son projet mais en sachant toujours vers où on va.
Qu'en pensez vous ? Ferais-je erreur, devons-nous planifier, architecturer, schématiser tout à 75-95% avant de commencer à coder, ou devons-nous oublier toute cette paperasse pour nous précipité dans le code ?
En bref, je déteste la paperasse, mais je la trouve indispensable pour conserver une abstraction de l'historique de développement du projet, et pour offrir un fil directeur au developpement dans un futur proche. Le code/concret d'un coté, la paperasse/abstrait de l'autre, mutuellement indiscociables et indispensable à la vivacité de l'avancé du projet.
J'en viens donc à : je me demandais s'il existait des approches (méthodes, bouquins, sites, docs quelconques) qui se rapprocherai de ma perception, qui irait dans mon sens, afin que je m'instruise sur le sujet, si ça existait ? (il est hors de question que je change d'approche, je préfére appronfondir et formaliser celle que j'ai adoptée naturellement, même si minoritaire ...)
# Digression : Conception vs Realisation
Posté par RuleZ . En réponse au message Conception de gros projets en C. Évalué à 2.
Ce que je veux dire, c'est que ma faible expérience de petit amateur du dimanche (=protection anti-puristes ON) me suggére que conception et réalisation doivent à la fois s'opposer et se compléter, que l'on doit avancer l'un juste de quoi avancer l'autre, que conception et réalisation doivent s'alterner fréquement, par période de taille appropriée (on avance l'un juste ce qu'il faut pour continuer l'autre, et ce en boucle). Ce qui permet de donner tout ce qu'il faut de dynamisme à son projet mais en sachant toujours vers où on va.
Qu'en pensez vous ? Ferais-je erreur, devons-nous planifier, architecturer, schématiser tout à 75-95% avant de commencer à coder, ou devons-nous oublier toute cette paperasse pour nous précipité dans le code ?
En bref, je déteste la paperasse, mais je la trouve indispensable pour conserver une abstraction de l'historique de développement du projet, et pour offrir un fil directeur au developpement dans un futur proche. Le code/concret d'un coté, la paperasse/abstrait de l'autre, mutuellement indiscociables et indispensable à la vivacité de l'avancé du projet.
J'en viens donc à : je me demandais s'il existait des approches (méthodes, bouquins, sites, docs quelconques) qui se rapprocherai de ma perception, qui irait dans mon sens, afin que je m'instruise sur le sujet, si ça existait ? (il est hors de question que je change d'approche, je préfére appronfondir et formaliser celle que j'ai adoptée naturellement, même si minoritaire ...)