TODO 주석이 의미가 있습니까? [닫은]

나는 상당히 큰 프로젝트를 진행 중이며 그것을 위해 일부 번역 작업을 수행했습니다. 번역되지 않은 많은 레이블이 있었고 코드를 파헤치는 동안이 작은 코드 조각을 발견했습니다.

//TODO translations

이것은 대부분의 개발자가 특정 코드 조각을 얻은 후 개발자가 할 때까지 이것을 보지 않을 것이라는 느낌을 얻었 기 때문에 자신과 다른 사람들 에게이 의견의 의미에 대해 생각하게했습니다. 그것을 유지하거나 새로운 기능을 추가합니다. 그래서 이것은 TODO오랫동안 잃어 버릴 것입니다.

이 의견을 작성하는 것이 합리적입니까, 아니면 개발자의 초점을 유지하는 화이트 보드 / 종이 / 다른 곳에 작성해야합니까?

내가 사용하는 경향이 // todo것들에 대한 의견 이 일이,하지만 나는 즉시 할 수 없습니다.

또한 내가 그들을 쫓아 다니는지 확인합니다-나는 그들을 검색하고 (Visual Studio에는 그러한 의견을 나열하는 멋진 기능이 있습니다) 작업 이 완료 되었는지 확인하십시오 .

그러나 당신이 말한 것처럼, 모든 사람들이 그들에 대해 부지런하지는 않으며 많은 의견과 마찬가지로 시간이 지남에 따라 부패하는 경향이 있습니다.

나는 이것이 개인적인 취향에 더 가깝다고 말하고 싶습니다.해야 할 일을 문서화하고 추적하는 한, 그것이 // todopostit 노트 또는 화이트 보드 에 있는지 여부는 중요 하지 않습니다. 조치).

최신 IDE는 TODO주석을 인식 하고 자체 패널 / 창 / 탭에서 볼 수 있으므로 이론적으로 손실되지 않습니다 (이클립스와 Visual Studio 모두 생각하고 있다는 것을 알고 있다고 생각합니다).

당신은 다음과 같은 추가 코멘트 단어를 구성 할 수 있습니다 FIXME, BEWARE또는 어떤 다른 당신은 사용자 정의 할. 그러나 프로젝트의 다른 개발자는 IDE를 동일한 방식으로 사용자 정의해야합니다.

TODO는 손실되지는 않았지만 응용 프로그램이 "현재"제대로 작동하는 데 필요하지 않은 내용과 관련이 있기 때문에 "이론적으로"작성했습니다. "현재"는 프로젝트의 유형 / 크기에 따라 5 분에서 5 년까지 연장 될 수 있습니다.

마지막으로, 제 생각에는 코드의 다른 곳에있는 것보다 "어디서 변경해야합니까?"라는 질문에 정확하게 대답하여 올바른 위치에 코드를 작성하는 것이 더 합리적입니다.

편집 : TODO의 날짜와 소유자를 포함하여 Wikipedia의 기사에 의견에 기록 된 것처럼 좋은 습관으로 간주됩니다.

적어도 나는 때때로 사용합니다. 중요한 점은 다음과 같은 일관된 태그를 사용하는 것 TODO또는 FIXME그들은 쉽게 간단한 텍스트 검색으로 찾을 수 있도록.

예를 들어, "quick 'n dirty"솔루션은 다음과 같이 라벨링하기 편리합니다.

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

코드가 수행해야 할 작업을 수행하고 아무도 불평하지 않으면 주석이 해를 끼치 지 않습니다. 코드를 아름답게 꾸밀 시간이 있다면 FIXME라벨 검색으로 쉽게 시작할 수 있습니다.

업계에서는 모든 사람이 // todo항목 을 볼 수있는 기회를 얻지 못하기 때문에 개발자는 할일 댓글 대신 JIRA (또는 기타) 항목을 작성하는 것이 좋습니다 . 그러나 때로는 대규모 프로젝트에서 다음과 같은 행을 따라 사용자 정의 속성이 정의됩니다.

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

그리고이 방법으로 방법을 꾸밀 수 있습니다 ...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

그리고 더 높은 업이 와서 자동으로 수확 할 수 있습니다. 간단한 // todo알림 으로 인해 과잉이 될 수 있지만 효과적입니다. 또한 .NET 플랫폼이 필요합니다.

TODO는 주석의 하위 양식 일뿐입니다. 작성자가 전달할 내용과 전달 방법을 잘 알고 있으면 주석이 유용합니다. 유머 감각은 또한 몇 년 후 유지 보수를 기쁘게하기 위해 소량으로 적용 할 수 있습니다.

작년에 내 코드 중 일부가 폐기되었다는 전화를 받았습니다. 나는 그것이 생산 중이었고 16 년 동안 유지 보수에서 살아 남았다는 사실에 깊은 인상을 받았습니다. 따라서 코드가 오래 지속될 수 있습니다. 의도, 향후 요구 사항 등에 대한 의견은 코드를 처음보고있는 몇 년 전부터 누군가를 돕는 데 큰 도움이 될 수 있습니다.

내 경험에 따라 다릅니다. 주요 요인은 팀이 이러한 "작은"의견에 대해 후속 조치를 취할 수 있도록 훈련되었는지 여부입니다. 그들이 그렇다면 그렇습니다. 그렇지 않은 경우 이러한 의견은 시간 낭비 일뿐 아니라 스토리 카드와 같은 다른 옵션을 살펴볼 수도 있습니다.

개인적으로 TODO 주석을 가끔 사용하지만 일반적으로 수명이 짧으며 보통 1, 2 또는 3과 같이 매우 적은 수의 주석이 있습니다. 나는 그것들을 다른 것보다 코드베이스에서 마커로 더 많이 사용합니다. 내가 그들을 돌보는 데 너무 오래 기다리면 내가해야 할 일이 무엇인지 잊어 버립니다.

내가 선호하는 것은 항상 이것들을 사용하지 않고 대신 적절한 스토리 카드 나 백 로그 또는 이와 유사한 것을 사용하는 것입니다. 하나의 작업에 하나의 메커니즘을 사용하십시오.

나는 과거에 그것들을 쓰곤했지만 보통 당신이 그것들을 따르지 않는 것을 발견했습니다.

따라서 이제는 내가 바쁘게 끝나고 난 직후에 작업하고 싶은 것을 표시하는 데만 사용합니다. 예를 들어, 새로운 함수를 구현하고 사용하는 함수에 작은 버그가 있음을 알 수 있습니다. 현재 작업에서 탈선을 피하기 위해이 문제를 해결하기 위해 FIXME를 만듭니다.

나를 돕기 위해 코드에 FIXME가 있으면 CI 빌드가 실패하도록 설정됩니다. :-)

즉시 해결할 수없는 잠재적 인 문제가 발견되면 티켓 / 버그 / 문제를여십시오. 그렇게하면 모든 버그처럼 우선 순위를 지정할 수 있습니다. 버그 DB에 문제가 있고 코드에 TODO와 같은 문제가있는 것보다 훨씬 낫습니다.

선택적으로 버그 ID :-)로 TODO를 넣을 수 있습니다.

나는 TODO의견이 어느 정도 의미가 있다고 생각 합니다. 당신이 (민첩하고 TDD 상점에서 공통으로) 반복적으로 작업하는 경우 특히, 당신이 인식 할 일이있을 것이다 있다 오래 전에 필요할 것하지만 어떤 그런 다음 거기에 바로 구현하기 위해 우회로를 만들고 싶어하지 않습니다.

추악한 것은 그러한 주석이 코드베이스에 남아있을 때입니다. 기능에 대해 적극적으로 작업하는 동안 기능을 그대로 두는 것이 좋지만 기능을 완성하는 데 가까워지면 기능을 제거하는 데 집중해야합니다. 실제로 올바른 작업 코드로 대체하는 작업을 수행하지 않으려면 적어도 관련 기능을 제외하십시오. 코드가 처음에 @JoonasPulakka의 예를 빌리려면

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

당신은 그것을 다음과 같이 바꿀 수 있습니다

ConnManager.getConnection(GetDatabaseName());

당분간 GetDatabaseName ()은 시작한 것과 동일한 문자열을 반환하는 스텁입니다. 이렇게하면 향후 확장 지점이 명확 해지며 데이터베이스 변경이 필요한 모든 위치에 변경 사항이 반영 될 것입니다. 데이터베이스 이름이 다소 일반적인 경우 유지 관리 성이 크게 향상 될 수 있습니다.

개인적으로, 나는 TODO의도가 동일하기는하지만, 내 자신의 키워드를 엄격하게 사용하지 않고 다시 사용합니다. 또한 코드를 체크인하기 전에 해당 키워드에 대한 전역 소스 코드 검색을 수행합니다.이 키워드는 일반적으로 코드의 어느 곳에도 표시되지 않도록 선택됩니다. 그것이 발견되면, 나는 무언가를 잊어 버렸다는 것을 알고 있습니다.

주석과 함께 프로그래머 이름 / 서명을 포함시키는 것에 관해서 는 소스 코드 버전 제어 시스템이 있다면 과도하다고 생각합니다 ( 그렇지 않습니까?). 이 경우 비난 기능은 누가 주석을 추가했는지 또는 누가 주석을 마지막으로 변경했는지 확인한 사람을 더 정확하게 알려줍니다. 예를 들어 Visual Studio에서는 소스 제어 기능 중 "주석"기능을 사용하여이를 쉽게 수행 할 수 있습니다.

언젠가 다른 사람이 그 코드에 올 때 다른 사람이 그것을 고칠 것이라는 아이디어로 TODO 또는 FIXME를 작성하면 귀찮게하지 않을 것입니다. 코드를 어지럽히고이 정보를 수집하는 IDE의보고 부분을 복잡하게 만듭니다.

유용하게 사용하려면 가까운 시일 내에 코드를 책갈피에 추가하여 적절한 마음 상태로 빠르게 돌아갈 수있는 방법을 제공해야합니다. 다시 말해, 코드에 최대한 빨리 제거하기 위해 코드에 배치합니다.

더 이상 살았던 것은 사실 버그 기반에 배치해야합니다.

우리의 삶에는 충분한 소음이 있습니다. 다른 곳에서 필요한 동안주의를 기울이는 새로운 물건을 만들지 마십시오.

내 2 센트

일반적으로 // TODO 주석을 작성하지는 않지만 모든 주석을 분리 된 파일로 유지합니다. 여전히 쉽게 관리 할 수있는 온라인 소프트웨어를 찾거나 쓸 수 없으므로 TODO 파일은 짧은 시간 후에 프로젝트를 열 때 지금해야 할 일을 잊어 버린 다음 TODO 파일을보고 작업을 수행하기 때문에 여전히 가장 유용합니다. . "filename.cpp 354 : Re bla this bla bla bla"이 있는데 파일에서 // TODO 주석을 검색하면 훨씬 유용합니다. 나는 게으른 때 // TODO 이전 버전을 수행했지만 소스 파일에서 오래된 // TODO를 제거하고 프로젝트가 제대로 작동 할 때 수정하지 않습니다. 모든 // TODO를 소스에서 별도의 장소로 옮기고 다른 작업과 함께 유지하여 작업의 우선 순위를 쉽게 지정할 것을 강력히 권장합니다. 다양한 파일과 다양한 프로젝트에서 모든 TODO를 얻었을 때 우선 순위는 정말 어려운 일입니다.

나는 큰 것이지만 혼자가 아니라고 생각합니다. 예를 들면 다음과 같습니다.

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

이 접근법은 아주 훌륭하게 작동합니다. 비록 당신이 일부 코드를 완성하도록 상기시키는 예외를 던지는 습관을 만드는 것이 실제로 가장 전문적인 접근 방식은 아니라고 말할 수 있습니다. 그러나 그것은 당신이 무언가를 완성했다고 생각하고 당신이하지 않았을 때 당신이 완성했다고 생각하는 경우에 저를 구했습니다.

작업 목록을 생성 할 수있는 다른 백만 개 이상의 방법에 비해 할일 주석의 큰 장점은 할일 주석이 코드와 함께 이동하여 분리 될 수 없다는 것입니다.

아마도 이와 같은 것들에 가장 적합한 장소는 코드가 아닌 이슈 트래커 일 것입니다.

모든 TODO 또는 FIXME를 공식 로그에 입력하는 것이 좋습니다. 그렇지 않은 경우 쉽게 검색 할 수 있으며 뛰어난 TODO 및 FIXME를 확인하기 위해 각 반복의 단계 여야합니다. 그런 다음 카탈로그를 작성하고 즉시 해결하도록 설정하거나 팀이 적절한 시간에 수정하도록 계획 할 수 있습니다.

마지막으로 일단 고정되면 제거해야합니다. 해결 후 체계적으로 제거하지 않으면 효과가 떨어집니다.

결론 : 문제를 전혀 기록하지 않는 것보다 낫지 만 실제로 유지해야합니다.

IntelliJ는 새로운 TODO가있는 코드를 커밋하려고 할 때 실제로 경고합니다. 따라서 TODO를 "이것은 실제로 커밋 할 때 발생해야합니다"라고 항상 해석 할 수 있습니다.

"TODO"를 귀하의 의견에 대한 의미 적 레이블로 생각할 때, 그것들이 의미가 있다고 생각합니다.

우리 회사의 코딩 표준에서, 책임있는 개발자의 이니셜이 TODO에 포함되어야한다고 지정합니다 ( 즉 , "SAA TODO :"를 입력합니다). 그렇지 않으면 미래의 일부 개발자가 처리 할 수 ​​있도록 TODO 메모와 함께 하위 표준 코드를 남기려는 유혹이 있기 때문에 이것이 적어도 관습으로 유용하다고 생각합니다.

유용하게도 많은 IDE는 이러한 주석을 작업 목록에 추가하도록 구성 할 수 있으므로 무기한을 잊어 버리지 않고 유사하게 처리 할 수 ​​있습니다.

더 불명료하지만 효과적인 방법은 아마도 프로그램 주석이 작성 될 때 여러분과 다른 사람들이 볼 수있는 방식으로 할일 주석을 컴파일러 메시지로 바꾸는 것입니다.

델파이에서 :

{$message 'todo: free this thing when you know its not going to blow up'}

내 경험상, TODO코드 조각을 사용할 수 없음을 나타내고 독자에게 코드를 사용 가능 하게 만드는 데 필요한 부분 (로컬 또는 다른 곳)을 알려주는 데 사용해야합니다.

TODO주석은 어떤 방식으로 수정하면 일부 코드가 더 좋을 것임을 나타내는 데 사용되어서는 안됩니다. 예를 들어 다시 작성하면 유지 관리가 용이 ​​한 더티 코드 나 아직 필요없는 추가 기능이 있습니다. 이러한 주석은 쌓이는 경향이 있으며 grep TODO결과가 쓸모없는 결과를 낳습니다.