Sulitnya Pencarian Kode

Sulitnya Pencarian Kode

• Fitur pencarian Val Town saat ini berbasis kemampuan Postgres ILIKE, sehingga hanya mendukung pencarian substring sederhana yang memasukkan hasil jika kata kunci ada di dalam kode
  • Hampir tidak ada pemeringkatan hasil pencarian, dan pencarian yang mencakup beberapa kata juga tidak didukung dengan baik
  • Fitur pencarian yang lebih baik adalah salah satu permintaan yang paling sering diajukan

Perbedaan pencarian bahasa alami dan pencarian kode

• Solusi pencarian umum ditujukan untuk bahasa alami seperti bahasa Inggris, sehingga kurang cocok untuk pencarian kode
  • Algoritme seperti penghapusan stop words, stemming, dan lemmatization justru menimbulkan masalah pada kode
  • Misalnya, the dalam TypeScript bukan stop word, melainkan bisa menjadi nama variabel valid yang memang ingin dicari
  • Batas kata juga berbeda, dan melakukan stemming pada nama fungsi pun tidak terlalu bermakna

Full Text Search di Postgres

• Ekstensi Full Text Search di Postgres bekerja cukup baik hingga skala tertentu, tetapi saat membesar akan menemui masalah performa
  • Bagi tim kecil, penting untuk menjaga infrastruktur sesederhana mungkin sehingga mereka berusaha menyelesaikan semuanya dengan Postgres, tetapi saat ini mereka sedang menantang batas cluster Postgres single-node
  • Sulit menemukan contoh penggunaan FTS untuk pencarian kode

Pencarian Trigram dengan pg_trgrm

• Pencarian trigram punya beberapa contoh keberhasilan dalam pencarian kode
  • Google Code Search, sistem pencarian baru GitHub, Sourcegraph, dan lain-lain
• Dengan ekstensi Postgres pg_trgrm, dukungan pencarian trigram ditambahkan dengan membuat indeks GIN pada kolom teks pencarian
  • Ini solusi yang baik untuk pencarian regex, tetapi sulit membuat pemeringkatan yang tepat untuk kueri bebas

Berbagai opsi untuk pencarian kode

• Ada berbagai search engine seperti Meilisearch, Typesense, Zoekt, ParadeDB, dan Sonic, tetapi kebanyakan tidak dikhususkan untuk pencarian kode
• Pencarian kode GitHub dan Sourcegraph sangat bagus, tetapi itu adalah hasil dari tim khusus dan investasi waktu yang besar
• Elasticsearch sangat bisa dikustomisasi, tetapi beban pengelolaannya besar untuk tim kecil
• Meilisearch adalah alternatif ES yang dibuat dengan Rust, tetapi tampaknya lebih berfokus pada latensi
• ParadeDB mengusung slogan "cukup Postgres" dan menjanjikan fitur mirip ES, tetapi belum bisa digunakan

Opini GN⁺

• Seperti yang saat ini dilakukan Val Town, pada tahap awal mengimplementasikan pencarian kode hanya dengan fitur dasar Postgres tampak sebagai pilihan yang bijak untuk mengurangi beban pengelolaan infrastruktur. Namun, ketika skala layanan membesar, adopsi search engine khusus tampaknya akan sulit dihindari
• Saat skala membesar, rasanya setidaknya perlu mengadopsi Elasticsearch, tetapi bahkan dalam kasus ini menggunakan layanan cloud terkelola akan menjadi cara untuk mengurangi beban operasional infrastruktur
• Disayangkan bahwa tidak banyak open source yang benar-benar khusus untuk pencarian kode. Seiring pentingnya pencarian kode yang terus meningkat, akan bagus bila ke depan proyek open source yang berfokus pada pencarian kode seperti Sourcegraph menjadi lebih aktif
• Tampaknya diperlukan riset tentang algoritme pemeringkatan pencarian yang mencerminkan karakteristik struktural kode, melampaui pencarian string sederhana. Misalnya, dengan membedakan nama variabel, nama fungsi, komentar, dan memberi bobot yang berbeda
• Dalam jangka panjang, arahnya diperkirakan akan berkembang menuju Semantic Code Search yang memanfaatkan Large Language Model. Jika pencarian semantik yang dapat menemukan kode dengan logika sama meski penamaan atau formatnya berbeda menjadi mungkin, itu akan sangat membantu produktivitas developer

[GN⁺]

Komentar Hacker News

• Sourcegraph menangani pencarian kode skala besar, tetapi saat baru memulai, pencarian waktu nyata tanpa indeks pun ternyata bisa bekerja dengan baik jauh lebih lama dari yang diperkirakan. Karena yang perlu ditemukan hanya N kecocokan pertama. Senang berdiskusi dengan orang-orang yang membangun hal seperti ini.

• Platform pencarian kode yang bagus membuat hidup jauh lebih mudah. Jika meninggalkan Google, fitur pencarian kode internal adalah hal yang paling akan dirindukan. Integrasinya dengan semua hal lain begitu baik sampai sulit dibayangkan. Setiap kali memakai pencarian Github, rasa apresiasi itu makin besar. Bukan berarti buruk, tetapi membangun platform pencarian kode yang bersifat umum pada dasarnya jauh lebih sulit.

• Ini memang tidak diajarkan secara eksplisit kepada para pengembang baru, tetapi berikut perkembangan pengetahuan tentang keterampilan dasar pencarian kode yang mutlak penting dan sebaiknya dibangun sejak awal:

  • Belajar menggunakan Ctrl+F
  • Beralih ke ripgrep
  • Opsional, tetapi ada baiknya mempelajari salah satu editor baris perintah yang kuat
  • Beralih dari ripgrep ke grep dan mempelajari beberapa flag
  • Menyadari bahwa ada batas pada apa yang bisa dilakukan dengan ripgrep, lalu beralih ke alat pencarian kode khusus yang benar-benar terindeks

• Pembuat IDE dan alat pengembang sudah lama punya wawasan bahwa untuk melakukan pencarian kode dengan benar, platform kompiler harus dibuka. Pencarian kode yang baik menjadi fondasi dukungan refactoring, autocompletion, dan fungsi IDE umum lainnya.

• IBM mewujudkannya lewat Eclipse, tetapi sejak itu belum ada yang benar-benar sebanding. Eclipse memiliki kompiler inkremental cepat untuk Java bahkan ketika ada kesalahan sintaks, dan representasi kode di IDE terhubung dengan kompiler tersebut.

• Salah satu pendekatan pencarian kode paling menarik yang saya lihat belakangan ini adalah septum, yang bertujuan mengambil jumlah konteks sekitar yang tepat per berkas. Yang lain adalah stack-graphs, yang mencoba menyelesaikan relasi simbolik secara inkremental di seluruh codebase.

• Saya terkejut hound, yang saya anggap pemimpin di antara solusi open source, tidak disebutkan.

• Github pernah menjengkelkan karena "memperbaiki" perilaku tokenisasi yang aneh. Mereka memang meningkatkan fitur find-usages bergaya IDE, tetapi masih belum sempurna, jadi kadang saya tetap ingin pencarian teks untuk "foo.bar()", namun perilaku stemming ini malah menemukan semua tempat yang menyebut foo dan bar sehingga hasilnya membengkak.

• Saya tidak paham isyarat mereka tentang Zoekt. Itu bukan "komitmen infrastruktur baru" dibanding opsi lain. Server dan indexer-nya adalah satu binary tunggal, jadi rasanya tidak bisa lebih sederhana lagi. Tidak terlihat ada alasan untuk lebih takut padanya dibanding Elasticsearch.

• Oracle memiliki view USER/ALL/DBA_SOURCE yang menampilkan semua kode PL/SQL yang dimuat. Saya penasaran apakah EnterpriseDB mengimplementasikan ini di dalam Postgres, atau apakah ini tersedia sebagai ekstensi.

• Pencarian Github hebat? Dalam kebanyakan kasus rasanya hampir tidak berguna, dan menurut saya clone + ripgrep jauh lebih efisien. Sepertinya masalahnya lebih pada UX yang mengerikan daripada kemampuan pencarian itu sendiri.