IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Stéphane le calme

953PARTAGES

19  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 01/09/2023 à 20:56
Citation Envoyé par Stéphane le calme Voir le message
Quelle est la loi ou le principe de l’ingénierie logicielle que vous contestez ou que vous remettez en question ? Sur quels arguments ou expériences vous basez-vous ?
Je conteste la partie "be liberal in what you accept" de la loi de Postel / du principe de robustesse, quoique ça dépend comment on l'interprète.

Pour résumer ma position, si on complique l'implémentation pour pouvoir recevoir n'importe quoi en entrée et corriger les inputs à la volée, alors on finit par recevoir n'importe quoi en entrée et, le jour où on veut migrer vers une autre solution moins tolérante avec les données farfelues en entrée, on découvre des problèmes.

Par exemple, en Python, je trouve dommage que Pydantic (utilisé par FastAPI) soit laxiste par défaut. Un mode strict existe, mais on sait bien que les développeurs privilégient les choix par défaut. Du coup, si un programme utilise Pydantic en mode laxiste alors, le jour où il sera remplacé par autre chose, par exemple msgspec (utilisé par Litestar) qui est moins tolérant avec les données farfelues, il y aura un risque que des problèmes cachés sous le tapis jusqu'alors remontent à la surface.
7  1 
Avatar de binarygirl
Membre chevronné https://www.developpez.com
Le 02/09/2023 à 23:53
C'est une question d'implémentation, par exemple les navigateurs appliquent de longue date le principe de graceful degradation, par exemple si certains attributs CSS ne sont pas reconnus car trop récents ou non standards, alors ils peuvent être ignorés, mais la page devrait dans l'ensemble se présenter correctement.

Dans le contexte des réseaux, on peut appliquer le même principe. Par exemple, si on reçoit un TTL avec une valeur absurde comme 512, on peut se rabattre sur une valeur standard par défaut pour "corriger" l'input défectueux. Il ne faudrait pas qu'un fuzzer ou un test d'intrusion fasse planter la couche réseau, ou produise un buffer overflow. Mais en dépit de cette anomalie, le paquet peut encore être traité et acheminé.

J'imagine que c'est un peu ça l'idée chez Postel.

Si on devait rejeter systématiquement toute page HTML malformée, alors il n'y a pas beaucoup de sites qui fonctionneraient bien.
Pour ce qui est du réseau, rejeter systématiquement tout paquet invalide peut être trop sévère, car il y a des différences d'implémentations entre les systèmes d'exploitation, et elles ne sont pas toujours connues à l'avance par le programmeur. Exemple: la taille du payload d'un ping.
3  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 03/09/2023 à 0:36
Citation Envoyé par binarygirl Voir le message
par exemple si certains attributs CSS ne sont pas reconnus car trop récents ou non standards, alors ils peuvent être ignorés, mais la page devrait dans l'ensemble se présenter correctement.
Concernant la compatibilité ascendante, je ne suis pas contre son existence.

Citation Envoyé par binarygirl Voir le message
Si on devait rejeter systématiquement toute page HTML malformée, alors il n'y a pas beaucoup de sites qui fonctionneraient bien.
Si les navigateurs avaient tous rejeté dès le départ toute page HTML mal formée alors, en pratique, les sites auraient quasiment tous des pages HTML bien formées.

En effet, avant de mettre un site en ligne, on regarde ce que ça donne sur le navigateur. Si on se rend compte que la page est rejetée, alors on la corrige. Sinon, si elle s'affiche bien, alors on se dit que c'est bon. C'est pour cela que j'ai écrit que, « si on complique l'implémentation pour pouvoir recevoir n'importe quoi en entrée et corriger les inputs à la volée, alors on finit par recevoir n'importe quoi en entrée ».

Hélas, aujourd'hui, dans le cas des navigateurs, c'est trop tard. Si un navigateur rejette toute page HTML mal formée, alors les utilisateurs le rejetteront au profit d'autres navigateurs.
4  1 
Avatar de TotoParis
Membre expérimenté https://www.developpez.com
Le 02/09/2023 à 20:59
Citation Envoyé par Pyramidev Voir le message
Je conteste la partie "be liberal in what you accept" de la loi de Postel / du principe de robustesse, quoique ça dépend comment on l'interprète.

Pour résumer ma position, si on complique l'implémentation pour pouvoir recevoir n'importe quoi en entrée et corriger les inputs à la volée, alors on finit par recevoir n'importe quoi en entrée et, le jour où on veut migrer vers une autre solution moins tolérante avec les données farfelues en entrée, on découvre des problèmes.

Par exemple, en Python, je trouve dommage que Pydantic (utilisé par FastAPI) soit laxiste par défaut. Un mode strict existe, mais on sait bien que les développeurs privilégient les choix par défaut. Du coup, si un programme utilise Pydantic en mode laxiste alors, le jour où il sera remplacé par autre chose, par exemple msgspec (utilisé par Litestar) qui est moins tolérant avec les données farfelues, il y aura un risque que des problèmes cachés sous le tapis jusqu'alors remontent à la surface.
D'autant qu'être trop souple fini trop souvent à introduire des risques de sécurité...
1  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 08/09/2023 à 7:52
Je pense que ces regles (à part DRY et SOLID) s'appliquent à tous les projets de développement (pas que informatique) voir à tous les projets.
Dans toutes les entreprises les projets sont ultra structurés avec des jalons "qui garantissent" qu'on ne "glisse" pas pourtant je n'ai connu qu'un projet qui n'a pas glissé et c'était un projet de crise donc je déconseille de reproduire ces méthodes pour des projets en mode nominal, sous peine de ne jamais finir parce qu'on a cramé tout le monde.
1  1 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 08/09/2023 à 12:46
Citation Envoyé par Pyramidev Voir le message
Je conteste la partie "be liberal in what you accept" de la loi de Postel / du principe de robustesse, quoique ça dépend comment on l'interprète.

Pour résumer ma position, si on complique l'implémentation pour pouvoir recevoir n'importe quoi en entrée et corriger les inputs à la volée, alors on finit par recevoir n'importe quoi en entrée et, le jour où on veut migrer vers une autre solution moins tolérante avec les données farfelues en entrée, on découvre des problèmes.

Par exemple, en Python, je trouve dommage que Pydantic (utilisé par FastAPI) soit laxiste par défaut. Un mode strict existe, mais on sait bien que les développeurs privilégient les choix par défaut. Du coup, si un programme utilise Pydantic en mode laxiste alors, le jour où il sera remplacé par autre chose, par exemple msgspec (utilisé par Litestar) qui est moins tolérant avec les données farfelues, il y aura un risque que des problèmes cachés sous le tapis jusqu'alors remontent à la surface.
Sur l'aspect technique du principe, je suis plutôt d'accord, mais ne pratique, dans un projet multi-partie, si tu commences à être le gars qui accepte tout les inputs foireuses et gérer élégamment, bah on va prendre ça comme acquis et tout les merdes des autres partis du projet te tomberont dessus. En bref, je le ferais volontiers pour de la technique pure (protocole réseau) mais certainement pas pour des données métiers mal branlées.

Si les navigateurs avaient tous rejeté dès le départ toute page HTML mal formée alors, en pratique, les sites auraient quasiment tous des pages HTML bien formées.

En effet, avant de mettre un site en ligne, on regarde ce que ça donne sur le navigateur. Si on se rend compte que la page est rejetée, alors on la corrige. Sinon, si elle s'affiche bien, alors on se dit que c'est bon. C'est pour cela que j'ai écrit que, « si on complique l'implémentation pour pouvoir recevoir n'importe quoi en entrée et corriger les inputs à la volée, alors on finit par recevoir n'importe quoi en entrée ».

Hélas, aujourd'hui, dans le cas des navigateurs, c'est trop tard. Si un navigateur rejette toute page HTML mal formée, alors les utilisateurs le rejetteront au profit d'autres navigateurs.
Je trouve le cas du HTML un peu bancale, pour être pris pour exemple, globalement on ferme des balises qui n'ont pas été fermés et on gère le cas ou y'a du texte séparé entre plusieurs balises.

Enfin, il me semble que les optimisations bien aggressives de google pour le mobile avait justement joué sur le fait que les navigateurs étaient tolérant pour gagner de la bande passante.
0  0 
Avatar de vivid
Membre régulier https://www.developpez.com
Le 11/09/2023 à 13:50
faire preuve de bonne fois, lois universelle !
1  1 
Avatar de nifux
Futur Membre du Club https://www.developpez.com
Le 15/09/2023 à 16:50
Citation Envoyé par Pyramidev
Si les navigateurs avaient tous rejeté dès le départ toute page HTML mal formée alors, en pratique, les sites auraient quasiment tous des pages HTML bien formées.
Après peux être qu'Internet serait réduite à portion congrue et à l'élite qui fait des pages bien formée... le minitel ?

Les solutions doivent pouvoir être flexibles pour permettre l'appropriation par des non initiés. Toutes ses applications qui sont abandonnées car elles ne permettent pas aux utilisateurs d'entrer leurs données sans avoir démontrées au préalable leur utilité.

Citation Envoyé par TotoParis
D'autant qu'être trop souple fini trop souvent à introduire des risques de sécurité...
Quant aux règles de sécurité... Il faut faire le distinguo entre ce qui mérite sécurité et ce qui ne mérite pas.
Autant je comprends l'intérêt de la double authentification pour mon site de banque ou mon hébergeur. Autant systématiser la double authentification pour... le site de la SNCF.... cela créé là encore de la rigidité et des risques d'abandon.
1  1 
Avatar de Jacti
Membre habitué https://www.developpez.com
Le 20/09/2023 à 12:54
Tout est dit dans la norme ISO/CEI/IEEE 12207 intitulée " Ingénierie des systèmes et du logiciel ". Le reste n'est que littérature et chacun y va de son petit couplet approximatif qui n'apporte rien au sujet.
Je constate, par ailleurs, que la plupart des commentaires ne parle que de Web, HTML and co qui n'est que la "mousse" des logiciels d'aujourd'hui alors que la majorité des logiciels n'est pas dans ce domaine.
0  1