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 rendre leurs systèmes faciles à comprendre et à utiliser.
9. Principes SOLID
Les principes SOLID sont un ensemble de cinq principes qui guident les ingénieurs logiciels dans la conception et le développement de systèmes logiciels faciles à maintenir et à étendre. Les principes sont :
- (Single Responsibility Principle) Principe de responsabilité unique : une classe ou un module doit avoir une et une seule raison de changer.
- (Open/Closed Principle) Principe ouvert/fermé : une classe ou un module doit être ouvert pour extension, mais fermé pour modification.
- (Liskov Substitution Principle) Principe de substitution de Liskov : une sous-classe ou une classe dérivée doit être substituable à sa superclasse ou à sa classe de base.
- (Interface Segregation Principle) Principe de ségrégation des interfaces : un client ne doit pas être obligé de dépendre de méthodes ou de propriétés qu'il n'utilise pas.
- (Dependency Inversion Principle) Principe d'inversion de dépendance : une classe ou un module doit dépendre d'abstractions plutôt que de concrétions.
L'implication des principes SOLID est que les ingénieurs logiciels doivent suivre ces principes lors de la conception et du développement de systèmes logiciels, car ils peuvent les aider à atteindre une cohésion élevée, un faible couplage, une abstraction élevée, une faible complexité, une testabilité élevée, une réutilisabilité élevée et une modularité élevée dans leurs systèmes.
10. Loi de Murphy
La loi de Murphy stipule que « tout ce qui peut mal tourner tournera mal et au pire moment possible ». Cette loi est également connue sous le nom de loi des conséquences involontaires ou du credo du pessimiste. Elle doit son nom à Edward Murphy, un ingénieur qui a travaillé sur un projet visant à mesurer la tolérance à l'accélération humaine en 1949.
La loi de Murphy est importante, car elle reflète la complexité et l’imprévisibilité de la réalité, et invite à la prudence et au réalisme face aux risques et aux incertitudes. Elle peut être appliquée par les ingénieurs logiciels de deux manières :
- la première manière est de prendre la loi de Murphy comme une règle de conception. Dans ce cas, on ne considère pas la loi de Murphy comme vraie, mais on conçoit tout système comme si elle l’était. En particulier, un système doit être à l’épreuve non seulement des accidents les plus improbables, mais aussi des manœuvres les plus stupides de la part de l’utilisateur. Elle justifie donc les principes de la conception de sûreté préconisant de planifier et d’éliminer dès la conception les possibilités de mauvaise utilisation, par exemple à l’aide de détrompeurs ;
- la deuxième manière est de prendre la loi de Murphy comme une source d’humour. Dans ce cas, on utilise la loi de Murphy pour dédramatiser les situations difficiles ou frustrantes, et pour rire des aléas et des erreurs qui peuvent survenir dans le développement logiciel. Elle permet donc de cultiver un état d’esprit positif et résilient face aux obstacles et aux échecs.
Et vous ?
Connaissiez-vous toutes ces lois et principes ? Sinon, lesquels ne connaissiez-vous pas ? Quel est le principe de l’ingénierie logicielle ou la loi que vous trouvez le plus utile ou le plus pertinent dans votre travail ? Pourquoi ? Quel est le principe de l’ingénierie logicielle ou la loi que vous avez le plus de mal à respecter ou à appliquer dans votre travail ? Quelles sont les difficultés ou les conséquences que vous rencontrez ? Quel est le principe de l’ingénierie logicielle ou la loi que vous contestez ou que vous remettez en question ? Sur quels arguments ou expériences vous basez-vous ? Quel est le principe de l’ingénierie logicielle ou la loi qui n’a pas été mentionné ici, mais que vous considérez comme important ou intéressant ? Comment le définiriez-vous et comment l’utiliseriez-vous ? Quel est le principe de l’ingénierie logicielle ou la loi qui vous fait le plus rire ou qui vous amuse le plus ? Avez-vous des anecdotes ou des exemples à partager ? 
Envoyé par Stéphane le calme
