소프트웨어 엔지니어로서, 너는 네 가지 방식으로 너의 처리해야 할 사항을 조직할 수 있다

TODO는 개발자에게 까다로운 화제다.많은 코드 라이브러리는 누가 TODO에 대해 책임을 져야 하는지, 심지어는 TODO를 처리하는 데 필요한 상하문을 아는 사람이 없는 상황에서 TODO가 여전히 존재한다는 죄책감을 가지고 있다.그러나 우리가 휘두르지 못하는 임무를 부끄러워해야 하는가?
많은 개발자들이 프로젝트 코드에 TODO를 추가하는 방법을 채택했다.그러나 이것이 반드시 그들을 관리하는 최선의 방법은 아니다.TODO를 집중된 인터페이스로 추출하는 것이 합리적입니다. 이 인터페이스는 TODO를 주동적으로 관리하고 상하문, 기능 설명, 수요, 심지어 관련 코드 세션까지 메타데이터를 추가할 수 있습니다.

이 문서에서는 TODO와 관련된 다음 사항에 대해 설명합니다.

소프트웨어 엔지니어가 TODO를 사용하는 이유는 무엇입니까?

코드 라이브러리에 TODO를 추가하는 데 문제가 있습니까?

TODO 관리를 위한 모범 사례는 무엇입니까?

대기 사항을 관리하는 가장 좋은 방법은 무엇입니까?

개발자가 TODO

를 사용하는 이유
소프트웨어 엔지니어가 프로젝트에서 TODO를 사용하는 이유는 다음과 같습니다.

알림: 만약 당신이 새로운 기능을 개발하고 있다면 refactoring가 필요한 코드를 만났을 것입니다.그러나 재구성은 새로운 특성에 직접적인 영향을 미치지 않기 때문에 자신을 일깨워 줄 수 있다.이것은 아주 좋은 예로 다음 작은 동작을 신속하게 기록할 수 있으며, 이후의 시간에 집행해야 한다.한편, 개발자들은 JIRA나 Asana 등 프로젝트 관리 도구에서 새로운 문제나 임무를 만드는 비용이 너무 많다고 생각한다.

TODO 대체 프로젝트 관리 도구: 나도 이런 실수를 한 적이 있다.나는 작은 프로젝트를 위해 프로젝트 위원회를 설립하는 것을 피하고 싶다. 왜냐하면 이것은 시간을 낭비하는 것 같기 때문이다.그래서 많은 개발자들이 프로젝트 코드에 몇 십 개의 TODO를 추가하여 프로젝트 관리 도구에 대한 수요를 대체했다.

인출 요청이 적음을 유지한다. 일부 개발자들은 작은 인출 요청을 더 좋아한다. 왜냐하면 심사하기 쉽기 때문이다.따라서 단일 작업을 처리하기 위해 여러 개의 작은 PRs를 작성합니다.이 임무의 일부로서 수행해야 할 작업을 추적하기 위해 그들은 PRs에 TODO를 포함하여 자신이 아직 완성하지 못한 일을 일깨워 준다.

힌트: 개발자는 TODO를 다음 개발자가 같은 코드를 처리하는 힌트로 자주 남용한다.TODO는 새 프로젝트를 막 시작했을 때 코드나 가능한 코드 확장을 계속하는 방법을 설명할 수 있습니다.

IDE 지원: 많은 IDE는 코드 라이브러리에서 TODO를 강조 표시하고 검색하는 기능을 사용합니다.개발자가 항상 TODO를 추가하는 것이 가장 좋은 방법입니다.예를 들어 Visual Studio Code 가장 유행하는 TODO 관리 확장은“Todo Tree”인데 설치량이 110만 회를 넘는다.

(출처: Todo Tree extension Visual Studio 코드)

코드 라이브러리에 TODO를 추가하는 데 문제가 있습니까?

TODO의 가장 중요한 문제는 컨텍스트가 부족하다는 것입니다.개발자는 일반적으로 짧은 TODO를 작성하지만, 이러한 TODO는 그것들을 해결하기 위해 많은 상하문을 제공하지 않는다.따라서 TODO는 코드 라이브러리에 대한 지식이 풍부한 소수의 사람들만 해결할 수 있다.심지어 TODO를 작성한 엔지니어만 무슨 일이 일어날지 알 수도 있다.
또한, TODO를 작성한 사람 외에는 명확한 소유자가 없습니다.다른 사람의 코드를 처리할 때 TODO를 만났을 때 TODO를 삭제하시겠습니까 아니면 해결하시겠습니까?이것은 대답하기 매우 어려운 문제다.나는 대학에서 토도스를 개인 메모지로 삼아 내가 그것을 건드리는 것을 허락하지 않았던 것을 기억한다.
이제 토도에게 무슨 일이 일어날지 생각해 보자.TODO가 마스터/마스터 브랜치에서 처리되지 않는 빈도는 얼마나 됩니까?프로젝트 코드에 TODO를 병합한 지 몇 달이 지나도 해결되지 않았습니다.소유권과 배경이 부족하기 때문이다.
마지막으로 TODO는 곧 만료됩니다.특히 대형 개발팀에서는 코드의 변화가 매우 빠르다.즉, TODO가 더 이상 유효하지 않습니다.마찬가지로 배경이 부족하기 때문에 아무도 감히 그것들을 삭제하지 못한다.이 문제를 해결하기 위해 일부 회사는 서로 다른 project management and technical debt 도구를 사용하여 마감일을 설정하고 상하문을 추가합니다.

어떻게 해야 할 일을 정확하게 관리합니까?

이러한 지침은 TODO를 관리하는 정확한 규칙 매뉴얼이 아니다. 왜냐하면 팀의 선호도, 규모와 관리 스타일에 달려 있기 때문이다.따라서 팀의 업무를 더욱 잘 관리하는 데 도움을 줄 수 있는 네 가지 팁이 열거되어 있습니다.

1. 사소한 문제에서 TODO 사용

소프트웨어 엔지니어는 모든 팀 멤버가 빠르게 처리할 수 있는 미세 임무를 정의하기 위해 TODO만 사용해야 한다.예를 들어, 모듈의 이름을 보다 설명적인 이름으로 변경하도록 개발자에게 알리는 TODO를 추가할 수 있습니다.이것은 프로젝트 관리 도구에 단독으로 기록해야 하는 임무가 아니다.
더 큰 문제나 임무는 프로젝트 관리 도구를 사용해야 한다.이것은 문제의 규격을 정의하고 development sprint의 일부분으로 기획할 수 있도록 합니다.

2. 충분한 컨텍스트 추가

코드 라이브러리에만 TODO를 추가하는 것이 코드 문제를 일으키는 가장 좋은 방법은 아니다.문제를 정리하고 배경을 추가하는 방법을 찾고 있다면 Stepsize해 보세요.엔지니어가 플랫폼에 TODO를 가져와 구성하고 코드 링크, 의존 항목, 작업 시간 손실 등 상하문을 추가할 수 있도록 한다.

3. 일관된 업무 양식 사용

TODO의 일관된 형식을 통해 보다 효과적으로 관리할 수 있습니다.예를 들어, 만료일과 소유자를 정의하는 형식을 선택할 수 있습니다.

@TODO <due date> <owner> <task details>

또는 코드 세그먼트나 관련 파일에 대한 인용 등 더 많은 속성을 정의할 수 있습니다.

@TODO <due date> <owner> <task details> <link 1> <link 2>

만약 일치된 포맷이 있다면, 정의된 포맷에 부합되는 코드 심사 기간에 TODO를 받아들이는 것이 훨씬 쉽다.그것은 당신의 팀이 당신의 프로젝트에서 애매모호한 임무를 수행하는 것을 방지할 수 있다.이 외에도 고정 형식을 사용하면 코드 라이브러리에서 TODO를 빠르게 검색할 수 있습니다.

4. 처리해야 할 사항의 규칙 정의

당신의 팀과 함께 앉아서 처리해야 할 사항에 대해 규칙을 정하세요.예를 들어, TODO를 사용할 수 있는 작업 유형을 정의합니다.이 점을 분명히 함으로써 프로젝트 관리 도구의 도움을 필요로 하는 임무가 아니라 미세한 임무를 더욱 쉽게 식별할 수 있다.

뭐가 제일 좋아요?

코드 라이브러리에서 TODO를 관리하는 것을 별로 좋아하지 않는다는 의견을 덧붙입니다.그러나 이런 전략은 정확한 규칙 집합을 가진 소규모 단체에 적용될 수 있다.상하문을 제공하고 명확한 소유자를 정하는 것을 잊지 마라.
이 게시물은 미첼 무데스가 쓴 것이다.Michiel은 기술 콘텐츠 작성을 좋아하는 열정적인 블록체인 개발자입니다.이외에도 마케팅, 사용자 체험 심리학, 창업 정신을 배우는 것을 좋아한다.그가 글을 쓰지 않을 때, 그는 아마도 벨기에 맥주를 즐기고 있을 것이다.
Managing Technical Debt에 발표되었다.