오래된 주석은 도시 신화입니까?

나는 사람들이 "의견이 구식이되는 경향이있다"고 주장하는 것을 끊임없이 본다. 문제는 내 경력 전체에 2 ~ 3 개의 오래된 의견이있는 것 같습니다. 별도의 문서에있는 오래된 정보는 항상 발생하지만 내 경험상 코드 자체의 오래된 주석은 매우 드 exceed니다.

내가 함께 일하는 사람이 방금 운이 좋았습니까? 특정 산업이 다른 산업보다이 문제에 더 취약합니까? 당신은이 있는가 특정 사용자가 본 적이 최근 오래된 코멘트의 예를? 아니면 오래된 주석이 실제 문제보다 이론적 인 문제에 더 가깝습니까?

지속적으로

나는 구식이며 오해의 소지가있는 유일한 수영 자라고 믿을 수 없습니다. 오프 기회에 이것은 이해하는 데 도움이됩니다.

아마도 코드의 나이에 따라 가장 중요합니다. 다음 요소는 직원의 이직률입니다.

나는 동등한 부품 R & D 및 유지 보수 작업을합니다. R & D는 새로운 코드이며 일반적으로 구타를 조금 벗어난 것입니다. 많은 동료들이 이미 라이브러리가없는 것을 시도 할 때 많은 설명을 믿습니다. 주석 대 코드 비율이 평소보다 높기 때문에 상황이 동기화되지 않을 가능성이 더 많습니다.

유지 보수 코드 ... 나는 10 세 이상이고 5 세 이상인 시스템에서 활발한 유지 관리 자입니다 .10 세 코드와 의견은 예상대로 끔찍합니다. 10 년 동안 코드베이스에 많은 도움을 받았고 더 이상 모든 것이 어떻게 작동하는지 아무도 모릅니다. 5 년 된 코드와 의견은 팀의 이직률이 매우 낮기 때문에 꽤 좋습니다.

저는 거의 모든 서비스를 제공합니다. 심지어 우리 제품은 특정 고객에 맞게 조정되어 있습니다.

구체적인 예 :

• 메모리 내 복사본 방지와 같은 특정 방법론의 성능 향상을 설명하는 주석. Pentium 2의 최고급 시스템이 MB의 RAM을 가지고 있지만 지금은 거의 문제가되지 않습니다.

• 할 일

• 주석을 포함하여 복사하여 붙여 넣은 코드 블록. 의견은 원래 위치에서 의미가 있었지만 여기서는 거의 의미가 없습니다.

• 주석 처리 된 코드 위에 주석 블록 (누가 몇 년 동안 있었는지 아는 사람).

이 모든 것에서는 주석과 코드를 소프트웨어와 동일한 수준으로 유지하지 않는 경향이 있습니다. IDE와 기본 개발자 습관은 이것으로 도움이되지 않습니다. 제 눈은 그것들을 지나치도록 훈련되었습니다. 필자는 구식이며 활동적인 프로젝트에서 구식을 피하는 것이 상대적으로 저렴하다고 생각합니다. 코드 / 코멘트 비율을 높게 유지할 수 있다면 최신 상태로 유지하는 것이 그리 중요하지 않습니다. 프로덕션 시스템에서 버그 수정을 위해 x 시간의 예산을 책정 할 때 이러한 것들을 사냥하는 것을 정당화하는 것이 조금 더 어렵습니다.

"의견은 구식이되는 경향이 있습니다."

나는 이것이 문제가 될 수 있음을 알기에 충분히 일어나는 것을 보았다.

문제는 내 경력 전체에 2 ~ 3 개의 오래된 의견이있는 것 같습니다.

모든 사람이 의견을 충분히 처리하고 유지하는 환경에서 일하는 것이 완벽하게 가능해야한다고 생각합니다. 편집중인 코드 근처의 주석을보고 적절한 경우 주석을 업데이트하는 것이 약간의 추가 노력 일뿐입니다. 주석이 너무 멀리 떨어져있어 즉시 눈에 띄지 않는 경우 어쨌든 나쁜 주석이므로 처음에는 추가해서는 안됩니다 (적어도 존재하지 않음).

또한 일반적으로 의견이 구식이된다는 진술과 함께, 가독성을 줄이고 사람들을 혼란스럽게한다는 진술을 따릅니다. 이것은 내가 아직 경험하지 않은 것입니다. 오래된 주석이 발생할 때마다 변경 사항을 명확하게 확인하고 추가 노력이 필요하지만 최신 코드를 나타내도록 주석을 업데이트합니다.

Roehm 등 의 최근 연구 . 2012 년 은 다음을 관찰합니다.

21 명의 참가자 (28 명 중)는 소스 코드 와 인라인 주석 으로부터 주요 정보를 얻는다고보고 한 반면, 4 명만이 문서가 주요 정보 출처라고 답했습니다.

이것은 일반적으로 코드 자체의 주석이 여전히 매우 유용하다고 여겨지는 의심과 일치합니다. 이것은 오래된 문서와 오래된 주석 사이에 명확한 선이 그려 져야 함을 나타냅니다 .

_{Roehm, T., Tiarks, R., Koschke, R. 및 Maalej, W. (2012, June). 전문 개발자는 소프트웨어를 어떻게 이해합니까? 2012 년 국제 소프트웨어 공학 회의 (pp. 255-265) 진행. IEEE 프레스.}

오래된 의견은 직업 냄새입니다. 구식이거나 방치 된 단위 테스트를하는 것과 같습니다. 상점에서 한 번 활성화 된 좋은 프로세스가 카우보이 코드로 변하고 있음을 보여줍니다. 일을 제대로하기 위해 시간을내는 적절한 "엔지니어링 문화"가 무너졌습니다. 프로젝트 / 회사가 기술 부채에 빠질 수 있습니다.

요컨대, 당신은 운이 좋았습니다. 당신이 당신의 경력에서 지금까지 합리적으로 잘 운영되는 상점을 가지고 있다면, 이것을 많이 보지 못할 수도 있습니다. 그러나 덜 일반적이고 덜 운영되는 상점에서는 다른 혼란과 평행을 이룹니다.

주석은 테스트와 비슷하지만 최신 상태 일 때는 매우 좋지만 코드가없는 경우 코드를 이해하기가 더 어려워 질 수 있습니다.

오래된 코멘트를 본 적이 없다면 매우 운이 좋았습니다.

내가 작업 한 대부분의 코드베이스는 오래된 주석으로 가득 차 있었고 일반적으로 주석 대신 혼란의 원인이되므로 주석을 완전히 무시합니다.

오래된 주석은 종종 JavaDoc에 나타납니다.

• 더 이상 존재하지 않는 인수 나열
• 모든 주장을 설명하지는 않음
• 예외 등의 유사한 사항

또한 대부분의 성능 고려 사항이 코드 자체보다 더 빨리 부실 해지는 경향이있는 경우 "댓글을 작성하려면 여기에 수행"과 같은 내용이 언급됩니다.

나는 때때로 오래된 주석을 처리합니다. 확실히 도시 신화가 아닙니다. 사람들은 최악의 관행 목록에서 그것을 자주 언급하기 때문에가 아니라 그렇게 할 때 일반적으로 많은 시간과 노력이 들기 때문에 언급합니다.

우리의 코드베이스에서 가장 오래된 주석은 메서드 선언 근처가 아니라 호출 근처에서 메서드 동작을 설명하는 (반) 패턴을 사용하여 발생합니다. 누군가가 한 번에 한 번만 호출되는 메소드로 긴 코드 조각을 추출한 다음 메소드 호출에 주석을 달 때 발생합니다. 따라서 다음과 같은 결과가 나타납니다.

featureList = GetFeatures();

// Sorting features and deleting empty ones from the list...
ProcessFeatures(featureList);

그리고 방법은 주석없이 아래 어딘가에 선언됩니다. 사람들은 몇 년 동안 사양 변경 및 버그 수정을 처리하면서 이러한 방법을 혼란스럽게 생각하며 결국 목록을 정렬하지 않고 빈 기능을 찾으면 예외를 던지는 방법으로 끝납니다. 따라서 위의 주석은 오래된 주석이므로 결국 디버거에서 시간이 걸립니다. 이것은 일부 코드베이스에서 발생합니다.

스스로에게 물어보십시오. 코드 줄을 변경하고 관련 주석을 변경하거나 새로운 주석을 추가하지 않은 적이 있습니까?

나는 많은 레거시 코드로 작업했으며 주석은 때로는 관련성이 거의 없습니다.

대부분의 경우 내 경험은 귀하의 경험과 일치하지만 코드베이스 전체에서 사실이었던 한 가지 사례를 실행했습니다. 그것은 더 이상 클라이언트와 "좋은 조건"에 있지 않은 컨설팅 상점에 의해 몇 년 전에 작성된 앱이었습니다.

이 회사는 코드에 대해 언급하면서 예외적 인 작업을 수행했지만 원래 핸드 오프 이후로 코드를 유지 한 프로그래머는 "절대적으로 변경해야 할 사항 만 변경"사고 방식의 일부였으며 그 자체로는 나쁘지 않았습니다. 불행히도, 그들은 주석에 대해서도 같은 태도를 유지하여 시간이 지남에 따라 주석과 코드가 상당히 분리되었습니다.

설명적인 주석이 너무 오래되지는 않지만 몇 년 동안 TODO 주석이 많이 있습니다. 나는 그들이 타임 캡슐과 같으면 좋았고 다음과 같이 말했습니다.

//TODO: In 15 years AND NO SOONER... actually implement this method.

내가 작업 한 마지막 3 개의 프로젝트는 코드베이스에서 오래되고 오해의 소지가 있으며 쓸모없는 주석을 제거하는 데 며칠을 보냈습니다. 가능하고 필요한 곳에서는 더 적절한 주석으로 대체하지만, 종종 주석을 삭제하고 계속 진행하는 문제가 아닙니다.

나는 다른 사람들로부터 인수 한 거의 모든 코드베이스에 대해 거의 동일한 작업을 수행했습니다. 보통 오랫동안 유지되지 않았고 원래 소유자는 오랫동안 이동하지 않았거나 적절한 핸드 오버를 할 수 없거나 의지 할 수 없었습니다.

주석 사용이 줄어들 수 있습니다. 자격을 갖춘 사람의 코드는 얼마입니까? 예를 들어 누군가가 실제로 구식이 되려면 주석을 포함시켜야합니다. 둘째, 주석 처리 된 코드를 변경해야합니다. 높은 백분율의 코드가 적합한 지 확실하지 않습니다.

많은 응용 프로그램을 망치고 많은 시간을 낭비하기 위해서는 하나의 나쁜 의견에 의존해야합니다.

많은 코드를 생성하는 조직에서는 주석을 동기화하기가 어렵습니다. 무슨 일이 일어나고 있는지 이해하는 가장 좋은 방법은 작업중인 모듈의 제어 흐름도를 그리는 소프트웨어를 사용하는 것입니다. 이것이 소프트웨어가하는 일을 계속 느끼게하는 유일한 방법입니다.