Chemins de code optimisés (Lean Code Paths)
Commencez par une opération réelle. Que l'appelant affiche-t-il ou sur quoi agit-il ? Suivez ce besoin à travers l'API, le service, le middleware, l'ORM et le SQL exécuté. Éliminez le travail superflu au point le plus précoce sur le chemin affecté. Utilisez un code simple et peu coûteux dans le développement courant. Localisez le goulot d'étranglement avant d'introduire une optimisation plus complexe.
Règles d'implémentation
- Réutilisez les données déjà disponibles dans la requête. Regroupez les requêtes, écritures et appels distants chaque fois que l'opération le permet. Scindez les lots aux limites réelles. Vérifiez ce qu'une API de traitement par lots fait en interne. Les appels parallèles par élément entraînent toujours un aller-retour par élément.
- Choisissez les structures de données en fonction du motif d'accès. Parcourez une collection existante pour une recherche unique. Construisez un dictionnaire indexé une fois pour des correspondances répétées. Sortez le calcul et le parsing invariants des boucles. Sur les chemins chauds, éliminez les tris répétés, les grandes copies et les collections intermédiaires inutilisées. Passez les valeurs existantes au sein d'un processus au lieu de faire un aller-retour via JSON pour convertir entre des formes identiques.
- Analysez et validez les entrées externes là où elles entrent. Les fonctions internes peuvent utiliser des valeurs dont le point d'entrée a déjà vérifié la présence, le type ou la plage. Avant d'ajouter une branche défensive, identifiez une entrée atteignable et l'échec que la branche empêche. Attrapez une erreur là où le code peut se rétablir, ajouter un contexte utile, ou la traduire en un contrat d'erreur différent.
- Incluez la propriété dans le prédicat de lecture ou d'écriture lorsque c'est possible. Passez l'identité de tâche vérifiée, la propriété et les arguments à travers des modules, planificateurs et exécuteurs de confiance. Un transfert, rappel ou délégation au sein de la même tâche ne nécessite pas en soi une autre vérification ou recherche. Lorsqu'une nouvelle entrée ou une frontière de confiance indépendante est impliquée, vérifiez les garanties que le récepteur ne peut pas hériter. Appliquez les conditions mutables telles que le solde, l'état antérieur et l'idempotence de manière atomique à l'écriture qui en dépend.
- Utilisez une valeur par défaut appropriée du framework ou définissez une règle fixe une fois là où elle appartient. Ajoutez un paramètre de configuration uniquement pour une différence de déploiement réelle, un besoin de réglage indépendant, ou une demande explicite de l'utilisateur. Utilisez d'abord le magasin de configuration ou de secrets existant. Créez un fichier uniquement lorsque le mécanisme existant ne peut pas répondre au besoin. Ajoutez des interrupteurs de fonctionnalité uniquement sur demande.
- Préférez les contraintes d'unicité, les écritures conditionnelles, les incréments atomiques et les transactions courtes. Avant d'ajouter un verrou applicatif, identifiez les opérations concurrentes, le résultat incorrect, et pourquoi les mécanismes existants ne peuvent pas l'empêcher. Verrouillez la plus petite ressource pour l'intervalle le plus court. Vérifiez chaque scripteur et tout résultat tardif avant de supprimer un verrou existant.
- Préservez les règles d'accès, l'ordre, la pagination, la sémantique de succès partiel, la qualité de sortie et la récupération. Discutez des modifications matérielles du comportement ou du coût avec l'utilisateur. Réutilisez le middleware, les points d'entrée de test et les critères d'acceptation du projet.
Lisez la référence pertinente
- Pour SQL, le comportement ORM, les index, les opérations par lots, les transactions et les verrous, lisez Accès à la base de données et transactions.
- Pour la sélection de champs de l'API, le middleware, le cache, les files d'attente, les gros fichiers ou le chargement frontend, lisez la section pertinente de Runtime et middleware.
Vérification
- Exercez les API modifiées via le point d'entrée réel de l'application dans un environnement de test autorisé. Vérifiez la réponse, les appelants affectés et l'état métier final. Lors de la suppression de champs, inspectez la charge utile réelle et, pour les chemins basés sur une base de données, le SQL exécuté. Pour le regroupement par lots, comparez le nombre de requêtes pour un petit lot et un lot complet. Testez la race condition, la requête dupliquée ou le chemin de récupération pertinent lorsque des effets secondaires sont impliqués. Vérifiez les tâches en arrière-plan et les calculs locaux via leurs points d'entrée normaux et inspectez leurs sorties. Suivez les vérifications requises du projet et l'intégration continue.
- L'utilisateur est propriétaire de l'acceptation visuelle et manuelle du Web. Passez la page, les actions et les résultats attendus, et marquez cette acceptation comme en attente. Exécutez les vérifications de construction, de type ou d'interaction pertinentes pour les modifications frontend. Si l'utilisateur délègue les tests navigateur, couvrez la portée demandée.
- Appuyez les affirmations d'accélération par des mesures avant et après dans le même environnement avec des données et une concurrence équivalentes. Enregistrez le nombre d'échantillons et l'état du cache. Choisissez des métriques qui exposent le coût sous investigation, telles que la latence de queue, le débit, le nombre de requêtes, les lignes scannées, les octets transférés ou la mémoire de pointe. Pour les tâches asynchrones, distinguez l'acceptation, le délai de file d'attente et l'achèvement. Signalez une exécution unique comme une exécution unique. Sans référence comparable, rapportez uniquement ce qui a été mesuré. Gardez la vérification proportionnelle au changement.