Les erreurs que commettent les ingénieurs dans les grandes bases de code existantes

• Travailler dans une grande base de code est l’une des choses les plus difficiles pour un ingénieur logiciel. Il est difficile d’acquérir cette expérience via des projets personnels ou open source
  • Des millions de lignes de code, 100 à 1 000 ingénieurs travaillant en parallèle, une base de code vieille d’au moins 10 ans
  • Cela exige une capacité spécifique à comprendre un état accumulé de complexité et de temps

La plus grande erreur est le manque de cohérence

• L’erreur la plus fréquente consiste à ignorer la base de code existante et à implémenter sa propre fonctionnalité. Cela empêche de maintenir la cohérence et aggrave la confusion dans la base de code
  • En général, on implémente de manière indépendante pour minimiser les interactions avec la base de code existante afin de garder son code propre, et pour éviter le code « legacy » existant
• La cohérence réduit la complexité de la base de code et facilite les améliorations futures
• Par exemple, lors de l’implémentation d’un endpoint API, il est important de suivre le mécanisme d’authentification existant. Cela permet de traverser en sécurité le champ de mines qu’est la base de code
• Sans motifs cohérents, il faut mettre à jour tout le code manuellement, ce qui devient de plus en plus difficile

Autres éléments importants

• Comprendre comment le service est réellement utilisé
  • Identifier les principaux endpoints API les plus utilisés et les chemins critiques (hot paths)
  • Traiter avec prudence les modifications sur le code le plus fréquemment utilisé
• L’importance des tests et du monitoring
  • Dans les projets à grande échelle, il est impossible de tester tous les états, donc on ne teste que les chemins principaux
  • Écrire du code de manière défensive et s’appuyer sur des déploiements progressifs ainsi que sur le monitoring
• Éviter d’ajouter des dépendances
  • Les dépendances entraînent des problèmes de sécurité et une hausse des coûts de maintenance
  • Si elles sont vraiment nécessaires, choisir des dépendances fiables
• Supprimer du code avec prudence, mais activement
  • Analyser les données de production pour retirer en toute sécurité les appels, puis supprimer le code
  • Supprimer le code inutile facilite la maintenance de la base de code
  • C’est l’un des travaux les plus précieux dans une grande base de code
• Travailler avec de petites PR et traiter d’abord les changements qui affectent le code d’autres équipes
  • Cela permet aux experts du domaine de repérer les problèmes et d’éviter les incidents

Pourquoi les grandes bases de code sont-elles importantes ?

• La valeur des grandes bases de code
  • La plupart des entreprises technologiques génèrent leurs revenus à partir de grandes bases de code
  • Travailler sur une « base de code legacy » correspond au vrai travail de l’entreprise
• Comprendre avant de découpler le code
  • Pour découpler une grande base de code, il faut d’abord comprendre suffisamment son fonctionnement global
  • Une refonte de grande ampleur est impossible sans compréhension

Résumé

• Les grandes bases de code ont une valeur métier importante
• Le plus important est de maintenir la cohérence
• Avant d’implémenter une nouvelle fonctionnalité, étudier le code existant et suivre ses motifs
• Si l’on ne suit pas les motifs existants, il faut avoir une très bonne raison
• Comprendre comment le code est utilisé en production
• Comme il est impossible de tout tester, ne pas trop dépendre des tests, mais s’appuyer sur le monitoring et les déploiements progressifs
• Saisir activement les occasions de supprimer du code, tout en procédant avec prudence
• Travailler par petites PR afin que les experts du domaine puissent relire

[kallare]

La cohérence est importante, mais cela ne veut pas dire qu’il faille repousser l’amélioration du code ou continuer à répéter de mauvais schémas existants… c’est une question difficile. À force de préserver la cohérence, on peut finir par accumuler la même dette technique.

[regentag]

Plus que tout, il faut respecter les conventions de code.
Surtout les règles d'indentation...

[roxie]

Vous êtes dans un domaine où il est impossible d’appliquer des outils capables de détecter ça automatiquement… ? T_T

[regentag]

Oui.... :(

[roxie]

Je vais pleurer aussi.. snif snif snif snif snif snif snif snif

[bbulbum]

L’ampleur du projet != sa maturité
Je suis d’accord sur le fait que la cohérence est très importante, mais je pense qu’il faut éviter de s’en servir comme prétexte pour reléguer l’amélioration de la base de code au second plan.
Un projet est toujours vivant et en croissance, donc si l’on ne parvient pas à l’améliorer au bon moment, il faudra ensuite beaucoup plus de temps et d’efforts pour rattraper le retard.

[beoks]

Je suis également d’accord. Je travaille moi aussi sur un projet vieux de plus de 20 ans, et il comporte vraiment beaucoup de parties très immatures au regard des standards actuels.
La cohérence a l’avantage d’améliorer la compréhension du code, mais comme les limites de la structure entraînent aussi celles des fonctionnalités et freinent l’évolution du service, je pense qu’une refonte audacieuse est parfois nécessaire.

[GN⁺]

Avis Hacker News

• Quand une base de code existante manque de cohérence, il est important d’introduire de nouvelles approches, de les documenter et de recueillir des retours. Il faut s’efforcer de conserver une cohérence avec le code existant.

  • Même si le code existant est mauvais, il est important de travailler en restant cohérent avec le code alentour.
  • Si les membres de l’équipe ne sont pas coopératifs, il peut être utile de souligner les problèmes du code existant et d’expliquer que la nouvelle approche est expérimentale.

• Il faut utiliser les outils de la base de code existante, même s’il peut être plus agréable de construire une nouvelle base de code.

  • Plus le couplage d’une base de code est fort, plus les changements peuvent devenir difficiles, et un manque de couverture de tests peut poser problème.

• Pour découper une grande base de code, il faut d’abord la comprendre, et si une équipe inexpérimentée essaie de le faire, l’échec est probable.

  • Un nouveau groupe peut faire échouer le projet s’il ne comprend pas le système existant.

• Dans les grandes bases de code, on voit souvent des tentatives d’amélioration faites au hasard.

  • Il est important d’identifier ce qu’il faut améliorer et de juger ce qui aura réellement un impact positif.
  • Il est important de savoir ce qu’il faut améliorer et de savoir quand s’arrêter.

• Il est difficile de faire évoluer une base de code dans la durée.

  • Une cohérence absolue ne permet pas l’expérimentation, et sans expérimentation, il n’y a pas de réussite.

• Quand la base de code est grande et que les effectifs manquent, il faut beaucoup de temps pour qu’une nouvelle personne devienne productive.

  • Travailler dans un tel environnement peut ne pas être bon pour la carrière.

• Garder une base de code propre consiste à ne faire que le minimum nécessaire pour livrer des fonctionnalités.

  • Cela peut être un choix tactique d’ingénieurs habiles politiquement, qui visent avant tout la mise en production des fonctionnalités.

• La cohérence n’est pas ce qu’il y a de plus important, et il vaut mieux améliorer certaines parties de la base de code.

  • L’« antipattern des couches de lave » peut produire un meilleur système que des tentatives de préserver la cohérence.

• L’affirmation « le manque de cohérence est une erreur fatale » est correcte à 100 %.

  • Cela suit la philosophie du « À Rome, fais comme les Romains ».

• Trois maximes pour un ingénieur :

  • clarté, cohérence, concision
  • placer la douleur au bon endroit
  • lutter contre l’entropie