Modifier un moteur de stockage de base de données sans perdre en vitesse ni en compatibilité

## Écrire du code lisible qui gère correctement les erreurs et la concurrence Écrivez un code clair et auto-documenté, avec des noms explicites et des commentaires pour les invariants non évidents. Préférez un flux de contrôle lisible aux astuces ingénieuses qui n’offrent qu’un gain de vitesse marginal. Respectez le formateur, les règles de nommage et les modèles structurels du dépôt. Utilisez systématiquement le type standard de statut ou d’erreur du projet. Propagez les échecs avec assez de contexte pour identifier l’opération qui a échoué. N’ignorez jamais silencieusement une erreur ou une valeur de statut non vérifiée. Évitez les assertions pour les échecs récupérables dans les chemins de production. Couvrez les entrées non valides, l’épuisement des ressources, les échecs d’E/S, la corruption et la progression partielle. Préservez la sémantique de la base de données, notamment l’ordre des clés, la visibilité des instantanés, la durabilité et le comportement de récupération. Documentez les hypothèses de synchronisation à côté des données qu’elles protègent. Examinez ensemble le verrouillage, les opérations atomiques, l’ordre mémoire, les risques de concurrence critique et les risques d’interblocage. Rendez explicite la libération des ressources dans les chemins de réussite, d’erreur, d’annulation et d’arrêt. Concentrez les commentaires sur les contrats locaux plutôt que sur la justification actuelle d’un seul appelant. Dédupliquez la logique répétée lorsqu’une abstraction partagée possède une responsabilité stable et cohérente. Ne déclarez pas une modification sensible à la correction prête à être fusionnée tant que les chemins d’échec et le comportement concurrent n’ont pas été testés. ## Accélérer le code selon sa fréquence d’exécution, preuves de mesure à l’appui Considérez la prise en compte des performances comme une exigence du travail sur les moteurs de stockage. Établissez la correction avant la micro-optimisation, tout en choisissant dès le départ des algorithmes et des structures de données solides. Classez le code affecté selon sa fréquence d’exécution : - Dans les chemins chauds, chaque allocation, copie, branchement et défaut de cache est multiplié par les opérations fréquentes. - Les chemins tièdes exigent un équilibre mesuré entre clarté et rapidité. - Les chemins froids privilégient la maintenabilité, sauf si le profilage révèle un coût significatif. Étayez les affirmations de performance avec des analyses comparatives et des données de profilage. Comparez avec une référence appropriée et indiquez la charge de travail, la configuration et la variance. Réduisez l’allocation dynamique dans les chemins chauds par la réutilisation, la préallocation, des arènes ou des pools de mémoire lorsque cela est justifié. Préférez les déplacements, les vues, les références et les opérations sur place aux copies inutiles. Organisez les données et les modèles d’accès afin de favoriser la localité et d’éviter le faux partage. Sortez les calculs invariants des boucles, regroupez les opérations répétées et réduisez les branchements imprévisibles. N’utilisez les indications de probabilité de branchement que pour les cas réellement rares ou coûteux, et non pour les configurations courantes. Favorisez la vectorisation par le compilateur grâce à une disposition des données adaptée avant de recourir à des fonctions intrinsèques explicites. N’utilisez explicitement SIMD que lorsque cette approche est prise en charge, mesurée et maintenable. Appliquez RAII et une propriété claire afin d’éviter les fuites tout en conservant un faible surcoût. Ne conservez pas une optimisation complexe qui n’apporte aucun bénéfice reproductible. ## Concevoir des API compatibles avec des options ayant chacune un seul rôle Conservez la politique de haut niveau dans l’appelant ou la couche de politique. Exposez des mécanismes précis et réutilisables depuis les couches inférieures. Ne rendez pas le code générique dépendant de l’identité ou de la justification d’un appelant particulier. Attribuez à chaque indicateur ou paramètre un comportement unique et cohérent. Remplacez les booléens qui regroupent la propriété, la mise en cache, le mode d’E/S et la prélecture par des champs explicites ou un objet d’options. Ne déduisez pas la politique de détails d’implémentation accessoires, tels que des poignées de cache ou l’état du lecteur. Utilisez des assertions, des interfaces plus étroites et des noms plus clairs pour rendre les contrats applicables. Veillez à ce que les nouvelles API respectent les conventions établies de nommage, d’ordre des paramètres, de types de retour et de gestion des erreurs. Utilisez des options sûres du point de vue des types, notamment des types entiers à largeur fixe et des énumérations à portée limitée lorsque cela convient. Validez les valeurs des options et renvoyez des erreurs claires. Rendez les modifications de configuration dynamique sûres pour les threads et vérifiez quand elles prennent effet. Préservez la compatibilité source et binaire, sauf justification exceptionnelle d’une rupture. Examinez la disposition, les symboles et les conventions d’appel lorsqu’une interface binaire publique est exposée. Dépréciez selon le processus documenté sur plusieurs versions et fournissez des conseils de migration. Documentez les API publiques avec leur utilisation, la signification des paramètres, les règles de sûreté des threads, les coûts de performance et les notes de compatibilité. N’exposez pas les types d’implémentation de tiers dans une API publique. ## Réviser le plus à fond le journal d’écriture anticipée et les autres parties à risque Appliquez la révision la plus approfondie à la journalisation préalable, aux tables en mémoire, au compactage, à la récupération et aux autres chemins centraux de la base de données. Testez les modifications centrales sous diverses configurations, méthodes de compactage, défaillances et charges de travail concurrentes. Assurez-vous que le compactage respecte les limites configurées et gère les cas sans fichier ou avec un seul fichier. Considérez les en-têtes publics comme la surface ayant le plus d’incidence sur la compatibilité. Considérez les formats persistants de tables et de blocs comme des contrats de données durables. Vérifiez les sommes de contrôle avec différents choix de compression, tailles de blocs, cas de corruption et frontières de compatibilité. Testez la sémantique de positionnement, d’élément suivant, d’élément précédent, de suppression et d’extrémité des itérateurs. Maintenez l’unicité des clés de cache et assurez-vous que la prélecture respecte les limites de ressources. Mesurez les performances des modifications de tables, de cache et d’utilitaires susceptibles de s’exécuter dans des chemins chauds. Rendez explicites la synchronisation du cache, la propriété de la mémoire et la politique d’éviction. Maintenez les utilitaires facultatifs isolés des éléments internes de la base de données. Pour les options, vérifiez la sûreté des types, la validation, la dépréciation et les mises à jour dynamiques sûres pour les threads. Pour les utilitaires internes, testez les dépassements de capacité par excès et par défaut, les entrées non valides et les contrats d’assertion. N’approuvez pas les modifications à haut risque des formats, de la récupération, du compactage ou du cache sans preuves issues de tests unitaires, d’intégration, de charge et de mesures de performance. ## Synchroniser tous les systèmes de compilation et compiler sur chaque plateforme prise en charge Maintenez tous les systèmes de compilation pris en charge lors de l’ajout ou du retrait d’un fichier source. Mettez d’abord à jour le manifeste source canonique, puis régénérez les fichiers de compilation dérivés avec le générateur approuvé. Ne modifiez pas manuellement un fichier de compilation interne généré. Recherchez les références concernées dans toutes les définitions de compilation, tous les langages, toute la documentation et toutes les implémentations. Utilisez le nombre de processeurs de l’hôte pour les compilations parallèles, dans les limites des ressources. Empêchez des modes de compilation différents de réutiliser des fichiers objets incompatibles. Pour les compilations manuelles, activez le mécanisme du système de compilation qui effectue automatiquement un nettoyage lors d’un changement de configuration. Prenez en charge la matrice du projet couvrant les systèmes d’exploitation, les compilateurs, les bibliothèques standard, les outils d’assainissement et les modes de compilation. Prévoyez Linux, macOS, Windows, les compilateurs natifs et croisés, les compilations de production, les outils d’assainissement, les compilations unifiées et les liaisons de langage lorsqu’ils sont configurés. Préférez les abstractions de portabilité du projet aux API directes des plateformes. Protégez par des conditions les en-têtes, appels, attributs et éléments intégrés propres à une plateforme qui sont inévitables. Incluez directement chaque en-tête standard au lieu de dépendre des inclusions transitives. Assurez-vous que les binaires de production et de charge se compilent sans informations de type à l’exécution lorsque le projet l’impose. Limitez les conversions descendantes à l’exécution aux tests ; ailleurs, utilisez l’utilitaire vérifié de conversion statique du projet. Exécutez les contrôles de source qui rejettent les caractères non pris en charge et les autres contenus incompatibles avec l’intégration continue. Utilisez la ponctuation ASCII dans les commentaires et les chaînes du code source lorsque le dépôt l’exige. ## Écrire des tests reproductibles sans dépendre de pauses Adaptez la profondeur des tests au risque : tests unitaires pour les comportements isolés, tests d’intégration pour les interactions et tests de charge pour la concurrence et les performances. Couvrez les limites, les chemins d’erreur, la récupération, les différences entre plateformes et les cas de régression. Utilisez des cas pilotés par table lorsque les entrées diffèrent mais que le contrat testé est commun. Extrayez des fonctions auxiliaires pour les constructions répétées, les allers-retours et les séquences d’assertions. Séparez les cas limites déterministes de la couverture aléatoire. Préférez l’échantillonnage aléatoire aux produits exhaustifs de paramètres lorsqu’il offre une couverture utile plus large. Utilisez la source aléatoire du projet et affichez la graine afin que les échecs soient reproductibles. N’effectuez pas de pause pendant l’attente d’événements concurrents. Utilisez des points de synchronisation ou des signaux explicites pour contrôler la progression des threads. Limitez l’exécution de chaque test unitaire au moyen d’un délai d’expiration défini. Exécutez en série un petit nombre de tests ciblés et les ensembles plus volumineux au moyen du dispositif de tests parallèles. Répétez les nouveaux tests de concurrence sous charge avec des changements de contexte forcés. Analysez les défaillances intermittentes propres à l’intégration continue avec les outils de reproduction dédiés du projet. Testez toutes les plateformes prises en charge qui sont concernées par les chemins, les API, les compilateurs ou les indicateurs de compilation. Assurez-vous que les échecs des tests indiquent suffisamment d’état pour reproduire la configuration qui les a déclenchés. Ajoutez les nouvelles options de configuration et les fonctionnalités de performance à la couverture des tests de charge et des mesures de performance. Avant soumission, vérifiez dans les tests mis à jour l’absence de duplication et d’état partagé accidentel. ## Ajouter les en-têtes de licence et synchroniser la documentation et les notes de version Ajoutez à chaque nouveau fichier source l’en-tête de licence exigé par le dépôt. Conservez les mentions de droit d’auteur d’origine dans les fichiers dérivés, en plus de l’en-tête du projet. Utilisez le préfixe de commentaire approprié à chaque langage source. Ne remplacez pas une désignation obligatoire de double licence par une déclaration générique de droits. Exécutez le formatage automatique après les modifications et examinez le diff obtenu. Exécutez les outils de maintenance des dépendances et refusez les modifications sans rapport du manifeste. Lors de l’ajout d’une fonctionnalité, évaluez les métriques utiles sans introduire de régression dans les chemins chauds. Exposez les fonctionnalités liées aux performances au moyen de l’outil standard de mesure de performance. Gardez les notes de version brèves, externes et centrées sur le comportement visible par l’utilisateur. Documentez la conception des composants dans l’index du sous-système et dans des chapitres ciblés. Assurez-vous que les sites ou publications générés font référence à des métadonnées d’auteur valides lorsque cela est exigé. Pour une nouvelle API, une nouvelle option ou une dépréciation, suivez la procédure dédiée du dépôt. Mettez à jour les conseils de migration avant de retirer une surface dépréciée. Maintenez synchronisés l’implémentation, les métadonnées de compilation, les tests, la documentation et les notes de version. Ne laissez pas un nouveau fichier source accessible depuis un système de compilation mais absent d’un autre. ## Réussir une compilation propre et les tests avant d’approuver une modification Examinez la correction, les tests, les performances, la compatibilité, les frontières contractuelles, le style et la documentation comme des critères distincts. Exigez des résultats de mesure de performance pour les modifications sensibles aux performances. Exigez une couverture par des tests de charge pour les nouveaux comportements concurrents ou configurables. Exécutez la cible complète de compilation propre et de tests après la réussite des contrôles ciblés. Exécutez la compilation plus stricte de vérification des statuts, qui détecte les résultats d’erreur ignorés. Utilisez le mode de nettoyage automatique afin que des indicateurs de compilation modifiés ne puissent pas réutiliser des objets périmés. Surveillez les longues exécutions de tests au moyen de la sortie de progression lisible par machine du système de compilation. Suivez la phase, le travail achevé, le travail total, les échecs, le pourcentage et des détails bornés sur les échecs. Distinguez les échecs d’assertion des plantages, des signaux, des expirations de délai et des erreurs d’infrastructure. Conservez les paramètres de mesure de performance et les configurations de test avec les preuves communiquées. Compilez les outils de mesure de performance en mode production pour effectuer les mesures. Passez à une compilation de débogage lors du diagnostic d’un plantage, puis effectuez une compilation propre avant de mesurer à nouveau. Exécutez les contrôles de formatage, de source, de compilation, de test, d’assainissement et de plateforme exigés par la surface concernée. Réexécutez les critères directement affectés après les corrections issues de la révision. Ne réduisez pas la portée d’une recherche de cohérence à l’échelle du dépôt simplement parce que certaines correspondances semblent improbables. N’approuvez que lorsque le code, les contrats, les tests, les métadonnées de compilation, la documentation et les preuves mesurées concordent.