Les erreurs commises par les ingénieurs logiciels dans les grandes bases de données établies

Par Sean Goedecke

Les erreurs commises par les ingénieurs logiciels dans les grandes bases de données établies, par Sean Goedecke

Travailler dans de grandes bases de code établies est l'une des choses les plus difficiles à apprendre en tant qu'ingénieur logiciel. Vous ne pouvez pas vous y exercer à l'avance (non, l'open source ne vous donne pas la même expérience). Les projets personnels ne peuvent jamais vous apprendre à le faire, parce qu'ils sont nécessairement petits et à partir de rien. Pour mémoire, lorsque je parle de "grandes bases de code établies », je veux dire :

• Plus d'un million de lignes de code ( environ 5M, disons)
• Entre 100 et 1000 ingénieurs travaillant sur la même base de code
• La première version de travail de la base de code date d'au moins dix ans

J'ai maintenant passé une décennie à travailler dans ces bases de code. Voici ce que j'aurais aimé savoir dès le départ.

L'erreur cardinale est l'incohérence

Il y a une erreur que je vois plus souvent que toute autre, et elle est absolument mortelle : ignorer le reste de la base de code et implémenter votre fonctionnalité de la manière la plus sensée. En d'autres termes, limiter vos points de contact avec la base de code existante afin de garder votre beau code propre non contaminé par des déchets hérités. Pour les ingénieurs qui ont principalement travaillé sur de petites bases de code, il est très difficile de résister. Mais vous devez y résister ! En fait, vous devez vous enfoncer aussi profondément que possible dans l'ancienne base de code, afin de maintenir la cohérence.

Pourquoi la cohérence est-elle si importante dans les grandes bases de code ? Parce qu'elle vous protège des mauvaises surprises, qu'elle ralentit la progression de la base de code vers le désordre et qu'elle vous permet de tirer parti des améliorations futures.

Supposons que vous construisiez un point d'accès à l'API pour un type d'utilisateur particulier. Vous pourriez mettre une logique de « retour 403 si l'utilisateur actuel n'est pas de ce type » dans votre point de terminaison. Mais vous devriez d'abord aller voir ce que les autres points de terminaison de l'API dans la base de code font pour l'authentification. S'ils utilisent un ensemble spécifique d'aides, vous devriez également utiliser cette aide (même si elle est laide, difficile à intégrer, ou semble exagérée pour votre cas d'utilisation). Vous devez résister à l'envie de rendre votre petit coin de code plus agréable que le reste.

La principale raison de le faire est que les grandes bases de code contiennent beaucoup de mines antipersonnel. Par exemple, vous ne savez peut-être pas que la base de code a un concept de « bots », qui sont comme des utilisateurs mais pas tout à fait, et qui nécessitent un traitement spécial pour l'authentification. Vous ne savez peut-être pas que l'outil de support interne de la base de code permet à un ingénieur de s'authentifier parfois au nom d'un utilisateur, ce qui nécessite un traitement spécial pour l'authentification. Il y a certainement une centaine d'autres choses que vous ne savez peut-être pas. La fonctionnalité existante représente un chemin sûr à travers le champ de mines. Si vous effectuez votre authentification comme d'autres points d'extrémité d'API qui existent depuis longtemps, vous pouvez suivre ce chemin sans avoir à connaître toutes les choses surprenantes que fait la base de code.

En outre, le manque de cohérence est la principale cause de mortalité à long terme des grandes bases de code, car il rend impossible toute amélioration générale. Pour en rester à notre exemple d'authentification, si vous souhaitez introduire un nouveau type d'utilisateur, une base de code cohérente vous permet de mettre à jour l'ensemble existant d'aides à l'authentification pour l'adapter à ce nouveau type d'utilisateur. Dans une base de code incohérente, où certains points de terminaison de l'API font les choses différemment, vous devrez mettre à jour et tester chacune de ces implémentations. En pratique, cela signifie que le changement général n'a pas lieu, ou que les 5 % de points de terminaison les plus difficiles à mettre à jour sont tout simplement laissés en dehors du champ d'application - ce qui, à son tour, diminue encore la cohérence, car vous avez maintenant un type d'utilisateur qui fonctionne pour la plupart des points de terminaison de l'API, mais pas pour tous.

Par conséquent, lorsque vous vous asseyez pour mettre en œuvre quoi que ce soit dans une grande base de code, vous devez toujours commencer par rechercher les antériorités et les suivre si possible.

Y a-t-il autre chose d'important ?

La cohérence est la chose la plus importante. Permettez-moi toutefois de passer rapidement en revue d'autres préoccupations :

Vous devez vous faire une idée précise de la manière dont le service est utilisé dans la pratique (c'est-à-dire par les utilisateurs). Quels sont les points d'accès les plus souvent utilisés ? Quels sont les points d'extrémité les plus cruciaux (c'est-à-dire ceux qui sont utilisés par des clients payants et qui ne peuvent pas se dégrader de manière gracieuse) ? Quelles garanties de latence le service doit-il respecter, et quel code doit être exécuté dans les chemins chauds ? Une erreur fréquente dans les grandes bases de code est d'apporter une « petite modification » qui se trouve inopinément dans le chemin chaud d'un flux crucial, et qui cause donc un gros problème.

Vous ne pouvez pas compter sur votre capacité à tester le code en cours de développement comme vous le feriez pour un petit projet. Tout grand projet accumule des états au fil du temps (par exemple, combien de types d'utilisateurs pensez-vous que GMail supporte ?) À un certain point, vous ne pouvez pas tester toutes les combinaisons d'états, même avec l'automatisation. Au lieu de cela, vous devez tester les chemins cruciaux, coder de manière défensive, et compter sur des déploiements lents et un suivi pour détecter les problèmes.

Soyez très, très réticent à introduire de nouvelles dépendances. Dans les grandes bases de code, le code est souvent éternel. Les dépendances introduisent un coût permanent en vulnérabilités de sécurité et en mises à jour de paquets qui dépassera presque certainement votre durée de service dans l'entreprise. Si vous devez le faire, assurez-vous de choisir des dépendances qui sont largement utilisées et fiables, ou qui sont faciles à récupérer en cas de besoin.

Pour les mêmes raisons, si vous avez l'occasion de supprimer du code, saisissez-la à deux mains. C'est l'un des travaux les plus risqués dans les grandes bases de code, alors ne faites pas les choses à moitié : instrumentez d'abord le code pour identifier les appelants en production et réduisez-les à zéro, de sorte que vous puissiez être absolument certain qu'il est sûr de le supprimer. Mais cela vaut tout de même la peine d'être fait. Il y a peu de choses dans une grande base de code qui valent plus la peine que de supprimer du code en toute sécurité.

Travaillez dans de petits PRs et mettez en avant les changements qui affectent le code d'autres équipes. Ce point est important dans les petits projets, mais il est crucial dans les grands. En effet, vous comptez souvent sur les experts des autres équipes pour anticiper des choses que vous n'avez pas vues (les grands projets étant trop complexes pour que vous puissiez tout anticiper vous-même). Si les changements apportés aux zones à risque sont limités et faciles à lire, ces experts auront beaucoup plus de chances de remarquer les problèmes et de vous éviter un incident.

Pourquoi s'en préoccuper ?

Enfin, je voudrais prendre une seconde pour défendre ces bases de code en général. Voici un point de vue que j'ai souvent entendu :
Je pense que c'est une erreur totale. La raison principale est que, en règle générale, les grandes bases de code établies produisent 90 % de la valeur. Dans toute grande entreprise technologique, la majorité des activités génératrices de revenus (c'est-à-dire le travail qui paie réellement votre salaire d'ingénieur) provient d'une grande base de code établie. Si vous travaillez dans une grande entreprise technologique et que vous pensez que ce n'est pas vrai, vous avez peut-être raison, mais je ne prendrai cette opinion au sérieux que si vous connaissez très bien la grande base de code établie qui, selon vous, n'apporte pas de valeur. J'ai vu de nombreux cas où un petit service élégant alimente une fonction essentielle d'un produit à forte valeur ajoutée, mais où tout le code de production réel (paramètres, gestion des utilisateurs, facturation, rapports d'entreprise, etc) vit toujours dans la grande base de code établie.

Vous devez donc savoir comment travailler dans le "désordre hérité" parce que c'est ce que votre entreprise fait réellement. Que vous soyez un bon ingénieur ou non, c'est votre travail.

L'autre raison est qu'il est impossible de scinder une grande base de code établie sans d'abord la comprendre. J'ai vu de grandes bases de code être scindées avec succès, mais je n'ai jamais vu cela fait par une équipe qui ne maîtrisait pas déjà l'envoi de fonctionnalités à l'intérieur de la grande base de code. Il est tout simplement impossible de revoir la conception d'un projet non trivial (c'est-à-dire un projet qui rapporte de l'argent) à partir des principes de base. Il y a trop de détails accidentels qui soutiennent des dizaines de millions de dollars de revenus.

Résumé

• Les grandes bases de code valent la peine qu'on y travaille parce qu'elles paient généralement votre salaire
• La cohérence est de loin la chose la plus importante
• Ne commencez jamais une fonctionnalité sans d'abord rechercher l'art antérieur dans la base de code
• Si vous ne suivez pas les modèles existants, vous avez intérêt à avoir une très bonne raison pour cela
• Comprenez l'empreinte de production de la base de code
• Ne vous attendez pas à pouvoir tester tous les cas - comptez plutôt sur la surveillance
• Supprimez du code dès que vous en avez l'occasion, mais soyez très prudent à ce sujet
• Faites en sorte qu'il soit aussi facile que possible pour les experts du domaine de repérer vos erreurs.

Source : Mistakes engineers make in large established codebases

Et vous ?

Pensez-vous que ces principes sont crédibles ou pertinents ?
Quel est votre avis sur le sujet ?

Voir aussi :

Comment je livre des projets informatiques dans de grandes entreprises technologiques, par Sean Goedecke

Développement de logiciels à long terme, par Bert Hubert

Le Manifeste anti-héritage : Écrire du code qui dure, par Mensur Durakovic

Le pouvoir surprenant de la documentation, par Vadim Kravcenko