Perso, le mec qui me fait du code "super secure" pour un prototype par exemple "parce qu'il faut toujours bien coder", je le paye moitié moins car 50% du temps est pour son plaisir (soit l'affaire prend et j'ai des sous pour refaire une passe "plus propre" après quelques refactoring, soit ça part à la poubelle et on s'en fout du realloc à NULL)
Le problème de cette approche prototype, c'est qu'il ait de grand risque que la phase de mise au propre passe par une réécriture complète. Et là tous les bénéfices du prototype vite fait sont perdus.
De plus la phase de prototype, il y a moins de pression donc on peut prendre un peu plus de temps. Par contre avant la version finale pour la mise en production, c'est le stress, donc la mise au propre est secondaire. Et c'est pour ça qu'on a tant de logiciel en version "stable" qui ne sont rien d'autre que des bétas voir des alphas. Mais dans le monde logiciel, c'est facile de le faire, il n'y a aucune responsabilité.
En prototypage, on peut ne pas faire la gestion d'erreur, mais la prévoir. Ça coûte pas beaucoup de temps et ça permet de se concentrer sur le fonctionnement :
ptr=malloc(size);if(!ptr){/* TODO */}else{memcpy(ptr,pscr,size);/* ... etc ... */}
Et quand le temps est disponible, c'est plus facile de mettre au propre : grep TODO *.
Mais c'est vrai que dans des projets, le rapport temps/propreté peut poser problème, particulièrement dans les petites structures.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Chaque amélioration compte
Posté par Etienne Bagnoud . En réponse au journal realloc. Évalué à 5.
Le problème de cette approche prototype, c'est qu'il ait de grand risque que la phase de mise au propre passe par une réécriture complète. Et là tous les bénéfices du prototype vite fait sont perdus.
De plus la phase de prototype, il y a moins de pression donc on peut prendre un peu plus de temps. Par contre avant la version finale pour la mise en production, c'est le stress, donc la mise au propre est secondaire. Et c'est pour ça qu'on a tant de logiciel en version "stable" qui ne sont rien d'autre que des bétas voir des alphas. Mais dans le monde logiciel, c'est facile de le faire, il n'y a aucune responsabilité.
En prototypage, on peut ne pas faire la gestion d'erreur, mais la prévoir. Ça coûte pas beaucoup de temps et ça permet de se concentrer sur le fonctionnement :
Et quand le temps est disponible, c'est plus facile de mettre au propre :
grep TODO *.Mais c'est vrai que dans des projets, le rapport temps/propreté peut poser problème, particulièrement dans les petites structures.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell