텍스트용 중복 찾기

큰 팀에서 기술 문서화 작업을 한 경험이 있는 사람이라면 내용 중복 문제를 숙지하고 있을 것입니다. 최고의 도구와 연습을 활용하더라도 중복을 근본적으로 극복하는 것은 어렵습니다.

프로젝트가 커지면서 중복된 내용이 발생하기 시작합니다. 이는 많은 유사 제품이나 기능을 포함하는 큰 프로젝트에서 특히 그렇습니다.

한 번 정의:

<p>
    문제가 발생하면, 문제 해결 가이드를 참조하거나 지원센터에 연락하세요.
</p>

다른 곳에서 재사용:

<TroubleshootingNote/>

<p>
    문제가 발생하면, 문제 해결 가이드를 참조하거나 지원센터에 연락하세요.
</p>

<!-- 같은 뜻, 약간 다른 표현 -->
<p>
    문제가 발생한 경우, 문제 해결 가이드를 참조하거나 지원센터에 연락하세요.
</p>

중복에 반대하는 아이디어는 일반적으로 DRY 원칙으로 알려져 있습니다. 이 원칙은 주로 프로그래밍과 관련이 있지만, 문서화에서도 높게 평가받는 속성입니다.

프로젝트 소개

현대의 저작 도구들은 일반적으로 콘텐츠 재사용 기능을 제공하므로, 기술적 제약은 덜 걱정스럽습니다. 반면, 실제 문제는 중복을 발견하는 것에 있습니다. 재사용 가능한 덩어리로 무언가를 추출하기 전에 무엇을 추출해야 할지 알아야 합니다.

프로그래머라면, IDE는 중복된 코드를 강조하여 보여줄 것입니다:

불행하게도, 같은 기능을 문서화에 적용하는 것은 추상 구문 트리(AST)를 비교하는 데 의존하기 때문에 적합하지 않습니다. 이 방식은 텍스트와는 잘 맞지 않습니다.

나의 진행중인 프로젝트 중 하나는 문서화용 중복 찾기 도구를 구현하는 것입니다. 이 도구는 빠르게 비정확하거나 퍼지 매치를 찾을 수 있습니다. 예를 들어, 위의 나쁜 예같은 경우입니다.

이 글을 작성하는 시점에서 프로젝트는 진행중이지만, 이미 작동하는 프로토타입이 있습니다:

이 알고리즘은 내 MBP M1에서 약 6천개의 소스 파일로 구성된 프로젝트를 분석하는 데 30초 미만이 걸립니다. 그리고 나는 편집기에서 입력하자마자 중복을 즉시 강조하는 것을 개선하려고 계획하고 있습니다.

이 프로토타입은 이미 실제 프로젝트에서 많은 중복을 찾아내는 데 나와 동료들에게 도움이 되었습니다. 그래서 나는 결과와 앞으로의 개선에 대해 아주 열정적입니다.

다음 게시물에서, 나는 알고리즘을 단계별로 설명하고 성능을 평가하기 위해 벤치마크를 수행할 것입니다. 프로그래밍에 관심이 있다면 동시에 코딩을 해 볼 수 있습니다.

또는 진행상황을 계속 지켜보고 프로젝트가 완료되면 최종 제품을 사용해 볼 수도 있습니다. 완료되면, 이 기능은 나의 동료들이 만든 훌륭한 저작 도구인 Writerside에서 이용 가능할 것입니다.

나는 프로젝트 설명이 여러분에게 마음에 들고, 통과 과정이 유용하다고 생각할 것이라고 기대합니다.

다음 게시물에서 만나요!