La difficulté de la recherche de code

La difficulté de la recherche de code

• La fonction de recherche actuelle de Val Town repose sur ILIKE de Postgres et ne prend donc en charge qu’une simple recherche par sous-chaîne partielle : si le terme recherché apparaît dans le code, il est inclus dans les résultats
  • Il n’y a pratiquement pas de classement des résultats, et les recherches contenant plusieurs mots sont mal prises en charge
  • Une meilleure fonction de recherche est l’une des fonctionnalités les plus demandées

Différence entre recherche en langage naturel et recherche de code

• Les solutions de recherche générales visent le langage naturel comme l’anglais, et ne conviennent donc pas bien à la recherche de code
  • Des algorithmes comme la suppression des stop words, le stemming ou la lemmatisation causent au contraire des problèmes pour le code
  • Par exemple, the n’est pas un stop word en TypeScript : cela peut être un nom de variable valide que l’on souhaite rechercher
  • Les frontières entre mots sont différentes, et appliquer du stemming à des noms de fonctions n’a pas beaucoup de sens

Full Text Search de Postgres

• L’extension Full Text Search de Postgres fonctionne bien jusqu’à une certaine échelle, mais se heurte à des problèmes de performance à grande échelle
  • Pour une petite équipe, il est important de garder l’infrastructure aussi simple que possible, d’où la volonté de tout résoudre avec Postgres, mais on est actuellement en train de pousser les limites d’un cluster Postgres à nœud unique
  • Il est difficile de trouver des cas d’usage de recherche de code avec FTS

Recherche trigramme avec pg_trgrm

• La recherche trigramme a déjà connu des succès dans la recherche de code
  • Google Code Search, le nouveau système de recherche de GitHub, Sourcegraph, etc.
• En utilisant l’extension pg_trgrm de Postgres, il est possible de créer un index GIN sur la colonne de texte de recherche pour prendre en charge la recherche trigramme
  • C’est une bonne solution pour la recherche par expressions régulières, mais il est difficile de produire un classement pertinent pour des requêtes libres

Les différentes options pour la recherche de code

• Il existe divers moteurs de recherche comme Meilisearch, Typesense, Zoekt, ParadeDB ou Sonic, mais la plupart ne sont pas spécifiquement conçus pour la recherche de code
• Les recherches de code de GitHub ou Sourcegraph sont excellentes, mais ce sont le résultat d’équipes dédiées et d’investissements importants en temps
• Elasticsearch est très personnalisable, mais sa gestion représente une charge importante pour une petite équipe
• Meilisearch est une alternative à ES écrite en Rust, mais semble davantage centrée sur la latence
• ParadeDB se présente comme « simplement Postgres » et promet des fonctionnalités proches d’ES, mais n’est pas encore utilisable

L’avis de GN⁺

• Comme c’est le cas actuellement chez Val Town, implémenter la recherche de code au départ uniquement avec les fonctionnalités de base de Postgres semble être un choix judicieux pour réduire la charge de gestion de l’infrastructure. Mais à mesure que le service grandit, l’adoption d’un moteur de recherche spécialisé paraît inévitable
• À grande échelle, il faudra sans doute adopter au moins Elasticsearch, mais même dans ce cas, utiliser un service cloud managé pourrait être un bon moyen de réduire la charge opérationnelle
• Il est regrettable qu’il n’existe pas beaucoup d’open source spécialisés dans la recherche de code. Comme son importance ne cesse de croître, on peut espérer voir à l’avenir davantage de projets open source spécialisés, à l’image de Sourcegraph, devenir plus actifs
• Au-delà de la simple recherche de chaînes, il semble nécessaire de mener des recherches sur des algorithmes de classement tenant compte des caractéristiques structurelles du code, par exemple en attribuant des poids différents aux noms de variables, aux noms de fonctions ou aux commentaires
• À long terme, l’évolution devrait aller vers le Semantic Code Search basé sur les Large Language Models. Si une recherche sémantique capable de retrouver du code implémentant la même logique malgré des différences de nommage ou de format devient possible, cela pourrait fortement améliorer la productivité des développeurs

[GN⁺]

Avis Hacker News

• Sourcegraph traite la recherche de code à grande échelle, mais au démarrage, la recherche en temps réel sans index fonctionne étonnamment bien pendant assez longtemps. En effet, il suffit de trouver les N premières correspondances. Les personnes qui construisent ce genre de choses sont les bienvenues pour en discuter.

• Une bonne plateforme de recherche de code rend la vie bien plus facile. En quittant Google, c’est probablement la fonction de recherche de code interne qui me manquerait le plus. Elle est tellement bien intégrée à tout le reste que c’est difficile à imaginer. Chaque fois que j’utilise la recherche GitHub, je l’apprécie d’autant plus. Elle n’est pas mauvaise, mais construire une plateforme de recherche de code généraliste est intrinsèquement bien plus difficile.

• On ne l’enseigne pas explicitement aux nouveaux développeurs, mais voici la progression des connaissances autour des techniques de base de recherche de code, une compétence absolument cruciale à acquérir tôt :

  • apprendre à utiliser Ctrl+F
  • passer à ripgrep
  • facultatif, mais il est utile d’apprendre l’un des éditeurs en ligne de commande vraiment puissants
  • passer de ripgrep à grep et apprendre quelques options
  • réaliser qu’il y a des limites à ce qu’on peut faire avec ripgrep, puis passer à un véritable outil dédié de recherche de code indexée

• Les créateurs d’IDE et d’outils de développement avaient compris depuis longtemps que, pour bien faire de la recherche de code, il fallait ouvrir la plateforme du compilateur. Une bonne recherche de code sert de fondation au support du refactoring, à l’autocomplétion et à d’autres fonctions classiques des IDE.

• IBM a réussi cela avec Eclipse, mais depuis, il n’y a rien eu de vraiment comparable. Eclipse disposait d’un compilateur incrémental rapide pour Java, même en présence d’erreurs de syntaxe, et la représentation du code dans l’IDE était liée à ce compilateur.

• L’une des approches de recherche de code les plus intéressantes que j’ai vues récemment est septum, qui vise à récupérer au niveau du fichier une quantité appropriée de contexte environnant. Une autre est stack-graphs, qui cherche à résoudre de manière incrémentale les relations symboliques à l’échelle de toute la base de code.

• Je suis surpris que hound, que je considérais comme le leader des solutions open source, ne soit pas mentionné.

• Il est déjà arrivé que GitHub soit agaçant en « corrigeant » un comportement de tokenisation étrange. Ils améliorent la fonction de type find-usages des IDE, mais ce n’est toujours pas parfait, si bien qu’il m’arrive de vouloir une recherche textuelle sur foo.bar() ; or ce comportement de stemming gonfle les résultats en trouvant tous les endroits où foo et bar sont mentionnés.

• Je ne comprends pas leur allusion à Zoekt. Ce n’est pas plus une « nouvelle promesse d’infrastructure » que les autres options. Le serveur et l’indexeur sont un binaire unique, donc difficile de faire plus simple. Je ne vois pas pourquoi il faudrait en avoir plus peur qu’Elasticsearch.

• Oracle dispose de vues USER/ALL/DBA_SOURCE qui exposent tout le code PL/SQL chargé. Je me demande si EnterpriseDB implémente cela à l’intérieur de Postgres, ou si c’est disponible comme extension.

• La recherche GitHub serait excellente ? Dans la plupart des cas, elle me semble presque inutile, et j’ai l’impression que cloner + ripgrep est bien plus efficace. Le vrai problème semble être une UX terrible plus que la recherche elle-même.