ความยากของการค้นหาโค้ด

 (blog.val.town)
1 คะแนน โดย GN⁺ 2024-04-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ความยากของการค้นหาโค้ด

  • ฟังก์ชันค้นหาในปัจจุบันของ Val Town อิงกับความสามารถ ILIKE ของ Postgres จึงรองรับเพียงการค้นหาแบบ substring อย่างง่ายที่จะแสดงผลลัพธ์เมื่อคำค้นมีอยู่ในโค้ด
    • แทบไม่มีการจัดอันดับผลการค้นหา และยังรองรับการค้นหาที่มีหลายคำได้ไม่ดีนัก
    • ฟังก์ชันค้นหาที่ดีกว่านี้เป็นหนึ่งในความต้องการที่ถูกขอเข้ามามากที่สุด

ความแตกต่างระหว่างการค้นหาภาษาธรรมชาติกับการค้นหาโค้ด

  • โซลูชันค้นหาทั่วไปถูกออกแบบมาสำหรับภาษาธรรมชาติ เช่น ภาษาอังกฤษ จึงไม่ค่อยเหมาะกับการค้นหาโค้ด
    • อัลกอริทึมอย่างการลบ stop words, Stemming, Lemmatization กลับอาจสร้างปัญหากับโค้ด
    • ตัวอย่างเช่น the ใน TypeScript ไม่ใช่ stop-word แต่อาจเป็นชื่อตัวแปรที่ถูกต้องและเป็นสิ่งที่ผู้ใช้ต้องการค้นหา
    • ขอบเขตของคำก็แตกต่างกัน และการทำ stemming กับชื่อฟังก์ชันก็แทบไม่มีความหมายมากนัก

Full Text Search ของ Postgres

  • ส่วนขยาย Full Text Search ของ Postgres ทำงานได้ดีจนถึงระดับหนึ่ง แต่เมื่อขยายไปสเกลใหญ่จะเริ่มเจอปัญหาด้านประสิทธิภาพ
    • สำหรับทีมขนาดเล็ก การทำให้อินฟราสตรักเจอร์เรียบง่ายที่สุดเท่าที่ทำได้เป็นเรื่องสำคัญ จึงพยายามแก้ทุกอย่างด้วย Postgres แต่ตอนนี้กำลังเริ่มชนขีดจำกัดของคลัสเตอร์ Postgres แบบโหนดเดียว
    • หาเคสการใช้งานที่ใช้ FTS สำหรับค้นหาโค้ดได้ยาก

การค้นหาแบบ Trigram ด้วย pg_trgrm

  • การค้นหาแบบ Trigram มีตัวอย่างที่ประสบความสำเร็จในการค้นหาโค้ด
    • Google Code Search, ระบบค้นหาใหม่ของ GitHub, Sourcegraph เป็นต้น
  • ใช้ส่วนขยาย pg_trgrm ของ Postgres เพื่อสร้างดัชนี GIN บนคอลัมน์ข้อความสำหรับค้นหา และรองรับการค้นหาแบบ Trigram
    • เป็นทางออกที่ดีสำหรับการค้นหาด้วย regex แต่กับคำค้นแบบอิสระนั้นยากที่จะสร้างการจัดอันดับที่เหมาะสม

ตัวเลือกหลากหลายสำหรับการค้นหาโค้ด

  • มี search engine หลายตัว เช่น Meilisearch, Typesense, Zoekt, ParadeDB, Sonic แต่ส่วนใหญ่ไม่ได้ออกแบบมาเฉพาะสำหรับการค้นหาโค้ด
  • การค้นหาโค้ดของ GitHub และ Sourcegraph ทำได้ยอดเยี่ยม แต่เป็นผลลัพธ์จากการมีทีมเฉพาะทางและการลงทุนเวลาอย่างมาก
  • Elasticsearch ปรับแต่งได้มาก แต่สำหรับทีมเล็ก ภาระในการดูแลจัดการค่อนข้างสูง
  • Meilisearch เป็นทางเลือกแทน ES ที่พัฒนาด้วย Rust แต่ดูเหมือนจะโฟกัสที่ latency มากกว่า
  • ParadeDB โปรโมตตัวเองว่าเป็น "แค่ Postgres" พร้อมสัญญาว่าจะให้ความสามารถคล้าย ES แต่ตอนนี้ยังใช้งานไม่ได้

ความเห็นของ GN⁺

  • อย่างที่ Val Town ใช้อยู่ในตอนนี้ การเริ่มต้นทำระบบค้นหาโค้ดด้วยความสามารถพื้นฐานของ Postgres เพียงอย่างเดียวดูเป็นทางเลือกที่ชาญฉลาด เพราะช่วยลดภาระในการดูแลอินฟราสตรักเจอร์ได้ แต่เมื่อบริการขยายใหญ่ขึ้น การนำ search engine เฉพาะทางเข้ามาก็ดูจะหลีกเลี่ยงได้ยาก
  • เมื่อสเกลใหญ่ขึ้น ก็น่าจะจำเป็นต้องนำ Elasticsearch ระดับหนึ่งมาใช้ แต่ถึงอย่างนั้น การใช้บริการคลาวด์แบบ managed ก็น่าจะเป็นวิธีที่ช่วยลดภาระการดูแลอินฟราสตรักเจอร์ได้
  • น่าเสียดายที่ยังมีโอเพนซอร์สที่ออกแบบมาเฉพาะสำหรับการค้นหาโค้ดไม่มากนัก เมื่อความสำคัญของการค้นหาโค้ดเพิ่มขึ้นเรื่อย ๆ ก็อยากเห็นโปรเจกต์โอเพนซอร์สที่เน้นด้านนี้โดยตรง เช่น Sourcegraph มีความเคลื่อนไหวมากขึ้น
  • ดูเหมือนว่ายังจำเป็นต้องมีการวิจัยเรื่องอัลกอริทึมการจัดอันดับผลการค้นหาที่สะท้อนคุณลักษณะเชิงโครงสร้างของโค้ด มากกว่าการค้นหาแบบสตริงธรรมดา เช่น แยกน้ำหนักต่างกันให้กับชื่อตัวแปร ชื่อฟังก์ชัน และคอมเมนต์
  • ในระยะยาว คาดว่าจะพัฒนาไปสู่แนวทาง Semantic Code Search ที่ใช้ Large Language Model หากสามารถทำ semantic search ที่ค้นหาโค้ดซึ่งมีตรรกะเหมือนกันแม้จะตั้งชื่อหรือจัดรูปแบบต่างกันได้ ก็จะช่วยเพิ่มประสิทธิภาพการพัฒนาอย่างมาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-12
ความคิดเห็นจาก Hacker News

  • Sourcegraph จัดการกับการค้นหาโค้ดขนาดใหญ่ แต่ในช่วงเริ่มต้น การค้นหาแบบเรียลไทม์โดยไม่ทำดัชนีกลับใช้งานได้ดีนานกว่าที่คิด เพราะแค่หาผลลัพธ์ที่ตรงกัน N รายการแรกก็พอ ยินดีพูดคุยกับคนที่กำลังสร้างสิ่งแบบนี้

  • แพลตฟอร์มค้นหาโค้ดที่ดีทำให้ชีวิตง่ายขึ้นมาก ถ้าต้องออกจาก Google สิ่งที่จะคิดถึงที่สุดคือความสามารถในการค้นหาโค้ดภายในองค์กร มันผสานเข้ากับอย่างอื่นทั้งหมดได้ดีมากจนแทบนึกภาพไม่ออก ทุกครั้งที่ใช้การค้นหาของ Github ก็ยิ่งรู้สึกซาบซึ้งกับสิ่งนั้น ไม่ได้แย่ แต่การสร้างแพลตฟอร์มค้นหาโค้ดแบบทั่วไปนั้นยากกว่ามากโดยเนื้อแท้

  • แม้จะไม่ได้สอนนักพัฒนาใหม่อย่างชัดเจน แต่ลำดับความก้าวหน้าของความรู้เกี่ยวกับทักษะการค้นหาโค้ดพื้นฐาน ซึ่งเป็นทักษะสำคัญอย่างยิ่งที่ควรสร้างตั้งแต่ต้น มีดังนี้:

    • เรียนรู้การใช้ Ctrl+F
    • เปลี่ยนไปใช้ ripgrep
    • เป็นตัวเลือกแต่แนะนำอย่างมากให้เรียนรู้หนึ่งในโปรแกรมแก้ไขบนบรรทัดคำสั่งที่ทรงพลัง
    • ขยับจาก ripgrep ไปสู่ grep และเรียนรู้แฟล็กบางอย่าง
    • ตระหนักว่ามีข้อจำกัดกับสิ่งที่ทำได้ด้วย ripgrep แล้วเปลี่ยนไปใช้เครื่องมือค้นหาโค้ดเฉพาะทางที่มีการทำดัชนีจริง

  • ผู้สร้าง IDE และเครื่องมือพัฒนาตระหนักมานานแล้วว่า ถ้าจะทำการค้นหาโค้ดให้ดีจริง ต้องเปิดแพลตฟอร์มคอมไพเลอร์ การค้นหาโค้ดที่ดีเป็นรากฐานของการรองรับการรีแฟกเตอร์ การเติมโค้ดอัตโนมัติ และฟังก์ชัน IDE ทั่วไปอื่น ๆ

  • IBM เคยทำสิ่งนี้ได้ด้วย Eclipse แต่หลังจากนั้นก็ไม่มีอะไรที่เทียบได้ Eclipse มีคอมไพเลอร์แบบ incremental ที่รวดเร็วสำหรับ Java แม้จะมีข้อผิดพลาดทางไวยากรณ์ก็ตาม และการแสดงแทนโค้ดใน IDE ก็เชื่อมโยงกับคอมไพเลอร์นั้น

  • หนึ่งในแนวทางการค้นหาโค้ดที่น่าสนใจที่สุดที่เห็นเมื่อเร็ว ๆ นี้คือ septum ซึ่งมีเป้าหมายจะดึงบริบทโดยรอบในปริมาณที่เหมาะสมในระดับไฟล์ อีกอย่างคือ stack-graphs ที่พยายามแก้ความสัมพันธ์เชิงสัญลักษณ์แบบ incremental ทั่วทั้งโค้ดเบส

  • แปลกใจที่ไม่มีการพูดถึง hound ซึ่งเคยคิดว่าเป็นผู้นำในหมู่โซลูชันโอเพนซอร์ส

  • Github เคยทำให้หงุดหงิดด้วยการ "แก้ไข" พฤติกรรมการ tokenize แปลก ๆ พวกเขากำลังปรับปรุงฟีเจอร์ find-usages แบบสไตล์ IDE แต่ก็ยังไม่สมบูรณ์ ดังนั้นบางครั้งจึงอยากได้การค้นหาข้อความสำหรับ "foo.bar()" แต่พฤติกรรมการ stemming นี้กลับไปหาทุกที่ที่มีการพูดถึง foo และ bar ทำให้ผลลัพธ์บวมเกินจริง

  • ไม่เข้าใจว่าทำไมพวกเขาถึงปัดมือไปที่ Zoekt มันไม่ใช่ "ภาระผูกพันด้านโครงสร้างพื้นฐานใหม่" มากกว่าตัวเลือกอื่นเลย เซิร์ฟเวอร์และตัวทำดัชนีเป็นไบนารีเดียว จะให้เรียบง่ายกว่านี้ก็แทบไม่ได้แล้ว ดูไม่มีเหตุผลที่จะต้องกลัวมันมากกว่า Elasticsearch

  • Oracle มีวิว USER/ALL/DBA_SOURCE ที่แสดงโค้ด PL/SQL ทั้งหมดที่ถูกโหลดไว้ อยากรู้ว่า EnterpriseDB ได้นำสิ่งนี้ไปทำไว้ภายใน Postgres หรือมีให้ใช้เป็นส่วนขยายหรือไม่

  • การค้นหาของ Github ยอดเยี่ยมเหรอ? สำหรับกรณีส่วนใหญ่รู้สึกว่าแทบไม่มีประโยชน์ และคิดว่าการ clone มาแล้วใช้ ripgrep มีประสิทธิภาพกว่ามาก ดูเหมือนปัญหาจะเป็น UX ที่แย่มาก มากกว่าจะเป็นการค้นหาจริง ๆ