URL: https://linuxfr.org/users/barmic/journaux/lutter-contre-l-overengineering Title: Lutter contre l'overengineering Authors: barmic Date: 2016年05月23日T11:22:24+02:00 License: CC By-SA Tags: franglais, architecture, kiss et linus_torvalds Score: 49 Problématique ============= Lors du développement d’un logiciel (ça existe dans d’autres domaine de l’ingénierie), il arrive « facilement » que l’on fasse de l’overengineering. On entend généralement par là le fait de rendre le programme plus complexe que nécessaire pour effectuer sa tâche. C’est quelque par l’inverse du principe KISS bien connu. Voir la [page wikipedia](https://en.wikipedia.org/wiki/Overengineering). L’overengineering pose problème car en favorisant un critère de qualité logiciel, il nuit aux autres. Par exemple on peut faire de l’overengineering pour avoir des performances optimales et nuire à la maintenabilité du logiciel voir à sa robustesse. Il est aussi possible d’utiliser des structures trop complexes pour améliorer la maintenabilité et rendre le logiciel plus lent et/ou plus complexe. S’il y a bien sûr pleins de cas triviaux où discriminer l’overengineering du design correct est simple, ce n’est pas forcément toujours le cas. C’est en fait généralement plus simple à faire après coup qu’avant... Ce qui rend ce sujet complexe c’est aussi qu’il dépend du logiciel : selon ce qu’il fait et comment il est développé les critères de qualités ont plus ou moins d’importance (vous pouvez vouloir garder un logiciel simple pour augmenter vos chances d’avoir des contributeurs ou vouloir avoir de la performance à tous prix car votre logiciel ne sert à rien s’il répond trop tard). Comment lutter contre ? ======================= La dictature ------------ La meilleure façon de lutter contre ça consiste probablement à avoir de l’expérience. Avoir vu des cas d’overengineering permet de plus facilement comprendre ce qui est important à quel moment. Dans le monde du logiciel libre, ce rôle incombe aux gentils dictateurs de chaque projet qui doivent avoir une vision claire de ce que doit devenir leur projet. Dans le domaine, Linus Torvald pour Linux s’illustre régulièrement. Une information est sortie récemment à ce sujet. Il semble que les créateurs de certains projets à succès (Rails, Django...) n’aiment pas particulièrement le développement ce qui pousse naturellement à être minimaliste (cf : [Les créateurs de Django, PHP et Rails n’étaient pas des passionnés du code](http://www.developpez.com/actu/98843/Le-talent-et-la-passion-suffisent-ils-pour-faire-un-bon-developpeur-Les-createurs-de-Django-PHP-et-Rails-n-etaient-pas-des-passionnes-du-code/)). Le collectif ------------ Une autre façon qui peut aider à lutter contre l’overengineering consiste à multiplier le nombre d’avis différent sur le code. Le fait de faire des revues de code peut permettre de mettre le doigt sur ces problèmes. Mais il faut réunir AMHA un certain nombre de critères : - avoir des avis différents : une équipe de gros bœufs du code qui adorent la métaprgrammation et la création de DSL vont avoir tendance apprécier d’utiliser ces solutions même si elles ne sont pas nécessaires - faire des revues au plus tôt : faire relire son travail avant de l’avoir fini car remettre en cause le design après l’avoir terminé est contre productif (par exemple avec [des relectures à 30 % du travail terminé](https://42floors.com/blog/startups/thirty-percent-feedback)) La structure ------------ Le fait d’organiser un projet sur des temps données permet aussi de limiter l’overengineering. Savoir que l’on a 1 jour pour faire une tâche donnée pousse à commencer par implémenter la version naïve qui marche (mais peut être moins élégante) pour ensuite utiliser le reste du temps à l’amélioration de ce dernier. Cette amélioration sera donc limitée juste par le temps. C’est une façon qui présente le risque inverse de pousser à utiliser des solutions à la va vite pour tenter de tenir les délais. Il y a un juste milieu à trouver. Et vous ? ========= Et toi nal' ? Comment gères-tu ce sujet ? Je sais qu’il y a par ici des amoureux du code qui ont une grande maîtrise du langage qu’ils utilisent. Comment faites-vous pour ne pas trop en faire ?

AltStyle によって変換されたページ (->オリジナル) /