Technique n°2 — se limiter strictement au cahier des charges
Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.
Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu "qui fait le job" mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo