La dificultad de la búsqueda de código

La dificultad de la búsqueda de código

• La función de búsqueda actual de Val Town se basa en ILIKE de Postgres, por lo que solo admite una búsqueda simple por subcadenas en la que los resultados incluyen el término si este aparece en el código
  • Casi no hay ranking en los resultados, y las búsquedas con varias palabras no están bien soportadas
  • Una mejor función de búsqueda es una de las características más solicitadas

Diferencias entre la búsqueda en lenguaje natural y la búsqueda de código

• Las soluciones de búsqueda comunes están pensadas para lenguaje natural como el inglés, por lo que no son adecuadas para buscar código
  • Algoritmos como eliminación de stop words, stemming y lemmatization más bien causan problemas en el código
  • Por ejemplo, the en TypeScript no es una stop word, sino que puede ser un nombre de variable válido que se quiere buscar
  • Los límites de palabra también son distintos, y aplicar stemming a nombres de funciones no tiene mucho sentido

Full Text Search de Postgres

• La extensión Full Text Search de Postgres funciona bien hasta cierta escala, pero al crecer aparecen problemas de rendimiento
  • En equipos pequeños es importante mantener la infraestructura lo más simple posible, así que se intenta resolver todo con Postgres, pero ahora están desafiando los límites de un clúster de Postgres de nodo único
  • Es difícil encontrar casos de uso de búsqueda de código con FTS

Búsqueda por trigramas con pg_trgrm

• La búsqueda por trigramas tiene casos exitosos en búsqueda de código
  • Google Code Search, el nuevo sistema de búsqueda de GitHub, Sourcegraph, etc.
• Usan la extensión pg_trgrm de Postgres para crear un índice GIN sobre la columna de texto de búsqueda y así dar soporte a la búsqueda por trigramas
  • Es una buena solución para búsquedas con expresiones regulares, pero es difícil construir un ranking adecuado para consultas libres

Varias opciones para la búsqueda de código

• Existen varios motores de búsqueda como Meilisearch, Typesense, Zoekt, ParadeDB y Sonic, pero la mayoría no está especializada en búsqueda de código
• La búsqueda de código de GitHub y Sourcegraph es excelente, pero es el resultado de equipos dedicados y una gran inversión de tiempo
• Elasticsearch permite mucha personalización, pero la carga de operación es alta para equipos pequeños
• Meilisearch es una alternativa a ES hecha en Rust, pero parece estar más enfocada en la latencia
• ParadeDB promete capacidades similares a ES diciendo que es "simplemente Postgres", pero todavía no puede usarse

Opinión de GN⁺

• Como en el caso de Val Town, al inicio parece una decisión sensata implementar la búsqueda de código solo con las funciones básicas de Postgres para reducir la carga de administrar infraestructura. Pero a medida que el servicio crece, parece inevitable adoptar un motor de búsqueda especializado
• Cuando la escala aumente, probablemente habrá que introducir algo como Elasticsearch, aunque incluso en ese caso usar un servicio administrado en la nube sería una forma de reducir la carga operativa
• Es una pena que no haya mucho open source especializado en búsqueda de código. A medida que la importancia de la búsqueda de código sigue creciendo, sería bueno que en adelante se activen más proyectos open source especializados, como Sourcegraph
• Parece necesario investigar algoritmos de ranking para búsqueda que reflejen las características estructurales del código más allá de la simple búsqueda por cadenas. Por ejemplo, distinguir entre nombres de variables, nombres de funciones y comentarios para asignarles pesos distintos
• A largo plazo, se espera una evolución hacia Semantic Code Search aprovechando Large Language Models. Si fuera posible una búsqueda semántica que encuentre código con la misma lógica aunque cambien el naming o el formato, eso ayudaría mucho a la productividad de los desarrolladores

[GN⁺]

Opinión de Hacker News

• Sourcegraph maneja búsquedas de código a gran escala, pero al principio sorprendentemente funciona bien durante bastante tiempo solo con búsqueda en tiempo real y sin índices. Esto se debe a que solo necesitas encontrar las primeras N coincidencias. Me interesa conversar con gente que construye este tipo de cosas.

• Una buena plataforma de búsqueda de código te hace la vida mucho más fácil. Si dejara Google, lo que más extrañaría sería su búsqueda interna de código. Está tan bien integrada con todo lo demás que ya no me la imagino sin eso. Cada vez que uso la búsqueda de Github lo agradezco más. No es mala, pero construir una plataforma de búsqueda de código generalista es inherentemente mucho más difícil.

• No se les enseña explícitamente a los nuevos desarrolladores, pero así progresa el conocimiento sobre las habilidades básicas de búsqueda de código, que son absolutamente cruciales y deberían desarrollarse desde temprano:

  • Aprender a usar Ctrl+F
  • Cambiar a ripgrep
  • Opcional, pero muy recomendable: aprender uno de los editores potentes de línea de comandos
  • Pasar de ripgrep a grep y aprender algunas banderas
  • Darse cuenta de que hay límites para lo que se puede hacer con ripgrep y cambiar a una herramienta de búsqueda de código dedicada y realmente indexada

• Quienes crean IDEs y herramientas de desarrollo entendieron hace mucho tiempo que, para hacer bien la búsqueda de código, hay que abrir la plataforma del compilador. Una buena búsqueda de código es la base del soporte para refactorización, autocompletado y otras funciones comunes de los IDE.

• IBM logró esto con Eclipse, pero desde entonces no ha habido nada realmente comparable. Eclipse tenía un compilador incremental rápido para Java incluso cuando había errores de sintaxis, y la representación del código en el IDE estaba conectada a ese compilador.

• Uno de los enfoques de búsqueda de código más interesantes que he visto recientemente es septum, que busca traer la cantidad adecuada de contexto circundante a nivel de archivo. Otro es stack-graphs, que intenta resolver de forma incremental las relaciones simbólicas en toda la base de código.

• Me sorprende que no se mencione hound, que yo consideraba el líder entre las soluciones open source.

• A veces Github ha sido molesto al “arreglar” comportamientos extraños de tokenización. Están mejorando las funciones de tipo find-usages al estilo IDE, pero todavía no es perfecto, así que a veces quiero hacer una búsqueda de texto de "foo.bar()" y este comportamiento de stemming infla los resultados encontrando todos los lugares donde se menciona foo y bar.

• No entiendo su gesto de desdén hacia Zoekt. No es una “nueva promesa de infraestructura” más que otras opciones. El servidor y el indexador son un solo binario, así que difícilmente podría ser más simple. No veo por qué habría que tenerle más miedo que a Elasticsearch.

• Oracle tiene vistas USER/ALL/DBA_SOURCE donde se presenta todo el código PL/SQL cargado. Me pregunto si EnterpriseDB implementa esto dentro de Postgres o si se puede usar como extensión.

• ¿La búsqueda de Github es excelente? En la mayoría de los casos me parece casi inútil, y creo que clonar + ripgrep es mucho más eficiente. Parece que el problema no es tanto la búsqueda en sí, sino que la UX es terrible.