Die Schwierigkeit der Codesuche

Die Schwierigkeit der Codesuche

• Die aktuelle Suchfunktion von Val Town basiert auf der Postgres-Funktion ILIKE und unterstützt daher nur eine einfache Teilstring-Suche, bei der ein Treffer in den Suchergebnissen erscheint, wenn der Suchbegriff im Code vorkommt.
  • Es gibt kaum Ranking der Suchergebnisse, und Suchanfragen mit mehreren Wörtern werden nicht gut unterstützt.
  • Eine bessere Suchfunktion ist eines der am häufigsten gewünschten Features.

Unterschied zwischen natürlicher Sprachsuche und Codesuche

• Allgemeine Suchlösungen sind auf natürliche Sprache wie Englisch ausgelegt und daher für Codesuche nicht gut geeignet.
  • Algorithmen wie das Entfernen von Stop Words, Stemming und Lemmatisierung verursachen bei Code eher Probleme.
  • Zum Beispiel ist the in TypeScript kein Stop-Word, sondern kann ein gültiger Variablenname sein, nach dem man suchen möchte.
  • Auch Wortgrenzen sind anders, und es ergibt wenig Sinn, Funktionsnamen zu stemmen.

Full Text Search in Postgres

• Die Full-Text-Search-Erweiterung von Postgres funktioniert bis zu einer gewissen Größenordnung gut, stößt aber im großen Maßstab auf Performance-Probleme.
  • Für kleine Teams ist es wichtig, die Infrastruktur möglichst einfach zu halten, deshalb versucht man, alles mit Postgres zu lösen; aktuell stößt man jedoch an die Grenzen eines Single-Node-Postgres-Clusters.
  • Es ist schwer, Praxisbeispiele für Codesuche mit FTS zu finden.

Trigram-Suche mit pg_trgrm

• Es gibt erfolgreiche Beispiele für Trigram-Suche bei der Codesuche.
  • Google Code Search, das neue Suchsystem von GitHub, Sourcegraph usw.
• Mit der Postgres-Erweiterung pg_trgrm lässt sich durch einen GIN-Index auf der Textspalte der Suche Trigram-Suche unterstützen.
  • Für Regex-Suche ist das eine gute Lösung, aber für freie Suchanfragen ist es schwer, ein geeignetes Ranking zu erstellen.

Verschiedene Optionen für Codesuche

• Es gibt verschiedene Suchmaschinen wie Meilisearch, Typesense, Zoekt, ParadeDB und Sonic, aber die meisten sind nicht speziell auf Codesuche ausgerichtet.
• Die Codesuche von GitHub, Sourcegraph usw. ist hervorragend, aber das ist das Ergebnis dedizierter Teams und großer Zeitinvestitionen.
• Elasticsearch lässt sich stark anpassen, bringt für kleine Teams aber einen hohen Betriebsaufwand mit sich.
• Meilisearch ist eine in Rust geschriebene ES-Alternative, scheint aber stärker auf Latenz fokussiert zu sein.
• ParadeDB wirbt mit „einfach Postgres“ und verspricht ES-ähnliche Funktionen, ist aber noch nicht nutzbar.

Meinung von GN⁺

• Wie beim aktuellen Einsatz bei Val Town scheint es anfangs eine kluge Entscheidung zu sein, Codesuche nur mit den Grundfunktionen von Postgres umzusetzen, um den Aufwand für den Infrastruktur-Betrieb zu reduzieren. Mit wachsender Größe des Dienstes scheint die Einführung einer spezialisierten Suchmaschine jedoch unvermeidlich.
• Mit zunehmender Skalierung dürfte mindestens die Einführung von Elasticsearch nötig werden; auch dann wäre ein gemanagter Cloud-Service eine Möglichkeit, den Betriebsaufwand zu verringern.
• Schade ist, dass es nicht viele Open-Source-Projekte gibt, die auf Codesuche spezialisiert sind. Da die Bedeutung von Codesuche weiter zunimmt, wäre es wünschenswert, wenn Open-Source-Projekte mit Fokus auf Codesuche wie Sourcegraph künftig aktiver würden.
• Über einfache String-Suche hinaus scheint Forschung zu Ranking-Algorithmen nötig zu sein, die die strukturellen Eigenschaften von Code berücksichtigen. Zum Beispiel könnten Variablennamen, Funktionsnamen und Kommentare unterschiedlich gewichtet werden.
• Langfristig ist zu erwarten, dass sich die Entwicklung in Richtung Semantic Code Search mit Large Language Models bewegt. Wenn semantische Suche auch Code mit gleicher Logik, aber anderem Naming oder anderem Formatting finden kann, wäre das eine große Hilfe für die Produktivität von Entwicklern.

[GN⁺]

Hacker-News-Kommentare

• Sourcegraph befasst sich mit Code-Suche in großem Maßstab, aber am Anfang funktioniert überraschend lange auch reine Echtzeitsuche ohne Index gut. Denn man muss nur die ersten N Treffer finden. Gespräche mit Leuten, die so etwas bauen, sind willkommen.

• Eine gute Code-Suchplattform macht das Leben deutlich einfacher. Wenn man Google verlässt, wird man die interne Code-Suche am meisten vermissen. Sie ist so gut in alles andere integriert, dass man sich kaum etwas anderes vorstellen kann. Jedes Mal, wenn ich die Github-Suche benutze, bin ich dafür noch dankbarer. Sie ist nicht schlecht, aber eine allgemeine Code-Suchplattform zu bauen, ist grundsätzlich viel schwieriger.

• Man bringt es neuen Entwicklerinnen und Entwicklern nicht ausdrücklich bei, aber der Wissenspfad zu grundlegenden Code-Suchfertigkeiten, die man früh unbedingt aufbauen sollte:

  • lernen, Ctrl+F zu benutzen
  • zu ripgrep wechseln
  • optional, aber empfehlenswert: einen der leistungsfähigen Kommandozeilen-Editoren lernen
  • von ripgrep zu grep wechseln und ein paar Flags lernen
  • erkennen, dass es Grenzen dessen gibt, was man mit ripgrep tun kann, und zu einem echten spezialisierten Code-Suchwerkzeug mit Indexierung wechseln

• Hersteller von IDEs und Entwicklerwerkzeugen hatten schon lange die Einsicht, dass man Compiler-Plattformen öffnen muss, um Code-Suche richtig zu machen. Gute Code-Suche ist die Grundlage für Refactoring-Unterstützung, Autovervollständigung und andere typische IDE-Funktionen.

• IBM hat das mit Eclipse geschafft, aber seitdem gab es nichts wirklich Vergleichbares. Eclipse hatte einen schnellen inkrementellen Compiler für Java, selbst bei Syntaxfehlern, und die Code-Repräsentation der IDE war mit diesem Compiler verbunden.

• Einer der interessantesten Ansätze zur Code-Suche, die ich kürzlich gesehen habe, ist septum, das darauf abzielt, pro Datei die passende Menge an umgebendem Kontext einzubeziehen. Ein anderer ist stack-graphs, das versucht, symbolische Beziehungen über die gesamte Codebasis hinweg inkrementell aufzulösen.

• Ich bin überrascht, dass hound, das ich für den führenden Open-Source-Ansatz hielt, nicht erwähnt wird.

• Es war nervig, als Github das seltsame Tokenisierungsverhalten „repariert“ hat. Sie verbessern zwar IDE-artige Find-Usages-Funktionen, aber es ist noch immer nicht perfekt, sodass man manchmal eine Textsuche nach "foo.bar()" machen will und dieses Stemming-Verhalten dann alle Stellen findet, an denen foo und bar erwähnt werden, wodurch die Ergebnisse aufgebläht werden.

• Ich verstehe ihre Anspielung auf Zoekt nicht. Es ist nicht mehr ein „Versprechen neuer Infrastruktur“ als andere Optionen. Server und Indexer sind ein einziges Binary, einfacher geht es kaum. Ich sehe keinen Grund, davor mehr Angst zu haben als vor Elasticsearch.

• Oracle hat USER/ALL/DBA_SOURCE-Views, in denen aller geladene PL/SQL-Code bereitgestellt wird. Ich frage mich, ob EnterpriseDB das innerhalb von Postgres implementiert oder ob es als Erweiterung nutzbar ist.

• Github-Suche soll großartig sein? In den meisten Fällen wirkt sie auf mich fast nutzlos, und ich denke, Klonen + ripgrep ist viel effizienter. Das Problem scheint eher eine schreckliche UX zu sein als die eigentliche Suche.