Alors, je conseille fortement Rails, qui me semble idéal pour une méthode de développement que certains appellent "agile". Il y a en particulier un bon livre qui s'appelle "programmation agile avec ruby on rails", je crois, et qui aborde la programmation sous cet angle.
Dans cette vision des choses, tu as un entretien rapide avec tes utilisateurs, ils définissent leurs besoins, tu passes 2h à coder un prototype, tu leur fais essayer, ils t'expliquent pourquoi ce n'est pas du tout ce qu'ils veulent, tu passes une heure à faire les modifs, et tu recommences jusqu'à ce qu'ils soient contents.
Dans beaucoup de cas simples, tu peux même faire les modifs demandées pendant qu'ils boivent un café, ou en direct.
En particulier, des opérations souvent pénibles comme changer la structure des données deviennent relativement simples et rapides.
J'ai fait un projet de taille conséquente suivant cette méthode, ça m'a vraiment beaucoup facilité la vie car le client n'avait pas d'idée bien précise de ce qu'il voulait, et le client a été très satisfait du résultat et de la réactivité qu'on a pu obtenir alors que j'étais presque le seul à bosser dessus.
Pour prendre quelques exemples:
- le nombre et le type des champs de nos données changeait tout le temps et n'était défini nulle part, donc (en une demie journée) j'ai fait en sorte que les modèles du projet puissent contenir un nombre indéterminé de champs qui n'étaient pas des colonnes de la base de données mais stockées dans un champ fourre-tout. Au niveau applicatif, c'est entièrement transparent. C'est à dire que pour créer un champ, il suffit de lui affecter une valeur (livre.prix = 10 crée le champ prix s'il n'existe pas).
- j'ai dû rajouter au projet une gestion des droits permettant de rendre des champs accessibles seulement à certaines personnes en fonction d'une validation des données par d'autres personnes. Ce n'était pas prévu. En quelques heures, j'ai pu coder une solution élégante et plus générique que ce qui était demandé.
- j'ai dû faire en sorte qu'un formulaire puisse être édité par parties, sans qu'on puisse jamais modifier une partie déjà saisie. C'est à dire que les champs que l'on remplit à un moment ne sont plus modifiables par la suite. Le code qui fait ça doit représenter une trentaine de ligne avec beaucoup de redondance.
Je ne sais pas si ce sont des exemples très pertinent, mais ça montre que même quand tu es sous pression au niveau des deadlines, avec Rails tu peux bricoler des solutions rapidement et conserver une organisation propre et élégante. L'important là dedans, ce n'est pas le choix parfois discutable d'implémentation, c'est que les délais sont toujours de l'ordre de quelques heures, et qu'on ne se retrouve pas avec du code non maintenable à la fin.
[^] # Re: Cahier des charges ?
Posté par Yusei (Mastodon) . En réponse au journal Windev, qui es tu ?. Évalué à 3.
Dans cette vision des choses, tu as un entretien rapide avec tes utilisateurs, ils définissent leurs besoins, tu passes 2h à coder un prototype, tu leur fais essayer, ils t'expliquent pourquoi ce n'est pas du tout ce qu'ils veulent, tu passes une heure à faire les modifs, et tu recommences jusqu'à ce qu'ils soient contents.
Dans beaucoup de cas simples, tu peux même faire les modifs demandées pendant qu'ils boivent un café, ou en direct.
En particulier, des opérations souvent pénibles comme changer la structure des données deviennent relativement simples et rapides.
J'ai fait un projet de taille conséquente suivant cette méthode, ça m'a vraiment beaucoup facilité la vie car le client n'avait pas d'idée bien précise de ce qu'il voulait, et le client a été très satisfait du résultat et de la réactivité qu'on a pu obtenir alors que j'étais presque le seul à bosser dessus.
Pour prendre quelques exemples:
- le nombre et le type des champs de nos données changeait tout le temps et n'était défini nulle part, donc (en une demie journée) j'ai fait en sorte que les modèles du projet puissent contenir un nombre indéterminé de champs qui n'étaient pas des colonnes de la base de données mais stockées dans un champ fourre-tout. Au niveau applicatif, c'est entièrement transparent. C'est à dire que pour créer un champ, il suffit de lui affecter une valeur (livre.prix = 10 crée le champ prix s'il n'existe pas).
- j'ai dû rajouter au projet une gestion des droits permettant de rendre des champs accessibles seulement à certaines personnes en fonction d'une validation des données par d'autres personnes. Ce n'était pas prévu. En quelques heures, j'ai pu coder une solution élégante et plus générique que ce qui était demandé.
- j'ai dû faire en sorte qu'un formulaire puisse être édité par parties, sans qu'on puisse jamais modifier une partie déjà saisie. C'est à dire que les champs que l'on remplit à un moment ne sont plus modifiables par la suite. Le code qui fait ça doit représenter une trentaine de ligne avec beaucoup de redondance.
Je ne sais pas si ce sont des exemples très pertinent, mais ça montre que même quand tu es sous pression au niveau des deadlines, avec Rails tu peux bricoler des solutions rapidement et conserver une organisation propre et élégante. L'important là dedans, ce n'est pas le choix parfois discutable d'implémentation, c'est que les délais sont toujours de l'ordre de quelques heures, et qu'on ne se retrouve pas avec du code non maintenable à la fin.