Sourcegraph은 대규모 코드 검색을 다루지만, 처음 시작할 때는 인덱스 없이 실시간 검색만으로도 생각보다 오래 잘 작동함. 첫 N개 일치만 찾으면 되기 때문. 이런 것을 만드는 사람들과 대화하는 것을 환영함.
좋은 코드 검색 플랫폼은 삶을 훨씬 쉽게 만들어줌. Google을 떠나면 내부 코드 검색 기능이 가장 그리울 것. 다른 모든 것과 잘 통합되어 있어서 상상할 수 없음. Github 검색을 사용할 때마다 더욱 감사하게 됨. 나쁘진 않지만 일반화된 코드 검색 플랫폼을 구축하는 것은 본질적으로 훨씬 어려움.
새로운 개발자들에게 명시적으로 가르치지는 않지만 초기에 구축해야 할 절대적으로 중요한 기술인 기본 코드 검색 기술에 대한 지식 진행 과정:
Ctrl+F 사용법 배우기
ripgrep으로 전환
선택사항이지만 강력한 명령줄 편집기 중 하나를 배우는 것이 좋음
ripgrep에서 grep으로 이동하고 몇 가지 플래그 배우기
ripgrep으로 할 수 있는 것에 한계가 있다는 것을 깨닫고 실제 인덱싱된 전용 코드 검색 도구로 전환
IDE와 개발 도구 제작자들은 오래전부터 코드 검색을 제대로 하려면 컴파일러 플랫폼을 개방해야 한다는 통찰력을 가지고 있었음. 좋은 코드 검색은 리팩터링 지원, 자동 완성 및 기타 일반적인 IDE 기능의 기반이 됨.
IBM은 Eclipse로 이것을 해냈지만 그 이후로는 그에 필적할 만한 것이 없었음. Eclipse는 구문 오류가 있는 경우에도 Java용 빠른 증분 컴파일러를 가지고 있었고, IDE의 코드 표현은 해당 컴파일러와 연결되어 있었음.
최근에 본 가장 흥미로운 코드 검색 접근 방식 중 하나는 septum인데, 주변 컨텍스트의 적절한 양을 파일 단위로 가져오는 것을 목표로 함. 또 다른 것은 stack-graphs로, 전체 코드베이스에서 상징적 관계를 증분적으로 해결하려고 함.
오픈소스 솔루션의 리더라고 생각했던 hound가 언급되지 않아 놀람.
Github가 이상한 토큰화 동작을 "고쳐서" 성가신 적이 있음. IDE 스타일의 find-usages 기능을 개선하고 있지만 여전히 완벽하지 않아서 "foo.bar()"에 대한 텍스트 검색을 원할 때가 있는데 이 스테밍 동작이 foo와 bar가 언급된 모든 곳을 찾아 결과를 부풀림.
Zoekt에 대한 그들의 손짓이 이해가 안 됨. 다른 옵션보다 "새로운 인프라 약속"이 아님. 서버와 인덱서는 단일 바이너리여서 이보다 더 간단할 수 없음. Elasticsearch보다 더 무서워할 이유가 없어 보임.
Oracle은 로드된 모든 PL/SQL 코드가 제시되는 USER/ALL/DBA_SOURCE 뷰를 가지고 있음. EnterpriseDB가 이를 Postgres 내부에 구현하는지, 확장으로 사용할 수 있는지 궁금함.
Github 검색이 훌륭하다고? 대부분의 경우 거의 쓸모없는 것 같고, 복제 + ripgrep이 훨씬 더 효율적이라고 생각함. 실제 검색보다는 UX가 끔찍한 게 문제인 것 같음.
Hacker News 의견
Sourcegraph은 대규모 코드 검색을 다루지만, 처음 시작할 때는 인덱스 없이 실시간 검색만으로도 생각보다 오래 잘 작동함. 첫 N개 일치만 찾으면 되기 때문. 이런 것을 만드는 사람들과 대화하는 것을 환영함.
좋은 코드 검색 플랫폼은 삶을 훨씬 쉽게 만들어줌. Google을 떠나면 내부 코드 검색 기능이 가장 그리울 것. 다른 모든 것과 잘 통합되어 있어서 상상할 수 없음. Github 검색을 사용할 때마다 더욱 감사하게 됨. 나쁘진 않지만 일반화된 코드 검색 플랫폼을 구축하는 것은 본질적으로 훨씬 어려움.
새로운 개발자들에게 명시적으로 가르치지는 않지만 초기에 구축해야 할 절대적으로 중요한 기술인 기본 코드 검색 기술에 대한 지식 진행 과정:
Ctrl+F사용법 배우기ripgrep으로 전환ripgrep에서grep으로 이동하고 몇 가지 플래그 배우기ripgrep으로 할 수 있는 것에 한계가 있다는 것을 깨닫고 실제 인덱싱된 전용 코드 검색 도구로 전환IDE와 개발 도구 제작자들은 오래전부터 코드 검색을 제대로 하려면 컴파일러 플랫폼을 개방해야 한다는 통찰력을 가지고 있었음. 좋은 코드 검색은 리팩터링 지원, 자동 완성 및 기타 일반적인 IDE 기능의 기반이 됨.
IBM은 Eclipse로 이것을 해냈지만 그 이후로는 그에 필적할 만한 것이 없었음. Eclipse는 구문 오류가 있는 경우에도 Java용 빠른 증분 컴파일러를 가지고 있었고, IDE의 코드 표현은 해당 컴파일러와 연결되어 있었음.
최근에 본 가장 흥미로운 코드 검색 접근 방식 중 하나는
septum인데, 주변 컨텍스트의 적절한 양을 파일 단위로 가져오는 것을 목표로 함. 또 다른 것은stack-graphs로, 전체 코드베이스에서 상징적 관계를 증분적으로 해결하려고 함.오픈소스 솔루션의 리더라고 생각했던
hound가 언급되지 않아 놀람.Github가 이상한 토큰화 동작을 "고쳐서" 성가신 적이 있음. IDE 스타일의 find-usages 기능을 개선하고 있지만 여전히 완벽하지 않아서 "foo.bar()"에 대한 텍스트 검색을 원할 때가 있는데 이 스테밍 동작이 foo와 bar가 언급된 모든 곳을 찾아 결과를 부풀림.
Zoekt에 대한 그들의 손짓이 이해가 안 됨. 다른 옵션보다 "새로운 인프라 약속"이 아님. 서버와 인덱서는 단일 바이너리여서 이보다 더 간단할 수 없음. Elasticsearch보다 더 무서워할 이유가 없어 보임.
Oracle은 로드된 모든 PL/SQL 코드가 제시되는 USER/ALL/DBA_SOURCE 뷰를 가지고 있음. EnterpriseDB가 이를 Postgres 내부에 구현하는지, 확장으로 사용할 수 있는지 궁금함.
Github 검색이 훌륭하다고? 대부분의 경우 거의 쓸모없는 것 같고, 복제 + ripgrep이 훨씬 더 효율적이라고 생각함. 실제 검색보다는 UX가 끔찍한 게 문제인 것 같음.