Trolldi : 10 lois et principes de l'ingénierie logicielle qui sont souvent négligés

Comment les développeurs peuvent les appliquer à leur travail

Le génie logiciel est un domaine complexe et dynamique qui nécessite un apprentissage et une adaptation constants. Cependant, certains principes et lois fondamentaux ont été établis au fil des années et peuvent aider les ingénieurs logiciels à concevoir, développer et maintenir des systèmes logiciels de haute qualité. Malheureusement, ces lois sont souvent ignorées par les ingénieurs logiciels, intentionnellement ou non, ce qui entraîne divers problèmes et défis. Voici 10 lois sur le génie logiciel que les ingénieurs logiciels aiment ignorer, la raison pour laquelle elles sont importantes et comment elles peuvent être appliquées dans la pratique. Bien entendu, il n'y a pas d'ordre dans l'énoncé de ces lois.

1. Loi de Brooks

La loi de Brooks stipule que « l’ajout de main d’œuvre à un projet logiciel tardif permet d’y parvenir plus tard ». Cette loi a été formulée par Fred Brooks dans son livre classique « The Mythical Man-Month », basé sur son expérience en tant que gestionnaire du projet IBM System/360. Brooks a fait valoir que l'ajout de personnes supplémentaires à un projet qui est déjà en retard n'accélérera pas la livraison, mais augmentera plutôt la complexité et les frais de communication, ce qui entraînera des retards supplémentaires et une qualité inférieure.

L’implication de la loi de Brooks est que les projets logiciels doivent être planifiés et dotés en personnel avec soin dès le début, et éviter de modifier la taille ou la composition de l’équipe pendant le processus de développement. Si un projet prend du retard, ajouter plus de personnes n’est pas la solution ; au lieu de cela, la portée du projet doit être réduite, les exigences doivent être hiérarchisées et l'équipe existante doit être motivée et soutenue.

2. Loi de Conway

La loi de Conway stipule que « les organisations qui conçoivent des systèmes… sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations ». Cette loi a été proposée par Melvin Conway en 1968, sur la base de son observation selon laquelle la structure d'un système logiciel reflète la structure de l'organisation qui l'a créé. Par exemple, si une organisation dispose de quatre équipes travaillant sur un système, le système comportera probablement quatre composants principaux.

L’implication de la loi de Conway est que les ingénieurs logiciels doivent être conscients de l’impact des facteurs organisationnels sur la conception de logiciels et essayer de les aligner autant que possible. Par exemple, si un système doit être modulaire et faiblement couplé, l’organisation doit également adopter une structure modulaire et faiblement couplée, avec des limites et des interfaces claires entre les équipes. À l’inverse, si un système doit être intégré et cohérent, l’organisation doit également favoriser la collaboration et la coordination entre les équipes.

3. Loi de Hofstadter

La loi de Hofstadter stipule que « cela prend toujours plus de temps que prévu, même si l’on prend en compte la loi de Hofstadter ». Cette loi a été inventée par Douglas Hofstadter dans son livre « Gödel, Escher, Bach : An Eternal Golden Braid », comme une manière humoristique de saisir la difficulté d'estimer le temps nécessaire pour accomplir des tâches complexes. Hofstadter a expliqué que cette loi résulte de la nature récursive de la cognition humaine, qui conduit à sous-estimer la complexité et l'imprévisibilité de la réalité.

L’implication de la loi de Hofstadter est que les ingénieurs logiciels doivent être prudents et réalistes lorsqu’ils font des estimations, et éviter d’être trop confiants ou optimistes. Ils doivent également tenir compte de divers facteurs pouvant affecter la durée d'une tâche, tels que les dépendances, les risques, les incertitudes, les boucles de rétroaction, les tests, le débogage, la refactorisation, la documentation, etc. De plus, ils doivent surveiller et mettre à jour régulièrement leurs estimations et communiquer clairement aux parties prenantes.


4. La loi de Postel

La loi Postel stipule que « soyez conservateur dans ce que vous faites, soyez libéral dans ce que vous acceptez des autres ». Cette loi est également connue sous le nom de principe de robustesse ou principe de tolérance. Elle a été formulée par Jon Postel en 1980, comme ligne directrice pour la conception de protocoles réseau. Postel a suggéré que les systèmes logiciels devraient suivre des normes strictes lors de l'envoi de données ou de messages à d'autres systèmes, mais accepter les données ou les messages qui ne sont pas entièrement conformes aux normes, à condition qu'ils puissent être interprétés correctement.

L’implication de la loi de Postel est que les ingénieurs logiciels doivent s’efforcer de rendre leurs systèmes robustes et interopérables avec d’autres systèmes, en adhérant aux protocoles et normes établis lorsque cela est possible, mais également en étant flexibles et adaptables lorsque cela est nécessaire. Ils doivent également éviter de faire des hypothèses ou d’imposer des restrictions sur les données ou les messages qu’ils reçoivent d’autres systèmes, et gérer les erreurs ou les exceptions avec élégance.

5. Principe de Pareto

Le principe de Pareto stipule que « pour de nombreux événements, environ 80 % des effets proviennent de 20 % des causes ». Ce principe est également connu sous le nom de règle des 80/20 ou de loi du plus petit nombre. Il doit son nom à Vilfredo Pareto, un économiste italien qui a observé que 80 % des terres italiennes appartenaient à 20 % de la population. Le principe a été appliqué à divers domaines, y compris le génie logiciel, où il peut être utilisé pour identifier les facteurs ou fonctionnalités les plus importants ou les plus influents d'un système.

L'implication du principe de Pareto est que les ingénieurs logiciels doivent concentrer leurs efforts et leurs ressources sur les 20 % de facteurs ou de fonctionnalités qui produisent 80 % de la valeur ou de l'impact du système. Ils doivent également prioriser et résoudre les 20 % de bogues ou de défauts qui provoquent 80 % des erreurs ou des pannes du système. Ce faisant, ils peuvent faire plus avec moins et améliorer l’efficience et l’efficacité de leur travail.


6. Principe DRY

Le principe DRY stipule que « chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité au sein d'un système ». Ce principe est également connu sous le nom de Don’t Repeat Yourself (d'où l'acronyme DRY, l'équivalent en français est Ne vous répétez pas) ou Avoid Duplication. Il a été introduit par Andy Hunt et Dave Thomas dans leur livre « The Pragmatic Programmer », comme moyen de réduire la redondance et l'incohérence des systèmes logiciels. Hunt et Thomas ont fait valoir que la duplication du code, des données ou de la logique peut entraîner des problèmes de maintenance et d'évolution, tels qu'une complexité accrue, une lisibilité réduite et une probabilité accrue d'erreurs.

L'implication du principe DRY est que les ingénieurs logiciels doivent éviter de se répéter lors de l'écriture de code, de données ou de logique, et utiliser plutôt des techniques d'abstraction, de modularisation et de réutilisation pour créer une source unique de vérité pour chaque élément de connaissance du système. Ils doivent également refactoriser leur code, leurs données ou leur logique chaque fois qu'ils constatent une duplication, et les maintenir synchronisés et cohérents dans tout le système.

7. Principe YAGNI

Le principe YAGNI stipule que « vous n’en aurez pas besoin ». Ce principe est également connu sous le nom de "Ne construisez pas ce dont vous n’avez pas besoin" ou "Évitez la suringénierie". Il a été popularisé par Ron Jeffries, l'un des fondateurs d'Extreme Programming (XP), comme moyen d'éviter le gaspillage et la complexité des systèmes logiciels. Jeffries a conseillé aux ingénieurs logiciels de mettre en œuvre uniquement les caractéristiques ou fonctionnalités requises par les user stories ou spécifications actuelles, et de ne pas anticiper les besoins ou exigences futurs qui pourraient ne jamais se matérialiser.

L'implication du principe YAGNI est que les ingénieurs logiciels doivent se concentrer sur la fourniture de valeur aux utilisateurs et aux parties prenantes aussi rapidement et simplement que possible, et éviter d'ajouter des caractéristiques ou fonctionnalités inutiles qui peuvent augmenter le coût, le temps et les risques du projet. Ils devraient également accepter le changement et s’adapter aux exigences nouvelles ou changeantes à mesure qu’elles apparaissent, plutôt que d’essayer de les prévoir ou de les contrôler à l’avance.

8. Principe KISS

Le principe KISS stipule que « keep it simple, stupid ». Ce principe est également connu sous le nom de "Keep It Simple and Straightforward" ou "Évitez la complexité". Il a été attribué à Kelly Johnson, ingénieur chez Lockheed Martin, qui a mis son équipe au défi de concevoir des avions pouvant être réparés par un mécanicien moyen avec des outils de base. Le principe implique que la simplicité est une qualité souhaitable dans les systèmes logiciels, car elle peut améliorer la compréhensibilité, la convivialité, la fiabilité, les performances et la maintenabilité.

L'implication du principe KISS est que les ingénieurs logiciels doivent s'efforcer de rendre leurs systèmes aussi simples que possible, mais pas plus simples que nécessaire. Ils doivent éviter d’utiliser des technologies, des algorithmes, des modèles ou des conceptions complexes ou obscurs qui ne sont pas justifiés par le domaine du problème ou par les exigences du système. Ils doivent également utiliser des conventions de dénomination, des normes de codage, des pratiques de documentation et des méthodes de communication claires et cohérentes pour...