Kod Aramanın Zorlukları

Kod Aramanın Zorlukları

• Val Town'un mevcut arama özelliği Postgres ILIKE işlevine dayanıyor; bu yüzden yalnızca arama terimi kodun içinde geçiyorsa sonucu döndüren basit bir alt dizge aramasını destekliyor
  • Arama sonuçlarında neredeyse hiç sıralama yok ve birden fazla kelime içeren sorgular iyi desteklenmiyor
  • Daha iyi arama özelliği en çok talep edilen özelliklerden biri

Doğal dil araması ile kod araması arasındaki fark

• Genel arama çözümleri İngilizce gibi doğal dilleri hedeflediği için kod araması için uygun değil
  • Stop word kaldırma, stemming, lemmatization gibi algoritmalar kodda tersine sorun çıkarıyor
  • Örneğin the, TypeScript'te bir stop word değil, aramak isteyeceğiniz geçerli bir değişken adı olabilir
  • Kelime sınırları da farklı ve fonksiyon adlarına stemming uygulamanın da pek anlamı yok

Postgres Full Text Search

• Postgres'in Full Text Search uzantısı belli bir ölçeğe kadar iyi çalışıyor, ancak büyük ölçekte performans sorunlarıyla karşılaşıyor
  • Küçük ekiplerde altyapıyı mümkün olduğunca basit tutmak önemli olduğu için her şeyi Postgres ile çözmeye çalışıyorlar, ancak şu anda tek düğümlü bir Postgres kümesinin sınırlarını zorluyorlar
  • FTS ile kod araması yapılan örnekler bulmak zor

pg_trgrm ile trigram araması

• Trigram aramasının kod aramasında başarılı örnekleri var
  • Google Code Search, GitHub'ın yeni arama sistemi, Sourcegraph vb.
• Postgres'in pg_trgrm uzantısını kullanarak arama metni sütununda GIN indeksi oluşturup trigram aramasını destekliyorlar
  • Regex araması için iyi bir çözüm, ancak serbest biçimli sorgular için uygun bir sıralama üretmek zor

Kod araması için çeşitli seçenekler

• Meilisearch, Typesense, Zoekt, ParadeDB, Sonic gibi çeşitli arama motorları var, ancak çoğu kod aramasına özel değil
• GitHub, Sourcegraph gibi çözümlerin kod araması çok başarılı, ancak bunlar özel ekiplerin ve büyük zaman yatırımının ürünü
• Elasticsearch çok özelleştirilebilir, ancak küçük ekipler için işletme yükü yüksek
• Meilisearch, Rust ile yazılmış bir ES alternatifi, ancak daha çok gecikme süresine odaklanıyor gibi görünüyor
• ParadeDB, “sadece Postgres” olduğunu söyleyerek ES benzeri özellikler vadediyor, ancak henüz kullanılamıyor

GN⁺ Görüşü

• Şu anda Val Town'un yaptığı gibi, başlangıçta yalnızca Postgres'in temel özellikleriyle kod araması kurmak, altyapı yönetim yükünü azaltmak açısından akıllıca bir seçim gibi görünüyor. Ancak hizmet ölçeği büyüdükçe uzmanlaşmış bir arama motorunun devreye alınması kaçınılmaz görünüyor
• Ölçek büyüdüğünde en azından Elasticsearch gibi bir çözümün devreye alınması gerekecek gibi duruyor; ancak bu durumda bile bulut tabanlı yönetilen bir servis kullanmak altyapı yönetim yükünü azaltmanın bir yolu olabilir
• Kod aramasına özel açık kaynak sayısının az olması üzücü. Kod aramasının önemi giderek artarken, Sourcegraph benzeri kod aramasına odaklanan açık kaynak projelerin gelecekte daha da canlanması iyi olur
• Basit metin aramasının ötesinde, kodun yapısal özelliklerini yansıtan arama sıralama algoritmaları üzerine araştırma yapılması gerekiyor gibi görünüyor. Örneğin değişken adları, fonksiyon adları ve yorumları ayırıp farklı ağırlıklar vermek gibi
• Uzun vadede yönün, Large Language Model kullanan semantik kod aramasına doğru evrilmesi bekleniyor. Aynı mantığı taşısa bile adlandırması ya da biçimlendirmesi farklı olan kodu bulabilen semantik arama mümkün olursa, bu geliştirici verimliliğine büyük katkı sağlayacaktır

[GN⁺]

Hacker News görüşleri

• Sourcegraph büyük ölçekli kod aramayı ele alıyor, ancak ilk başladığınızda indeks olmadan yalnızca gerçek zamanlı aramayla bile şaşırtıcı derecede uzun süre iyi çalışıyor. Çünkü yalnızca ilk N eşleşmeyi bulmanız yeterli oluyor. Bu tür şeyler yapan insanlarla konuşmayı memnuniyetle karşılarım.

• İyi bir kod arama platformu hayatı çok daha kolaylaştırır. Google'dan ayrılınca en çok özleyeceğim şey kurum içi kod arama özelliği olurdu. Diğer her şeyle o kadar iyi entegre ki onsuz düşünmek zor. GitHub aramasını her kullandığımda bunun kıymetini daha çok anlıyorum. Kötü değil ama genelleştirilmiş bir kod arama platformu kurmak özünde çok daha zor.

• Yeni geliştiricilere açıkça öğretilmese de erken dönemde edinilmesi gereken, kesinlikle kritik bir beceri olan temel kod arama becerilerine dair ilerleme süreci:

  • Ctrl+F kullanmayı öğrenmek
  • ripgrepe geçmek
  • İsteğe bağlı ama güçlü komut satırı düzenleyicilerinden birini öğrenmek iyi olur
  • ripgrepten grepe geçip birkaç bayrak öğrenmek
  • ripgrep ile yapılabileceklerin bir sınırı olduğunu fark edip gerçek, indekslenmiş ve özel bir kod arama aracına geçmek

• IDE ve geliştirici araçları üreticileri, kod aramayı gerçekten doğru yapmak için derleyici platformlarını açmak gerektiği içgörüsüne uzun zaman önce sahipti. İyi kod arama; refaktör desteği, otomatik tamamlama ve diğer yaygın IDE özelliklerinin temelini oluşturur.

• IBM bunu Eclipse ile başardı ama o zamandan beri onunla boy ölçüşebilecek bir şey olmadı. Eclipse, sözdizimi hataları olsa bile Java için hızlı bir artımlı derleyiciye sahipti ve IDE'nin kod temsili bu derleyiciye bağlıydı.

• Son zamanlarda gördüğüm en ilginç kod arama yaklaşımlarından biri, dosya bazında çevredeki bağlamdan uygun miktarı getirmeyi hedefleyen septum. Bir diğeri ise tüm kod tabanında sembolik ilişkileri artımlı olarak çözmeye çalışan stack-graphs.

• Açık kaynak çözümlerin lideri olarak gördüğüm hounddan bahsedilmemesine şaşırdım.

• GitHub'ın garip tokenizasyon davranışını "düzeltip" can sıkıcı hale getirdiği oldu. IDE tarzı find-usages özelliğini geliştiriyorlar ama hâlâ mükemmel değil; bu yüzden bazen "foo.bar()" için düz metin araması yapmak istiyorum, ancak bu kök bulma davranışı foo ve bar'ın geçtiği her yeri bulup sonuçları şişiriyor.

• Zoekt için yaptıkları imayı anlamıyorum. Diğer seçeneklere göre "yeni bir altyapı taahhüdü" değil. Sunucu ve indeksleyici tek bir ikili dosya; bundan daha basit olamaz. Elasticsearch'ten daha fazla korkmayı gerektiren bir nedeni de yok gibi görünüyor.

• Oracle, yüklenmiş tüm PL/SQL kodunun sunulduğu USER/ALL/DBA_SOURCE görünümlerine sahip. EnterpriseDB bunu Postgres içinde uyguluyor mu ya da bir eklenti olarak kullanılabiliyor mu, merak ediyorum.

• GitHub araması harika mı? Çoğu durumda neredeyse işe yaramaz görünüyor ve clone + ripgrep'in çok daha verimli olduğunu düşünüyorum. Sorun gerçek aramadan çok UX'in korkunç olması gibi görünüyor.