Optimisation du code
Améliorez les performances visibles par l'utilisateur et la fiabilité tout en gardant le code compréhensible et le coût opérationnel proportionné. Optimisez la charge de travail existante ; n'ajoutez pas de complexité pour une échelle hypothétique future.
Workflow
- Définir l'objectif et les garde-fous. Identifiez le point d'accès, tâche, requête, charge de travail et résultat souhaité pertinents. Choisissez uniquement les métriques qui comptent : par exemple, latence p95/p99, débit, CPU, mémoire, taux d'allocation, nombre de requêtes base de données, allers-retours de dépendances, taux d'erreur ou saturation. Préservez le comportement, la cohérence, la sécurité et les contrats d'erreur existants. Posez une seule question ciblée uniquement lorsqu'un objectif ou une charge de travail manquant empêche un choix éclairé ; sinon déduisez ce que vous pouvez de la demande et du code.
- Établir une base de référence. Utilisez les traces, profils, plans de requêtes, métriques, tests ou un benchmark représentatif existants. Gardez l'entrée, l'environnement et la concurrence comparables avant et après. Ne prétendez pas à une accélération à partir d'une intuition ou d'une seule mesure bruyante. Évitez d'exécuter des tests de charge ou une analyse coûteuse de requêtes en production sans autorisation.
- Trouver le goulot d'étranglement. Tracez le chemin critique de bout en bout et utilisez le profilage ou l'instrumentation pour distinguer le travail CPU, le blocage, le temps base de données, les attentes réseau, la sérialisation, la contention de verrou et la mise en file d'attente. Inspectez le motif réel de requête/appel et les données représentatives. Préférez les preuves à un nettoyage large ou à une micro-optimisation. Si le goulot d'étranglement n'est pas établi, signalez l'incertitude et proposez la plus petite mesure utile avant d'apporter des modifications invasives.
- Choisir la modification la plus petite et efficace. Optimisez un goulot d'étranglement matériel à la fois lorsque c'est pratique. Préservez la sortie, l'ordre, le comportement d'échec, la sémantique des transactions et les contrôles de sécurité. N'échangez pas l'exactitude ou la fiabilité pour un gain de benchmark. Suivez les conventions du dépôt et évitez les refactorisations non liées.
- Vérifier les deux résultats. Exécutez les tests de correction pertinents et comparez la même charge de travail représentative avant et après. Vérifiez que la métrique cible s'est améliorée et que les garde-fous — en particulier la latence de queue, les erreurs, la mémoire et la saturation des dépendances — n'ont pas régressé. Si une comparaison significative n'est pas disponible, dites-le et évitez de présenter une modification non mesurée comme une optimisation prouvée.
- Rapporter le résultat. Indiquez brièvement le goulot d'étranglement et ses preuves, la modification apportée ou recommandée, la validation et l'impact mesuré (ou pourquoi il n'a pas pu être mesuré), et tout compromis matériel. Pour un audit ou une demande de plan, priorisez les découvertes par preuves, impact probable, effort et risque au lieu de modifier le code.
Optimisation des bases de données et de l'accès aux données
- Comptez les requêtes et inspectez les motifs d'accès ORM/base de données. Supprimez les lectures ou écritures N+1 avec une jointure, un lot ou une opération ensembliste appropriée ; vérifiez le nombre de requêtes et préservez l'ordre des résultats et le comportement des enregistrements manquants.
- Ne récupérez que les colonnes et lignes nécessaires. Utilisez la pagination ou le streaming pour les grands ensembles de résultats ; poussez le filtrage et l'agrégation appropriés vers la base de données au lieu de charger de grands ensembles de données dans la mémoire de l'application.
- Utilisez le plan de requête et les prédicats réels pour justifier les index. Vérifiez la sélectivité, les besoins de tri/joindre, les index existants et la surcharge d'écriture/stockage. N'ajoutez pas d'index spéculatifs ou en double. Validez le plan et la latence sur des données représentatives ; utilisez l'analyse basée sur l'exécution du plan uniquement dans un environnement sûr.
- Réduisez les allers-retours inutiles et maintenez les transactions et les portées de verrou pas plus larges que nécessaire. N'affaiblissez pas les contraintes, l'isolation, la validation ou la cohérence comme un raccourci.
- N'ajoutez du cache que lorsque la réutilisation mesurée le justifie. Définissez la fraîcheur, l'invalidation, la portée de la clé et le comportement en cas d'échec ; n'introduisez pas un cache comme réponse par défaut à une requête lente.
Optimisation des appels backend et de service
- Supprimez les appels redondants, regroupez les requêtes compatibles et parallélisez uniquement les appels vraiment indépendants. Gardez la concurrence bornée, préservez l'ordre/les dépendances requis et tenez compte de la capacité en aval.
- Réutilisez les clients et les pools de connexions. Définissez des délais/timeouts adaptés au budget de la requête et propagez l'annulation là où elle est supportée.
- Ne réessayez que les échecs transitoires lorsque l'opération est sûre à réessayer. Limitez les tentatives et le temps total de réessai, utilisez un backoff avec jitter et évitez de réessayer à plusieurs niveaux de manière à amplifier la charge. N'ajoutez pas de tentatives, de coupe-circuits ou de files d'attente sans un mode d'échec démontré qu'ils traitent.
- Réduisez les charges utiles trop volumineuses ou la sérialisation répétée uniquement lorsqu'elles sont matérielles pour le chemin mesuré. Maintenez intacts les sémantiques d'échec de service requises ; rendez la dégradation progressive explicite pour les dépendances optionnelles.
Runtime, fiabilité et maintenabilité
- Préférez le correctif le plus efficace soutenu par des preuves : améliorez la complexité algorithmique, supprimez le travail répété, réduisez les allocations/copies inutiles ou traitez le blocage et la contention avant les micro-optimisations de bas niveau.
- Gardez l'utilisation des ressources bornée sous concurrence : tenez compte de la mémoire, des files d'attente, des pools, du fan-out, des timeouts, de l'annulation et de la contre-pression. Assurez-vous que les échecs ne créent pas de tempêtes de réessais, de travail non borné ou de fuites de ressources.
- Traitez la performance et la fiabilité comme des résultats au niveau système. Un appelant plus rapide qui surcharge une base de données ou augmente les taux d'erreur n'est pas une optimisation.
- Appliquez YAGNI : n'ajoutez pas de dépendance, d'abstraction, de cache, d'index, de couche asynchrone, d'option de configuration ou de changement d'architecture pour un goulot d'étranglement hypothétique. Préférez un changement local clair ; si la complexité est nécessaire, expliquez le bénéfice mesuré et son coût de maintenance.
- Ne supprimez pas la validation d'entrée, l'autorisation, l'observabilité ou les contrôles de sécurité pour gagner un temps négligeable. Ne remplacez pas un code lisible par une micro-optimisation plus difficile à maintenir à moins que le gain mesuré ne soit matériel.
Notes de vérification
- Comparez des charges de travail équivalentes avec des exécutions reproductibles et suffisamment d'échantillons pour distinguer le signal du bruit. Utilisez les distributions (en particulier la latence de queue) lorsque c'est pertinent, pas seulement les moyennes.
- Vérifiez le comportement fonctionnel et les cas limites affectés par le batching, le caching, le parallélisme, la pagination, les réessais ou la concurrence. Ajoutez des tests ciblés là où ils protègent un invariant significatif, comme le nombre de requêtes, l'ordre, le comportement de timeout ou le repli de service optionnel.
- Re-profilez après le changement : les goulots d'étranglement se déplacent, et une amélioration locale peut transférer le coût à un autre service ou ressource.
- Si l'optimisation ne produit pas d'amélioration matérielle ou si sa complexité l'emporte sur le bénéfice, annulez-la ou déconseillez-la.