Độ khó của tìm kiếm mã nguồn

 (blog.val.town)
1 điểm bởi GN⁺ 2024-04-12 | 1 bình luận | Chia sẻ qua WhatsApp

Độ khó của tìm kiếm mã nguồn

  • Tính năng tìm kiếm hiện tại của Val Town dựa trên chức năng Postgres ILIKE, nên chỉ hỗ trợ tìm kiếm chuỗi con đơn giản: nếu từ khóa xuất hiện trong mã thì nó sẽ được đưa vào kết quả tìm kiếm
    • Hầu như không có xếp hạng kết quả tìm kiếm, và việc tìm kiếm với nhiều từ cũng không được hỗ trợ tốt
    • Một tính năng tìm kiếm tốt hơn là một trong những yêu cầu được đưa ra nhiều nhất

Khác biệt giữa tìm kiếm ngôn ngữ tự nhiên và tìm kiếm mã nguồn

  • Các giải pháp tìm kiếm thông thường nhắm đến ngôn ngữ tự nhiên như tiếng Anh, nên không phù hợp với tìm kiếm mã nguồn
    • Các thuật toán như loại bỏ stop words, stemming, lemmatization lại gây ra vấn đề đối với mã nguồn
    • Ví dụ, the không phải là stop-word trong TypeScript mà có thể là một tên biến hợp lệ mà người dùng muốn tìm
    • Ranh giới từ cũng khác, và việc stemming tên hàm cũng không có nhiều ý nghĩa

Full Text Search của Postgres

  • Phần mở rộng Full Text Search của Postgres hoạt động tốt đến một quy mô nhất định, nhưng khi mở rộng lớn hơn sẽ gặp vấn đề về hiệu năng
    • Với các nhóm nhỏ, việc giữ hạ tầng đơn giản nhất có thể là điều quan trọng nên họ muốn giải quyết mọi thứ bằng Postgres, nhưng hiện tại đang chạm tới giới hạn của một cụm Postgres single-node
    • Rất khó tìm thấy các ví dụ dùng FTS cho tìm kiếm mã nguồn

Tìm kiếm Trigram bằng pg_trgrm

  • Tìm kiếm Trigram đã có những trường hợp thành công trong tìm kiếm mã nguồn
    • Google Code Search, hệ thống tìm kiếm mới của GitHub, Sourcegraph, v.v.
  • Dùng phần mở rộng pg_trgrm của Postgres để tạo chỉ mục GIN trên cột văn bản tìm kiếm nhằm hỗ trợ tìm kiếm Trigram
    • Đây là một giải pháp tốt cho tìm kiếm bằng biểu thức chính quy, nhưng rất khó tạo ra xếp hạng phù hợp cho các truy vấn tự do

Nhiều lựa chọn khác nhau cho tìm kiếm mã nguồn

  • Có nhiều công cụ tìm kiếm như Meilisearch, Typesense, Zoekt, ParadeDB, Sonic, nhưng phần lớn không được tối ưu riêng cho tìm kiếm mã nguồn
  • Tìm kiếm mã nguồn của GitHub hay Sourcegraph rất xuất sắc, nhưng đó là kết quả của các đội ngũ chuyên trách và khoản đầu tư thời gian lớn
  • Elasticsearch có thể tùy biến rất nhiều, nhưng gánh nặng vận hành đối với nhóm nhỏ là khá lớn
  • Meilisearch là một lựa chọn thay thế ES được viết bằng Rust, nhưng có vẻ tập trung nhiều hơn vào độ trễ
  • ParadeDB tự nhận là "chỉ là Postgres" và hứa hẹn các tính năng tương tự ES, nhưng hiện vẫn chưa thể sử dụng

Ý kiến của GN⁺

  • Như cách Val Town đang làm hiện nay, việc triển khai tìm kiếm mã nguồn ban đầu chỉ bằng các chức năng cơ bản của Postgres có vẻ là một lựa chọn hợp lý để giảm gánh nặng quản lý hạ tầng. Tuy nhiên, khi quy mô dịch vụ tăng lên thì việc đưa vào một công cụ tìm kiếm chuyên dụng dường như sẽ là điều khó tránh khỏi
  • Khi quy mô lớn hơn, có lẽ sẽ cần đưa vào ít nhất là Elasticsearch, nhưng ngay cả trong trường hợp đó thì dùng dịch vụ cloud managed cũng sẽ là cách giúp giảm bớt gánh nặng vận hành hạ tầng
  • Việc thiếu các dự án mã nguồn mở chuyên biệt cho tìm kiếm mã nguồn là điều đáng tiếc. Khi tầm quan trọng của tìm kiếm mã nguồn ngày càng tăng, hy vọng trong tương lai sẽ có thêm nhiều dự án mã nguồn mở chuyên về lĩnh vực này như Sourcegraph hoạt động sôi nổi hơn
  • Có vẻ cần thêm nghiên cứu về các thuật toán xếp hạng tìm kiếm phản ánh được đặc tính cấu trúc của mã nguồn, vượt ra ngoài tìm kiếm chuỗi đơn thuần. Ví dụ như phân biệt tên biến, tên hàm, chú thích rồi gán trọng số khác nhau
  • Về lâu dài, nhiều khả năng hướng phát triển sẽ là Semantic Code Search sử dụng Large Language Model. Nếu có thể thực hiện tìm kiếm ngữ nghĩa để tìm ra những đoạn mã có cùng logic dù khác cách đặt tên hay định dạng, điều đó sẽ giúp tăng đáng kể năng suất phát triển

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-12
Ý kiến trên Hacker News

  • Sourcegraph xử lý tìm kiếm mã nguồn ở quy mô lớn, nhưng khi mới bắt đầu thì chỉ với tìm kiếm thời gian thực không có chỉ mục cũng hoạt động tốt lâu hơn mong đợi. Lý do là chỉ cần tìm N kết quả khớp đầu tiên. Rất hoan nghênh trao đổi với những người xây dựng kiểu công cụ này.

  • Một nền tảng tìm kiếm mã nguồn tốt giúp cuộc sống dễ dàng hơn rất nhiều. Khi rời Google, thứ tôi nhớ nhất sẽ là khả năng tìm kiếm mã nguồn nội bộ. Nó được tích hợp quá tốt với mọi thứ khác đến mức khó tưởng tượng nổi. Mỗi lần dùng tìm kiếm của Github tôi lại càng thấy trân trọng điều đó hơn. Nó không tệ, nhưng xây dựng một nền tảng tìm kiếm mã nguồn tổng quát về bản chất khó hơn nhiều.

  • Không ai dạy rõ ràng cho lập trình viên mới, nhưng đây là tiến trình hiểu biết về kỹ năng tìm kiếm mã nguồn cơ bản, một kỹ năng cực kỳ quan trọng cần xây dựng từ sớm:

    • Học cách dùng Ctrl+F
    • Chuyển sang ripgrep
    • Tùy chọn nhưng rất nên học một trong các trình soạn thảo dòng lệnh mạnh mẽ
    • Đi từ ripgrep sang grep và học thêm một vài cờ
    • Nhận ra rằng có giới hạn với những gì ripgrep làm được và chuyển sang công cụ tìm kiếm mã nguồn chuyên dụng có lập chỉ mục thực sự

  • Các nhà làm IDE và công cụ phát triển từ lâu đã có nhận thức rằng để làm tốt việc tìm kiếm mã nguồn thì cần mở nền tảng trình biên dịch. Tìm kiếm mã nguồn tốt là nền tảng cho hỗ trợ refactor, tự động hoàn thành và các tính năng IDE phổ biến khác.

  • IBM đã làm được điều này với Eclipse, nhưng từ đó đến nay chưa có gì sánh được. Eclipse có trình biên dịch tăng dần nhanh cho Java ngay cả khi có lỗi cú pháp, và biểu diễn mã nguồn trong IDE được gắn với chính trình biên dịch đó.

  • Một trong những cách tiếp cận tìm kiếm mã nguồn thú vị nhất tôi thấy gần đây là septum, với mục tiêu lấy đúng lượng ngữ cảnh xung quanh theo đơn vị tệp. Một cái khác là stack-graphs, cố gắng giải quyết gia tăng các quan hệ ký hiệu trên toàn bộ codebase.

  • Tôi ngạc nhiên vì không thấy nhắc đến hound, thứ mà tôi từng nghĩ là đầu tàu trong các giải pháp mã nguồn mở.

  • Github từng gây khó chịu khi họ "sửa" hành vi tách token theo cách kỳ quặc. Họ đang cải thiện tính năng find-usages kiểu IDE nhưng vẫn chưa hoàn hảo, nên đôi khi tôi chỉ muốn tìm kiếm văn bản cho foo.bar(), trong khi kiểu stemming này lại tìm mọi chỗ có nhắc đến foo và bar, làm phình to kết quả.

  • Tôi không hiểu cách họ ám chỉ về Zoekt. Nó không phải là một "cam kết hạ tầng mới" hơn các lựa chọn khác. Máy chủ và bộ lập chỉ mục là một binary duy nhất, không thể đơn giản hơn nữa. Có vẻ không có lý do gì để sợ nó hơn Elasticsearch.

  • Oracle có các view USER/ALL/DBA_SOURCE nơi toàn bộ mã PL/SQL đã nạp được trình bày ra. Tôi tự hỏi liệu EnterpriseDB có triển khai điều này bên trong Postgres hay có thể dùng như một extension hay không.

  • Tìm kiếm của Github mà tuyệt vời sao? Trong đa số trường hợp tôi thấy nó gần như vô dụng, và clone về + ripgrep hiệu quả hơn nhiều. Có vẻ vấn đề nằm ở UX tệ hại hơn là ở bản thân chức năng tìm kiếm thực sự.