A dificuldade da busca de código

A dificuldade da busca de código

• O recurso de busca atual da Val Town é baseado no ILIKE do Postgres, então só oferece uma busca simples por substring que inclui nos resultados apenas quando o termo pesquisado está presente no código
  • Quase não há ranking dos resultados, e buscas com várias palavras não são bem suportadas
  • Um recurso de busca melhor é um dos pedidos mais frequentes

Diferença entre busca em linguagem natural e busca de código

• As soluções de busca em geral são voltadas para linguagem natural, como inglês, por isso não são adequadas para busca de código
  • Algoritmos como remoção de stop words, stemming e lemmatization acabam causando problemas no código
  • Por exemplo, the não é uma stop word em TypeScript, mas pode ser um nome de variável válido que alguém quer buscar
  • Os limites de palavras também são diferentes, e fazer stemming em nomes de funções não tem muito sentido

Full Text Search do Postgres

• A extensão Full Text Search do Postgres funciona bem até certo porte, mas em grande escala esbarra em problemas de desempenho
  • Em equipes pequenas, é importante manter a infraestrutura o mais simples possível, então tenta-se resolver tudo com Postgres, mas no momento isso já está desafiando os limites de um cluster Postgres de nó único
  • É difícil encontrar casos de uso de busca de código com FTS

Busca por trigramas com pg_trgrm

• A busca por trigramas tem casos de sucesso em busca de código
  • Google Code Search, o novo sistema de busca do GitHub, Sourcegraph etc.
• Usando a extensão pg_trgrm do Postgres, é possível criar um índice GIN na coluna de texto de busca para oferecer suporte à busca por trigramas
  • É uma boa solução para busca por regex, mas é difícil criar um ranking adequado para consultas livres

Várias opções para busca de código

• Existem vários mecanismos de busca, como Meilisearch, Typesense, Zoekt, ParadeDB e Sonic, mas a maioria não é especializada em busca de código
• As buscas de código do GitHub e do Sourcegraph são excelentes, mas são fruto de equipes dedicadas e de muito investimento de tempo
• O Elasticsearch permite muita customização, mas impõe uma carga operacional grande para equipes pequenas
• O Meilisearch é uma alternativa ao ES feita em Rust, mas parece estar mais focada em latência
• O ParadeDB se apresenta como “apenas Postgres” e promete recursos parecidos com os do ES, mas ainda não pode ser usado

Opinião do GN⁺

• Como no caso do uso atual da Val Town, implementar a busca de código no início usando apenas os recursos básicos do Postgres parece uma escolha sensata para reduzir a carga de gestão da infraestrutura. Mas, à medida que o serviço cresce, a adoção de um mecanismo de busca especializado parece inevitável
• Quando a escala aumentar, algo como Elasticsearch provavelmente será necessário, mas mesmo nesse caso usar um serviço gerenciado em nuvem pode ser uma forma de reduzir a carga operacional
• É uma pena que não existam muitos projetos open source especializados em busca de código. Como a importância da busca de código só tende a crescer, seria ótimo ver projetos open source mais ativos e focados nisso, como o Sourcegraph
• Parece necessário pesquisar algoritmos de ranking para busca que vão além da simples busca por string e reflitam as características estruturais do código. Por exemplo, diferenciando nomes de variáveis, nomes de funções e comentários para atribuir pesos distintos
• No longo prazo, a tendência parece ser evoluir para busca semântica de código com uso de Large Language Models. Se for possível encontrar código com a mesma lógica mesmo quando nomes e formatação forem diferentes, isso pode ajudar muito na produtividade de desenvolvimento

[GN⁺]

Comentários no Hacker News

• O Sourcegraph lida com busca de código em larga escala, mas no começo, surpreendentemente, a busca em tempo real sem índice já funciona bem por bastante tempo. Isso porque basta encontrar as primeiras N correspondências. Conversar com pessoas que constroem esse tipo de coisa é sempre bem-vindo.

• Uma boa plataforma de busca de código torna a vida muito mais fácil. Ao sair do Google, a funcionalidade interna de busca de código seria a coisa de que eu mais sentiria falta. É tão bem integrada com todo o resto que fica difícil imaginar ficar sem. Cada vez que uso a busca do GitHub, fico ainda mais grato. Não é ruim, mas construir uma plataforma de busca de código generalista é inerentemente muito mais difícil.

• Não é algo ensinado explicitamente a novos desenvolvedores, mas esta é a progressão de conhecimento sobre técnicas básicas de busca de código, uma habilidade absolutamente crucial que precisa ser desenvolvida cedo:

  • aprender a usar Ctrl+F
  • migrar para ripgrep
  • opcional, mas vale muito a pena aprender um dos editores poderosos de linha de comando
  • passar de ripgrep para grep e aprender algumas flags
  • perceber que há limites para o que dá para fazer com ripgrep e migrar para uma ferramenta dedicada de busca de código com indexação de verdade

• Criadores de IDEs e ferramentas de desenvolvimento já tinham, há muito tempo, a percepção de que, para fazer busca de código direito, era preciso abrir a plataforma do compilador. Uma boa busca de código é a base para suporte a refatoração, autocompletar e outros recursos comuns de IDE.

• A IBM conseguiu isso com o Eclipse, mas desde então não houve nada à altura. O Eclipse tinha um compilador incremental rápido para Java mesmo quando havia erros de sintaxe, e a representação de código da IDE era conectada a esse compilador.

• Uma das abordagens de busca de código mais interessantes que vi recentemente é o septum, que tem como objetivo trazer a quantidade adequada de contexto ao redor no nível de arquivo. Outra é stack-graphs, que tenta resolver incrementalmente relações simbólicas em toda a base de código.

• Me surpreende que hound, que eu considerava o líder entre as soluções open source, não tenha sido mencionado.

• O GitHub já me irritou ao "corrigir" um comportamento estranho de tokenização. Eles estão melhorando os recursos de find-usages no estilo IDE, mas ainda não é perfeito, então às vezes eu quero uma busca textual por "foo.bar()", e esse comportamento de stemming acaba encontrando todos os lugares onde foo e bar são mencionados, inflando os resultados.

• Não entendi a insinuação deles sobre o Zoekt. Em comparação com outras opções, ele não exige uma "nova promessa de infraestrutura". O servidor e o indexador são um único binário, então dificilmente poderia ser mais simples. Não vejo motivo para ter mais receio dele do que do Elasticsearch.

• O Oracle tem as views USER/ALL/DBA_SOURCE, nas quais todo o código PL/SQL carregado é apresentado. Fico me perguntando se a EnterpriseDB implementa isso dentro do Postgres, ou se isso pode ser usado como extensão.

• A busca do GitHub é ótima? Na maioria dos casos, ela parece quase inútil, e acho que clonar + ripgrep é muito mais eficiente. O problema parece ser mais a UX horrível do que a busca em si.