कोड खोज की मुश्किलें

कोड खोज की मुश्किलें

• Val Town की मौजूदा search सुविधा Postgres की ILIKE functionality पर आधारित है, इसलिए यह केवल simple substring search को support करती है, जहाँ search term कोड में मौजूद हो तो ही वह परिणामों में शामिल होता है
  • search results की ranking लगभग नहीं के बराबर है, और कई शब्दों वाले queries को भी अच्छी तरह support नहीं किया जाता
  • बेहतर search सुविधा सबसे ज़्यादा माँगी जाने वाली features में से एक है

Natural language search और code search का अंतर

• सामान्य search solutions अंग्रेज़ी जैसी natural language के लिए बनाए जाते हैं, इसलिए वे code search के लिए उपयुक्त नहीं होते
  • Stop words removal, stemming, lemmatization जैसे algorithms कोड में उल्टा समस्याएँ पैदा करते हैं
  • उदाहरण के लिए, the TypeScript में stop-word नहीं बल्कि खोजे जाने योग्य एक valid variable name हो सकता है
  • शब्द सीमाएँ भी अलग होती हैं, और function names पर stemming करने का भी ज़्यादा मतलब नहीं होता

Postgres का Full Text Search

• Postgres का Full Text Search extension एक सीमा तक अच्छी तरह काम करता है, लेकिन बड़े पैमाने पर performance issues से टकराता है
  • छोटी teams के लिए infrastructure को जितना हो सके उतना simple रखना महत्वपूर्ण है, इसलिए वे Postgres से ही सब कुछ हल करना चाहती हैं, लेकिन अभी single-node Postgres cluster की सीमाओं को चुनौती दी जा रही है
  • FTS का उपयोग करके code search के उदाहरण ढूँढना मुश्किल है

pg_trgrm का उपयोग करके Trigram search

• Trigram search के code search में सफल उपयोग के उदाहरण मौजूद हैं
  • Google Code Search, GitHub का नया search system, Sourcegraph आदि
• Postgres के pg_trgrm extension का उपयोग करके search text column पर GIN index बनाकर Trigram search को support किया जा सकता है
  • यह regex search के लिए अच्छा समाधान है, लेकिन free-form queries के लिए उपयुक्त ranking बनाना कठिन है

code search के लिए विभिन्न विकल्प

• Meilisearch, Typesense, Zoekt, ParadeDB, Sonic जैसे कई search engines हैं, लेकिन अधिकांश code search के लिए विशेष रूप से अनुकूलित नहीं हैं
• GitHub और Sourcegraph जैसी code search systems उत्कृष्ट हैं, लेकिन वे dedicated teams और लंबे समय के निवेश का परिणाम हैं
• Elasticsearch को बहुत अधिक customize किया जा सकता है, लेकिन छोटी teams के लिए इसे manage करना बोझिल है
• Meilisearch, Rust में बनाया गया ES alternative है, लेकिन ऐसा लगता है कि उसका ज़ोर latency पर अधिक है
• ParadeDB खुद को "सिर्फ Postgres" कहता है और ES जैसी capabilities का वादा करता है, लेकिन अभी इसका उपयोग नहीं किया जा सकता

GN⁺ की राय

• अभी Val Town की तरह शुरुआती चरण में Postgres की built-in capabilities से ही code search बनाना infrastructure management का बोझ कम करने के लिए समझदारी भरा विकल्प लगता है। लेकिन service का scale बढ़ने पर किसी specialized search engine को अपनाना लगभग अनिवार्य दिखता है
• scale बढ़ने पर Elasticsearch जैसे समाधान की ज़रूरत पड़ सकती है, लेकिन उस स्थिति में भी cloud-managed service का उपयोग infrastructure management का बोझ कम करने का अच्छा तरीका होगा
• यह अफ़सोस की बात है कि code search के लिए विशेष रूप से बने open source विकल्प बहुत कम हैं। code search का महत्व लगातार बढ़ रहा है, इसलिए आगे Sourcegraph जैसे code-search-focused open source projects और अधिक सक्रिय हों तो अच्छा होगा
• simple string search से आगे बढ़कर, code की structural characteristics को ध्यान में रखने वाले ranking algorithms पर शोध की ज़रूरत दिखती है। उदाहरण के लिए variable names, function names, comments आदि को अलग-अलग पहचानकर अलग weight देना
• लंबी अवधि में यह दिशा Large Language Model का उपयोग करने वाली Semantic Code Search की ओर बढ़ती दिखती है। यदि naming या formatting में अंतर होने पर भी एक ही logic वाले code को खोजने वाली semantic search संभव हो जाए, तो यह developer productivity के लिए बहुत मददगार होगा

[GN⁺]

Hacker News राय

• Sourcegraph बड़े पैमाने पर code search संभालता है, लेकिन शुरुआत में बिना index के सिर्फ real-time search से भी यह उम्मीद से कहीं अधिक समय तक अच्छी तरह काम करता है। क्योंकि सिर्फ पहले N matches ढूंढने होते हैं। ऐसी चीज़ें बनाने वाले लोगों से बात करने का स्वागत है.

• एक अच्छा code search platform जीवन को बहुत आसान बना देता है। Google छोड़ने पर उसकी internal code search क्षमता सबसे ज़्यादा याद आएगी। वह बाकी हर चीज़ के साथ इतनी अच्छी तरह integrated है कि उसके बिना कल्पना करना मुश्किल है। हर बार Github search इस्तेमाल करते हुए उसकी और भी कद्र होती है। यह बुरा नहीं है, लेकिन एक generalized code search platform बनाना स्वभावतः कहीं अधिक कठिन है.

• नए developers को इसे आमतौर पर स्पष्ट रूप से नहीं सिखाया जाता, लेकिन शुरुआती दौर में बनानी वाली बिल्कुल महत्वपूर्ण skill यानी बुनियादी code search skills की प्रगति कुछ ऐसी होती है:

  • Ctrl+F इस्तेमाल करना सीखना
  • ripgrep पर जाना
  • वैकल्पिक है, लेकिन शक्तिशाली command-line editors में से किसी एक को सीखना अच्छा है
  • ripgrep से grep की ओर जाना और कुछ flags सीखना
  • यह समझना कि ripgrep से क्या किया जा सकता है उसकी सीमाएँ हैं, और फिर एक वास्तविक indexed dedicated code search tool पर जाना

• IDE और development tools बनाने वालों के पास बहुत पहले से यह समझ थी कि code search को सही ढंग से करने के लिए compiler platform को खोलना पड़ता है। अच्छा code search, refactoring support, autocomplete और अन्य सामान्य IDE features की नींव बनता है.

• IBM ने Eclipse के साथ यह कर दिखाया था, लेकिन उसके बाद से उसके बराबर कुछ नहीं आया। Eclipse के पास Java के लिए एक तेज incremental compiler था, जो syntax errors होने पर भी काम करता था, और IDE में code representation उसी compiler से जुड़ी हुई थी.

• हाल में देखे गए सबसे दिलचस्प code search approaches में से एक septum है, जिसका लक्ष्य आसपास के context की उचित मात्रा को file unit के हिसाब से लाना है। दूसरा stack-graphs है, जो पूरे codebase में symbolic relationships को incrementally resolve करने की कोशिश करता है.

• यह देखकर आश्चर्य हुआ कि hound, जिसे मैं open source solutions का लीडर मानता था, का ज़िक्र नहीं हुआ.

• Github कभी-कभी अपनी अजीब tokenization behavior को "ठीक" करके परेशान करता है। वह IDE-style find-usages functionality को बेहतर बना रहा है, लेकिन अभी भी यह परफेक्ट नहीं है, इसलिए कभी-कभी मैं सिर्फ "foo.bar()" के लिए text search चाहता हूँ, लेकिन यह stemming behavior foo और bar के हर उल्लेख को ढूंढकर results को फुला देता है.

• Zoekt के बारे में उनका इशारा समझ नहीं आया। यह दूसरे options की तुलना में कोई "नई infra commitment" नहीं है। server और indexer एक single binary हैं, इसलिए इससे सरल शायद ही कुछ हो। Elasticsearch की तुलना में इससे डरने की कोई वजह नहीं दिखती.

• Oracle के पास USER/ALL/DBA_SOURCE views हैं, जिनमें लोड किया गया पूरा PL/SQL code दिखाया जाता है। जिज्ञासा है कि क्या EnterpriseDB इसे Postgres के अंदर implement करता है, या extension के रूप में इस्तेमाल किया जा सकता है.

• Github search शानदार है? ज़्यादातर मामलों में यह लगभग बेकार लगता है, और मेरा मानना है कि clone + ripgrep कहीं अधिक प्रभावी है। असली समस्या search से ज़्यादा उसकी भयानक UX लगती है.