풀 요청에서 TODO를 처리하는 방법은 무엇입니까?

풀 요청의 변경 사항을 검토 할 때 종종 "TODO"메모가 포함 된 주석을 우연히 발견 할 수 있습니다.

• 문제를 해결하는 데 사용되는 솔루션은 개선 될 수 있지만 훨씬 더 많은 시간 투자가 필요합니다. 저자는 더 빠른 솔루션을 선택했지만 더 나은 옵션을 사용할 수 있다고 언급했습니다.
• 기존 버그를 해결하기위한 임시 코드가 있으며 곧 수정해야합니다.

TODO일반적으로 코드베이스의 수명 동안 코드베이스에 머무르는 것을 알고 있다면 풀 요청으로 어떻게 대응해야합니까? 공손하게 피하도록 요청하거나 실제로 정당화되는 경우 나중에 PR 작성자가 나중에 그것을 따를 수 있도록하려면 어떻게해야합니까?

팀 / 부서 / 조직에서 "일반적으로 코드베이스의 수명 동안 코드베이스에 머무른다"고 말할 때 다음을 고려하십시오.

• 당신에 적어 국방부TODO , FIXME유사한 태그 피해야한다, 또는.
• SonarQube 와 같은 정적 코드 분석 도구를 사용 하여 빌드를 불안정하게 자동 표시하십시오.
• 이슈 트래커에 해당 티켓이있는 경우에만 임시로 허용하십시오. 그러면 코드가 다음과 같이 보일 수 있습니다TODO [ID-123] Description ...

내 의견 에서 언급했듯이 마지막 문장은 티켓이 썩지 않는 환경에서만 의미가 있습니다 (예 : 제로 버그 정책 을 따르는 경우 ).

개인적으로, 나는 생각 TODO의이 때로는 합리적인, 그러나 사람은 과도하게 사용하지합니다. Robert C. Martin의 "Clean Code : Handile Book of Agile Software Craftsmanship" (p. 59)에서 발췌 :

TODO프로그래머가해야한다고 생각하는 일이지만, 현재로서는 어떤 이유로 할 수 없습니다. 더 이상 사용되지 않는 기능을 삭제하거나 다른 사람이 문제를 보도록하는 것이 좋습니다. 다른 사람이 더 나은 이름을 생각하거나 계획된 이벤트에 따라 변경하도록 상기시켜 줄 것을 요청하는 것일 수 있습니다. 어쨌든 시스템에 잘못된 코드를 남겨 두는 것은 변명 TODO이 아닙니다 .

TODO는 그들 자신도 악하지 않습니다. 나는 한 층 이상 깊숙이 들어 가지 않고 항상 추적기 티켓 당 1 문제를 해결하는 데 큰 팬입니다.

나는 종종 TODO 또는 FIXME를 사용하여 문제를 해결하기 위해 돌아 왔거나 돌아 왔음을 스스로 상기시키는 방법으로 사용합니다.

예를 들어 add (a, b)를 호출하고 TODO를 추가하여 add 메소드를 리팩터링 할 수 있습니다. 지금 add 메소드로 작업하고 싶지 않지만 다시 돌아오고 싶습니다.

따라서 풀 요청에서 TODO 또는 FIXME가 표시됩니다. 예를 들어 FIXME를 사용하여 책임을지고 엉망이해서는 안되는 다른 코드 영역 개발자에게 경고합니다. 예를 들어 FIXME add는 음수를 사용할 수 없습니다.

보이지 않거나 무시되지 않는 문제를 해결하기 위해 TODO FIXME 및 DEGUG 행을 모두 나열하는 스크립트를 사용합니다. 커밋 메시지에 추가됩니다.

모두 TODO 인 400 라인 커밋 메시지를 무시하기는 어렵습니다. 따라서 사람들은 문제의 코드를 이미 만지거나 새 티켓을 만들고 문제 코드를 독립형으로 수정하여 문제를 해결합니다.

공평하게, 나는 또한 모든 프로젝트가 코드 정리 시간에 빌드되었는지 확인합니다. 예, 15 일에 시작할 수 있지만 15 일에서 30 일까지 코드 정리를 수행하고있었습니다. (이상하게 여겨지지만 제품을 관리 한 적이 있다면 사전에 낮은 가시성 작업을 시작하려고하면 절대 도달 할 수 없다는 것을 알고 있습니다. 다른 것이 우선 순위를 갖습니다.)

완벽하지 않은 끌어 오기 요청이있을 수 있습니다. 지금은 가용 시간에 "충분히 잘"할 수 있지만 완벽하지는 않은 작업을하고 있습니다. 따라서 풀 요청을 제출하고 TODO를 주석의 올바른 위치에 배치하고 동시에 "충분히"에서 "완벽"으로 변경하기위한 변경 요청을 추가합니다.

이 새로운 변경 요청은 우선 순위를 정할 수 있으며 우선 순위가 가장 높은 항목 일 때 처리됩니다. 그것이 지금 완벽해야한다고 결정되면 , 그것은 다음으로 전달 될 것입니다.

이제 당신의 질문 : "어떻게 그것을 피하기 위해 정중하게 요청할 수 있습니까, 아니면 정말로 정당화된다면, 나중에 PR의 저자가 나중에 그것을 따르도록 어떻게 할 수 있습니까?" 내가 설명 한대로, 그것은 다소 멍한 것 같습니다. 늦게 배송하는 것과 배송하기에 충분한 것을 선택할 수 있다면 귀하의 결정이 아닙니다. 원하는 경우 제품 관리자에게 문의 할 수 있습니다. 그리고 "PR의 저자가 그것을 따르도록해야한다"? 당신이 팀을 가지고 있다면, 당신이 당신의 시스템에 로그인되어 있는지 확인해야하고, 희망 팀은 충분히 기록 일들이 손실되지 않도록 구성되어 있습니다, 그리고 사람이 더 높은 우선 순위 항목이없는 경우, 결국 그것을 수정합니다. 팀 노력이라는 것을 기억하십시오.

프로젝트가 TODO주석 으로 소스 코드에서 보류중인 항목을 추적하는 경우 허용해야합니다.

TODO풀 요청에 주석 이 있다는 사실 이 버그가 있다는 사실 은 소스 코드에서 보류중인 항목을 추적하는 것이 좋지 않다는 것을 알려 주어야합니다. 그런 식으로 물건을 잃거나 무시하는 경향이 있습니다. "작업 포크"에 대한 풀 요청에 대해 이야기하고 있다면 상황이 다릅니다. "작업 포크"는 바로 진행중인 작업입니다. 그러나 이와 같은 포크에는 일반적으로 풀 요청이 필요하지 않습니다. 여기에 제안 된 "하우스 규칙"은 마스터 브랜치에 대한 풀 요청에 대한 것 입니다.

하우스 규칙 # 1 - 모든 커밋 마스터 이후, 테스트를위한 준비가되어 있어야 마스터가 어떤 체크인 후 매일 내장되어 있습니다. 이러한 커밋에는 필요한 추가 테스트도 포함되어야합니다.

TODO코드가 완료되지 않았거나 테스트가 완료되지 않았거나 코드가 테스트 할 준비가되지 않았기 때문에 주석이있는 경우 해당 코드는 풀 요청이 아닌 로컬 커밋에 속합니다. 준비되면 전화 해

하우스 규칙 # 2-공개 이슈에 관한 모든 정보는 이슈 트래커에 저장됩니다. 그것의 모든. 메모, 낙서, 멍청이 등.

는 IF TODO코멘트 개방 문제에 관한, 그리고 그 문제에 대한 실제 수정하지, 그 정보는 이슈 트래커에 속한다. 이렇게하면 문제가 종결되기 전에 필요한 경우 문제가 실제로 해결되도록 모든 정보를 검토하고 확인할 수 있습니다.

하우스 규칙 # 3-보류중인 프로젝트 작업에 관한 모든 정보는 우선 순위 대기열 (또는 시스템 이름)에 속합니다.

명확히하기 위해 보류중인 프로젝트 작업은 이슈 티켓을 생성하기 전에 발견 된 결함인지, 특정 설계 요구 사항의 구현인지 또는 특정 디자인 요구 사항 중 하나인지 여부에 관계없이 우선 순위가 설정된 프로젝트에서 수행해야하는 작업입니다. 그 요구 사항의 필수 구성 요소.

TODO새로운 코드가 보류중인 작업에 영향을 미치거나 새로운 코드를 구현할 때 발견해야 할 코드베이스의 다른 것을 지적 하려는 의견이 있으면 해당 정보가 우선 순위 대기열에 속합니다. 기존 작업 또는 새 작업

하우스 규칙 # 4-제안은 아이디어 상자 (또는 기타)에 속합니다.

TODO의견이 소프트웨어의 설계 또는 구현에 대한 변경을 제안하는 경우 해당 정보는 프로젝트의 아이디어 상자 또는 "vNext"또는 "디자인 노트"또는 해당 종류의 모든 것에 속합니다.

하우스 규칙 # 5- TODO주석은 소스 코드에서 허용되지 않습니다. 기간.

이 규칙을 고수하면 다른 사람에 대해 걱정할 필요가 없습니다.