Le génie logiciel, c’est l’art de faire du logiciel de qualité.
D’accord, mais c’est quoi la qualité ?
Bonne question, merci.
La qualité, c’est la combinaison de plusieurs choses :
- Un code qui répond au besoin. Et oui, pas la peine de philosopher, la première des choses est de couvrir le besoin fonctionnel.
- Un code sans bug. Bon, c’est un « graal », tout programme a ses bug. La question est donc de réduire au maximum les bugs et surtout d’éviter les bug « mortels ».
- Une application qui répond vite. Ce critère est particulièrement important pour le web et le e-commerce en particulier. Quelques dixième secondes de trop, et les clients sont parti…
- Une application scallable. C’est la suite logique du point précédent. L’application doit répondre vite, même en cas d’affluence. Le système doit donc être capable d’avaler des pics de charges, et il doit être possible de faire grossir le système, en rajoutant des serveurs. ça à l’air de rien, mais si on n’y a pas pensé, la montée en charge va demandé pas mal de boulot.
- Une application robuste. La particularité des applications Internet, c’est, entre autre, qu’elle doivent « vivre » dans un environnement instable. L’application, pour tourner, s’appuie sur tout un tas de services tiers. Et bien la robustesse, c’est que l’application garde un comportement « sain » même quand des composants tiers tombent. On appelle ça la dégradation douce (smooth degradation).
- Une application évolutive. L’application va vivre, et il doit être facile de faire évoluer l’application, pour un cout raisonnable.
Bon, on pourrait en ajouter mais là, on a l’essentiel.
ça, c’est l’objectif.
Maintenant, la question, c’est : comment on atteint cet objectif ?
Là, la réponse n’est pas simple. Pas simple du tout en fait.
Au delà des objectifs assez factuels (moins de bug), d’autres objectifs sont plus délicats. Ainsi, « une application évolutive » est un objectif délicat. La difficulté est qu’on doit prévoir quels seront les axes d’évolutions. Ainsi, après développement, certaines parties seront faciles à faire évoluer, et d’autres non. La très mauvaise idée est de vouloir « tout faire évoluer ». Cela revient exactement au même que… ne rien dire. Dans ce cas, c’est l’équipe technique qui décide ce qui sera évolutif et ce qui ne le sera pas.
Une autre difficulté est qu’on est sur un terrain très instable. Les technologies évoluent très vite, et les demandes fonctionnelles aussi. Une application web doit donc être particulièrement souple.
Mais dans le même temps, on a rarement le temps de bien analyser, bien concevoir, bien développer. On veut faire vite, avec des équipes plus ou moins compétentes.
Ah la compétence des équipes ! C’est un bon sujet aussi. Puisque faire du logiciel, au final, c’est faire du code, la qualité du code sera directement en lien avec la qualité des développeurs.
En ce moment, la demande est très forte. La conséquence « mécanique » est de baisser le niveau d’expertise des développeurs (Il s’agit bien sûr d’une généralité, et bien sûr, il y a de très très bon développeurs).
Suite au prochain épisode 😉
J’aimerai juste souligner que les donneurs d’ordre peuvent parfois avoir une part de responsabilité en refusant d’investir assez de temps et de moyens dans l’analyse & la documentation. J’ajoute la doc car pour mois un code de qualité est un code documenté.
@ Taoufik. En fait la doc est juste un « préalable ». Pas du « Nice to Have », 100% d’accord. Le pb de la doc, c’est pas tant sa création que sa mise à jour. On commence, on documente, c’est propre, puis on passe sous stress, on a des délais serrés, des bugg non attendu, et la Oh surprise, la doc ne suit plus (malgré les outils associés aux actuels IDE)
Hello les accros du génie logiciel 😉
Je ne suis pas trop d’accord avec vous pour la doc, en tout cas pas la doc tel qu’on l’entend dans les méthodes classiques (Merise). La « grosse spec » qui doit être à jour ne l’est jamais…
Par contre, j’aurais été un lecteur de ce billet (je deviens complètement schizophrène 😉 ), j’aurais bondi sur la première ligne : répondre au besoin fonctionnel !
ça veut dire quoi ? Ou est la référence de ce besoin ?
Justement, elle n’existe pas ! et la vouloir est illusoire.
Juste une parenthèse, je vais dire lâchement et sans explications, Merise est une méthode obsolète, il faudrait arrêter d’en parler une fois pour toutes.
Pour pousser la philosophie plus loin, je dirais que la référence du besoin est dans la problématique …