Compromis logiciels
Chaque choix de conception que vous faites ferme la porte à une autre option. Le développement logiciel repose sur des compromis. Vous devez faire ces choix de manière intentionnelle. Si vous ne le faites pas, vous les ferez par accident.
Les compromis courants auxquels vous ferez face :
• Fonctionnalité vs Performance Un code propre est souvent plus lent. Un code rapide est souvent difficile à lire. Utilisez un code lisible pour les processus par lots qui s'exécutent une fois par jour. Utilisez un code optimisé pour les chemins qui s'exécutent des milliers de fois par requête.
• Flexibilité vs Simplicité Les abstractions complexes rendent le code difficile à comprendre. Écrivez le code le plus simple possible pour qu'il fonctionne. Concevez-le de manière à pouvoir l'étendre plus tard.
• Évolutivité vs Coût Concevoir pour un trafic massif coûte plus cher dès maintenant. Mesurer votre taux de croissance vous aide à décider. Si vous croissez de 20 % chaque mois, prévoyez l'avenir. Si vous avez peu de capital, surveillez vos coûts.
• Sécurité vs Utilisabilité Une sécurité extrême peut nuire à l'expérience utilisateur. Nous avons un jour imposé des jetons matériels (hardware tokens) pour un outil d'administration. Le taux de réussite de connexion est passé de 98 % à 84 %. Les ingénieurs se sont retrouvés bloqués lors d'urgences. Nous sommes passés aux notifications push mobiles. Les taux de réussite sont remontés à 96 %. Visez une sécurité raisonnable, pas une sécurité maximale.
Comment prendre de meilleures décisions :
- Soyez explicite sur votre objectif.
- Mesurez les données au lieu de deviner.
- Commencez par une solution simple.
- N'optimisez que lorsque vous en avez la preuve.
- Documentez la raison pour laquelle vous avez fait ce choix.
J'ai un jour tenté d'optimiser un sérialiseur JSON pour gagner quelques microsecondes. Cela a provoqué une fuite de mémoire qui a atteint 300 Mo. Un profiler a montré que les E/S réseau étaient le véritable goulot d'étranglement. Utilisez toujours un profiler avant de réécrire du code.
La dette technique est une réalité. Un raccourci aujourd'hui coûte du temps demain. Lorsque nous avons hérité d'un service mal conçu, nous n'avons pas procédé à une réécriture massive. Nous avons utilisé de petits changements constants. Nous avons fait passer la couverture de tests de 30 % à 78 %. Cela a réduit le temps de correction des bugs de 4 jours à 1,2 jour.
Les compromis ne sont pas permanents. Revoquez vos décisions. Vérifiez si vos optimisations sont toujours pertinentes. Agir de manière intentionnelle évite d'avoir un système médiocre en tout.
Source: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi