"주석 처리 된"코드 체크인 [닫힘]

좋아, 여기 내 현재 직장에서 약간의 마찰을 일으킨 무언가가 있는데 나는 정말로 그것을 기대하지 않았습니다. 사내 소프트웨어 개발은 ​​여기에서 새로운 개념이며 코딩 지침의 초안을 작성했습니다.

나는 "주석 처리 된"코드를 절대 저장소에 체크인하지 말라고 제안했습니다. 내가 이것을 언급 한 이유는 저장소가 파일의 전체 기록을 유지하기 때문입니다. 기능 코드를 제거하는 경우 모두 제거하십시오. 저장소는 변경 사항을 유지하므로 변경 사항을 쉽게 확인할 수 있습니다.

이로 인해 다른 개발자가이 경로를 취하는 것이 너무 제한적이라고 생각하는 데 약간의 마찰이 발생했습니다. 이 개발자는 작업 중이지만 불완전한 일부 코드를 주석 처리 할 수 ​​있기를 원합니다. 이 코드는 이전에 체크인 한 적이없고 어디에도 저장되지 않았을 것입니다. 우리는 TFS를 사용할 것이므로 변경 사항을 보류하는 것이 가장 올바른 해결책이라고 제안했습니다. 그러나 배포 될 수도 있고 배포되지 않을 수도있는 부분적인 변경 사항을 체크인 할 수 있기를 원했기 때문에 수락되지 않았습니다.

우리는 지속적 통합을 최대한 활용하고 개발 웹 서버에 자동으로 배포하는 시점에 도달하고자합니다. 현재 웹 서버 또는 데이터베이스 서버의 개발 버전은 없지만 곧 변경 될 예정입니다.

어쨌든, 당신의 생각은 무엇입니까? "주석 처리 된"코드가 저장소에 있으면 유용하다고 생각하십니까?

이 주제에 대해 다른 사람들의 의견을 듣고 싶습니다.

편집 : 명확성을 위해 우리는 비공개 브랜치를 사용하지 않습니다. 그렇게했다면 개인 브랜치에서 원하는 작업을 수행하라고 말하고 주석 처리 된 코드를 트렁크 또는 공유 브랜치와 병합하지 마십시오.

편집 : 개인용 또는 사용자 별 분기를 사용하지 않는 유효한 이유가 없습니다. 내가 동의하지 않는 개념이 아닙니다. 우리는 아직 그렇게 설정하지 않았습니다. 아마도 그것이 궁극적 인 중간 지점 일 것입니다. 지금은 TFS 선반을 사용합니다.

다른 경험을 가진 다른 사람들이있을 수 있지만, 반쯤 완성 된 코드를 확인하는 것은 끔찍한 생각입니다.

내가 배웠고 따르려고 노력하는 원칙은 다음과 같습니다.

• 자주 체크인하십시오-최소 한 번, 가능하면 하루에 여러 번
• 완전한 기능 만 체크인
• 첫 번째와 두 번째 충돌이 발생하면 (예 : 기능이 작동하는 데 하루 이상 소요됨) 작업이 너무 큽니다. 완료 가능한 작은 작업으로 나누십시오.

이것은 다음을 의미합니다.

• 주석 처리 된 코드는 작동하지 않으므로 체크인해서는 안됩니다.
• 주석 달기는 유효한 보관 전략이 아니므로 아직 완성되지 않은 코드이든 폐기되는 코드이든 주석 달기와 체크인은 의미가 없습니다.

요약하자면 아니요! 코드가 다음 단계로 이동할 준비가되지 않은 경우 (IntTest / QA / UAT / PreProd / Prod) 트렁크 또는 다중 개발자 브랜치에 커밋해서는 안됩니다. 기간.

편집 : 다른 답변과 주석을 읽은 후 주석이 달린 코드 를 금지 하는 것이 반드시 좋은 생각이라고 생각하지 않는다고 덧붙일 것입니다 (어쨌든 그것을 어떻게 시행할지 확실하지 않습니다). 제가 말하고자하는 것은 팀원 모두가 위에서 설명한 철학을 받아들이도록해야한다는 것입니다. 내가 일하는 팀은 진심으로 그것을 포용합니다. 결과적으로 소스 제어는 우리가 작업을 완료하는 데 도움이되는 완벽한 팀 구성원입니다.

이 철학을 받아들이지 않는 사람들은 대개 창을 깨뜨리고 소스 제어에 좌절감을 느낍니다. 그들은 그것을 기껏해야 필요한 악으로, 최악의 경우에는 피해야한다고 생각합니다. 이는 드물게 체크 인을 발생시킵니다. 이는 변경 세트가 거대하고 병합하기 어렵다는 것을 의미하며, 이는 좌절감을 더하고, 체크 인이 더 많은 것을 피할 수있게 만드는 등을 의미합니다. 이것은 궁극적으로 프로세스가 아니라 태도 문제입니다. 그것에 대해 정신적 장벽을 세우는 것은 쉽습니다. 당신이 정말로 원하지 않는 경우 다이어트하지 않는 이유를 찾는 것이 쉬운 것처럼 그것이 작동하지 않는 이유를 찾는 것은 쉽습니다. 그러나 사람들 이 그것을 원하고 습관을 바꾸는 데 전념 할 때 결과는 극적입니다. 이를 효과적으로 판매하는 것은 당신의 부담입니다.

"Never"는 가이드 라인에서 사용하기에 좋은 단어가 아닙니다.

동료는 주석 처리 된 코드를 체크인하는 것이 적절한 경우에 대한 훌륭한 예를 가지고 있습니다. 코드가 불완전하고 활성 상태에서 체크인하면 애플리케이션이 중단 될 수 있습니다.

대부분의 경우 잘 관리 된 변경 제어 시스템에서는 죽은 코드를 주석 처리 할 필요가 없습니다. 그러나 주석 처리 된 모든 코드가 "죽은"것은 아닙니다.

주석 처리 된 코드는 절대로 기록을 유지하기 위해 체크인 . 이것이 소스 제어의 요점입니다.

사람들은 여기서 많은 이상을 이야기하고 있습니다. 아마도 다른 사람들과는 달리 "실제 세계"가 가끔 내 업무를 방해하는 상황에서 여러 번의 중단이있는 여러 프로젝트를 수행해야합니다.

때때로 현실은 부분적으로 완전한 코드를 체크인해야한다는 것입니다. 코드를 잃어 버리거나 불완전한 코드를 체크인 할 위험이 있습니다. 아무리 작더라도 항상 작업을 "완료"할 여유가 없습니다. 그러나 모든 코드를 확인하지 않고 네트워크에서 랩톱을 분리 하지 않습니다 .

필요한 경우 부분 변경 사항을 적용하기 위해 자체 작업 분기를 생성합니다.

주석 처리 된 코드를 남기는 한 가지 경우 :

// This approach doesn't work
// Blah, blah, blah

이것이 문제에 대한 명백한 접근 방식이지만 미묘한 결함이 포함되어있을 때. 물론, 리포지토리는 그것을 가지고있을 것이지만 리포지토리는 미래에 누구에게도 그 길로 가지 말라고 경고하지 않을 것입니다.

주석 처리 된 코드를 확인하는 것은 절대 권장하지 않습니다. 그러나 나는 그것을 절대적으로 금지하지 않을 것입니다. 때때로 (드물지만) 주석 처리 된 코드를 소스 제어로 확인하는 것이 적절합니다. "절대하지 마"라고 말하는 것은 너무 제한적입니다.

나는 우리 모두가 다음과 같은 점에 동의한다고 생각합니다.

• 소스 제어에 데드 코드를 확인하지 마십시오.
• 소스 제어에 깨진하지 체크 마십시오 (비 작동) 코드, 적어도 결코 트렁크와 매우 드물게 사설, YMMV에
• 디버깅 목적으로 일시적으로 주석을 달거나 무언가를 깨뜨린 경우 코드를 올바른 형식으로 복원 할 때까지 코드를 체크인하지 마십시오.

일부는 일시적으로 제거 된 코드, 다음에 올 내용에 대한 문서로 주석 처리 된 소량의 코드를 포함하는 점진적이지만 불완전한 개선 또는 매우 짧은 (이상적으로는 한 줄) 주석 코드 와 같은 다른 범주가 있다고 말합니다. 절대 안되는 것을 보여주는 코드 다시 추가 할 수 없습니다입니다. 주석 처리 된 코드는 삭제 된 것이 아니라 주석 처리 된 이유를 설명하고 주석 처리 된 코드의 예상 수명을 제공하는 주석이 항상 함께 제공되어야합니다. 예를 들어, "다음 코드는 좋은 것보다 해를 끼치기 때문에 주석 처리되었지만 XXX 릴리스 전에 교체해야합니다."

위와 같은 설명은 고객의 출혈을 막기 위해 핫픽스를 제공하고 있으며 궁극적 인 해결책을 찾을 수있는 즉각적인 기회가없는 경우에 적합합니다. 핫픽스를 제공 한 후 주석 처리 된 코드는 여전히 수정해야 할 사항이 있음을 상기시켜줍니다.

주석 처리 된 코드는 언제 체크인합니까? 한 가지 예는 가까운 장래에 어떤 형태로든 다시 추가해야 할 가능성이 높은 것을 잠정적으로 제거하는 경우입니다. 주석 처리 된 코드는 이것이 불완전 함을 직접 상기시키는 역할을합니다. 물론 이전 버전은 소스 제어에 있으며 FIXME 주석을 더 많은 것이 필요하다는 플래그로 사용할 수 있습니다 . 그러나 때로는 (자주는 아니지만) 코드가 더 나은 주석입니다.

버그가 하나 개의 라인을 제거하지 (또는 드물게, 두 줄) 코드에 의해 고정 될 때 또한, 나는 때로는 주석이 줄을 주석 것이다 결코 이유와 그 코드를 다시 사용할 수 없습니다. 이러한 종류의 설명은 명확하고 직접적이며 간결합니다.

Rex M은 다음과 같이 말했습니다. 1) 완전한 기능 만 확인하십시오. 2) [If] 작업이 너무 큽니다. 완료 가능한 작은 작업으로 나누십시오.

응답 : 네, 이것이 이상적입니다. 프로덕션 코드에서 작업 할 때 즉시 해결해야 할 중요한 문제가있을 때 두 옵션 모두 달성 할 수없는 경우가 있습니다. 때로는 작업을 완료하기 위해 잠시 동안 필드에 코드 버전을 입력해야합니다. 이것은 문제의 근본 원인을 찾으려고 할 때 데이터 수집 코드 변경에 특히 해당됩니다.

더 일반적인 질문에서 질문을받는 특정 인스턴스에 대해 ... 개발자가 주석 처리 된 코드를 아무도 볼 수없는 비공개 브랜치로 확인하는 한, 그 개발자 (그리고 아마도 개발자가 공동 작업하는 사람), 해가 거의 없습니다. 그러나 해당 개발자는 그러한 코드를 트렁크 또는 이와 동등한 코드로 전달해서는 안됩니다. 트렁크는 항상 구축되어야하며 항상 작동해야합니다. 미완성 코드를 트렁크에 전달하는 것은 거의 항상 매우 나쁜 생각입니다. 개발자가 완료되지 않은 코드 또는 임시 코드를 비공개 브랜치로 확인하도록 허용하는 경우 트렁크로 전달하기 전에 코드를 스크럽하는 것을 잊지 않도록 개발자에게 의존해야합니다.

다른 답변에 대한 의견에 대한 응답으로 코드를 주석 처리하고 체크인하면 코드가 주석 처리 된 시간과 함께 주석 처리되지 않은 경우 코드가 작동 할 것으로 기대합니다. 분명히, 리팩토링 도구는 리팩토링에 항상 주석을 포함하지 않습니다. 거의 항상 주석 처리 된 코드를 프로덕션에 넣으면 코드는 산문보다 더 구체적인 주석 역할을하기 위해 거기에서 뭔가를 수행해야합니다. 긴 수명을 가져야하는 것이 아닙니다.

마지막으로 모든 소스 파일에서 주석 처리 된 코드를 찾을 수 있다면 문제가있는 것입니다. 어떤 이유로 든 주석 처리 된 코드를 트렁크에 전달 하는 것은 드문 경우입니다. 이것이 자주 발생하면 어수선 해져 가치를 잃게됩니다.

나는 결코 너무 강한 조건 이라고 생각 하지 않습니다 .

나는 주석 처리하고, 체크인하고, 테스트를 실행하고, 생각하고 다음 릴리스 후에 주석을 제거하는 경향이 있습니다.

일반적으로 주석 처리 된 코드를 체크인하는 것은 원래 작성자가 아니고 코드를 읽거나 수정해야하는 사람들 사이에 혼란을 야기하기 때문에 잘못된 것입니다. 어쨌든 원저자는 3 개월이 지나면 코드에 대해 혼란스러워합니다.

나는 코드가 회사 또는 팀에 속하며 동료를 위해 일을 쉽게 만드는 것은 귀하의 책임이라는 믿음을지지합니다. 주석 처리 된 코드를 확인하지 않고 유지되는 이유에 대한 주석도 추가하지 않는 것은 다음과 같이 말하는 것과 같습니다.

이 물건이 여기에있는 이유에 대해 모두 혼란스러워도 상관 없습니다. 나의 필요는 당신의 것보다 더 중요하기 때문에 내가 이것을 한 이유입니다. 나는 당신이나 다른 사람에게 내가 왜 이렇게했는지를 정당화 할 필요가 없다고 느낍니다.

나에게 주석 처리 된 코드는 일반적으로 덜 사려 깊은 동료 의 무례 함의 표시로 간주됩니다 .

NOW와 같은 작은 기능이나 버그 수정을 추가해야 할 때 다음 3 분 안에 파일을 수정해야 할 때 코드가 절반 정도 개발되어 괜찮습니다. 실용적인 요구 사항이 전장의 실용적 이상을 지배합니다.

저는 주석 처리 된 코드는 체크인하지 말아야한다는 원칙에 광범위하게 동의합니다. 소스 제어 시스템은 공유 리소스이며 동료는 어느 정도이를 개인 스크래치 패드로 사용하고 있습니다. 특히 코드베이스의 공유 소유권 아이디어에 가입 한 경우 다른 사용자에게는 그다지 배려하지 않습니다.

주석 처리 된 코드를 보는 다음 개발자는 그것이 진행중인 작업인지 전혀 알지 못할 것입니다. 그는 그것을 자유롭게 바꿀 수 있습니까? 죽은 코드입니까? 그는 모른다.

동료의 변경 사항이 체크인 할 수있는 상태가 아닌 경우이를 완료하고 / 또는 더 작은 점진적 변경을 수행하는 방법을 배워야합니다.

"배포되거나 배포되지 않을 수있는 부분적인 변경 사항 확인"-아마도 테스트 될 수도 있고 아닐 수도 있음을 의미합니까? 그것은 매우 로프가 많은 코드 기반에 대한 미끄러운 경사입니다.

이것은 두 가지 사고 방식의 근본적인 차이를 보여줍니다. 자신이 만족하고 느끼는 작업 코드 만 확인하는 사람은 절약 할 가치가있는 사람과 작업을 확인하여 수정 관리가있는 사람은 데이터 손실을 막기 위해 거기에 있습니다.

나는 후자를 "가난한 사람의 테이프 백업으로 수정 제어 시스템을 사용하려는 사람들"로 특성화하고 싶지만, 내가 어느 캠프에 있는지에 대해서는 내 손을 기울이게 될 것입니다. :-)

내 생각 엔 당신은 "좋은 코드"캠프에 속하고 그는 "작업 코드"캠프에 속한다.

[편집하다]

댓글에서 네, 맞습니다.

내가 말했듯이, 나는 당신과 함께 있지만, 이것이 여기 stackoverflow와 내가 일하는 곳에서 소수의 의견이라고 말할 수 있습니다. 따라서 나는 당신이 그것을 운영하는 유일한 방법으로 개발 표준에 정말로 담을 수 있다고 생각하지 않습니다. 어쨌든 표준을 따르기를 원한다면 아닙니다. 훌륭한 리더가 아는 한 가지는 그들이 따르지 않을 것이라고 알고 있는 명령을 절대 내리지 않는 것입니다.

btw : 좋은 편집자는 이전 버전을 유지하는 데 도움이 될 것입니다. 예를 들어, Emacs에서는 보관 된 이전 버전과 보관 된 이전 버전을 10으로 설정하여 내 파일의 마지막 10 개 저장을 유지합니다. 백업 제어로서의 개정 통제에 대한 당신의 주장을 돕는 방법으로 그것을 살펴볼 수 있습니다. 그러나 당신은 논쟁에서 이길 수 없습니다.

내 경험상 개발자 스위치는 코드에 주석 처리되어 있습니다.

때로는 새로운 백엔드가 병렬로 빌드되고 활성화 스위치가 소스 제어에서 주석 처리됩니다.

블루 문에서 한 번 필요하지만 고객이 필요로하지 않는 기괴한 기능은 종종 그런 방식으로 구현됩니다. 이러한 것들은 일반적으로 보안 또는 데이터 무결성 우회 위험이 높으므로 개발 외부에서 활성화하는 것을 원하지 않습니다. 먼저 코드 주석을 제거하는 데 사용할 개발자를 요구하는 것이 가장 쉬운 방법 인 것 같습니다.

체크인에 대한 또 다른 이유는 주석 처리 된 코드입니다.

기존 코드를 수정하고 있으며 미묘한 버그를 발견했습니다. 간과하기 쉽고 언뜻보기에는 정확 해 보일 수도 있습니다. 주석 처리하고 수정 사항을 제자리에 놓고 진행 상황과 수정 이유에 대한 주석을 추가하십시오. 수정 사항에 대한 의견이 저장소에 있는지 확인하십시오.

아마도 여기서 진짜 질문은 개발자가 불완전한 코드를 확인할 수 있는지 여부입니다.

이 관행은 지속적인 통합을 구현하려는 귀하의 목표와 모순되는 것 같습니다.

때에 따라 다르지. 설명을 위해 남겨 둔다면 아마도. 리팩토링 중에 유용 할 수 있습니다. 그렇지 않으면 일반적으로 아닙니다. 또한 미완성 코드를 주석 처리하면 오류가 발생하기 쉽고 시간이 많이 소요됩니다. 코드를 더 작은 조각으로 나누고 작동 할 때 확인하는 것이 더 좋습니다.

내 견해 : 개발자가 자체 브랜치 또는 자체 샌드 박스 영역에서 작업하는 경우 원하는 모든 항목을 체크인 할 수 있어야합니다. 코드를 공유 브랜치 (기능 브랜치, 팀의 브랜치 또는 당연히 MAIN / 트렁크)로 체크인 할 때 코드가 가능한 한 깨끗해야합니다 (코멘트 처리 된 코드, 더 이상 FIXME 등).

"Never"는 너무 강력한 규칙이라고 생각합니다. 사람들이 주석이 달린 코드를 저장소에 체크인할지 여부에 대한 개인적인 여유를 남겨두기로 투표하겠습니다. 궁극적 인 목표는 "깨끗한 저장소"가 아닌 코더 생산성이어야합니다.

이러한 느슨 함의 균형을 맞추려면 주석 처리 된 코드에 만료일이 있다는 것을 모든 사람이 알고 있어야합니다. 주석이 달린 코드가 일주일 내내 사용 중이고 활성화되지 않은 경우 누구나 삭제할 수 있습니다. ( "1 주일"을 자신에게 맞는 것으로 바꾸십시오.) 그렇게하면 사람들의 개인적인 스타일을 너무 직접적으로 방해하지 않고 볼 때 혼란을 없앨 권리가 있습니다.

주석 처리 된 코드가 저장소에 체크인되어서는 안된다는 점에 절대적으로 동의합니다. 그것이 바로 소스 코드 제어의 목적입니다.

내 경험상 프로그래머가 주석 처리 된 코드를 체크인했을 때, 올바른 솔루션이 무엇인지 확신 할 수없고 다른 사람이 그 결정을 내릴 것이라는 희망으로 대체 솔루션을 소스에 남겨 두는 것이 더 행복하기 때문입니다.

나는 그것이 코드를 복잡하게 만들고 읽기를 어렵게 만든다는 것을 알았다.

라이브 시스템에서 호출하지 않는 반 완성 된 코드를 확인하는 데 문제가 없습니다 (따라서 소스 제어의 이점을 얻을 수 있음). 내 문제는 설명이없는 주석 처리 된 코드 섹션을 찾는 것입니다. 딜레마는 코드가 제외되는 결과였습니다.

소스 코드 제어 시스템에서 주석 처리 된 코드를 체크인하는 것은 특히 코드를 주석 처리하는 데 사용되는 언어 태그가 블록으로 작성된 경우 특히주의하여 수행해야한다고 생각합니다.

/* My commented code start here
My commented code line 1
My commented code line 2
*/

개별 라인 기준이 아니라 다음과 같습니다.

// My commented code start here
// My commented code line 1
// My commented code line 2

(당신은 아이디어를 얻습니다)

제가 극도로주의를 기울이는 이유는 기술에 따라 사용중인 비교 / 병합 도구에 대해 매우주의해야하기 때문입니다. 특정 소스 코드 제어 시스템과 특정 언어를 사용하면 diff / merge 도구를 쉽게 혼동 할 수 있습니다. 예를 들어 ClearCase의 표준 비교 / 병합은 .xml 파일 병합에 악명이 높습니다.

주석 블록 행이 제대로 병합되지 않으면 코드가 활성화되지 않아야 할 때 시스템에서 활성화됩니다. 코드가 불완전하고 빌드가 깨지면 즉시 발견 할 수 있으므로 아마도 가장 악의가 없을 것입니다.

그러나 코드가 빌드를 통과하면 존재하지 않아야 할 때 활성화 될 수 있으며 CM 관점에서는 악몽 시나리오가 될 수 있습니다. QA는 일반적으로 거기에 있어야 할 것을 테스트하고, 거기에 있어야 할 코드는 테스트하지 않습니다. 따라서 코드는 사용자가 알기 전에 프로덕션에 들어갈 수 있으며, 코드가있을 때 코드가 있음을 깨닫게됩니다. 그렇게해서는 안됩니다 ( "버그"는 생산 과정에서 또는 고객, 최악의 장소 또는 시간에 의해 발견되므로).

소스 제어 히스토리가 무언가를 주석 처리하고 설명과 함께 주석 처리를 확인하는 것보다 "이전 방식"을 설명하도록 허용하는 것은 이론적으로 좋은 생각입니다.

그러나 실제 세계에서는 공식적인 검토 프로세스 (주기적으로 만 수행)의 일부가 아니거나 무언가가 작동하지 않는 경우 및 개발자가 작업중인 파일의 소스 제어 기록을 보지 않습니다. 이유를 알 수 없습니다.

그럼에도 불구하고 3 개 이상의 버전을 되돌아 보는 것은 기본적으로 일어나지 않습니다.

부분적으로 이것은 소스 제어 시스템이 이런 종류의 간단한 검토를 쉽게 만들지 않기 때문입니다. 일반적으로 이전 버전을 확인하거나 이전 버전과 비교해야합니다. 두 버전 만 표시되며 변경된 내용을 한 눈에 볼 수있는 간결한보기가 없습니다.

부분적으로 그것은 인간의 본성과 팀의 요구의 조합입니다. 내가 무언가를 고쳐야하는데 몇 시간 안에 고칠 수 있다면 한 달 동안 "라이브"되지 않은 코드의 이전 버전을 조사하는 데 한 시간을 소비하지 않을 것입니다 (각 개발자가 (예 : 내가 지금하고있는 일과 관련된 내용을 변경하는 것에 대한 논의를 기억하는 경우), 내가 거기에 뭔가가 있다는 것을 우연히 알지 않는 한, 종종 많은 수정을 의미합니다.

코드가 삭제되고 다시 체크인되면 모든 의도와 목적 (완전한 롤백의 제한된 목적 제외)에 대해 존재하지 않게됩니다. 예, 백업 목적으로 존재하지만 코드 사서 역할을하는 사람이 없으면 길을 잃을 것입니다.

내 현재 프로젝트의 소스 제어 트리는 약 10 주가 지났으며 약 4 명의 엔지니어로 구성된 팀이며 약 200 개의 커밋 된 변경 목록이 있습니다. 나는 우리 팀이 뭔가 견고하고 준비가 된 즉시 확인하는 것만 큼 좋은 일을하지 않는다는 것을 알고 있습니다. 따라서 모든 중요한 변경 사항을 파악하기 위해 코드의 모든 부분에 대한 코드 기록을 읽는 것이 매우 어렵습니다.

지금은 초기 개발 모드에서 프로젝트 작업을하고 있는데, 유지 관리 모드의 프로젝트와는 매우 다릅니다. 두 환경 모두에서 동일한 도구가 많이 사용되지만 요구 사항은 상당히 다릅니다. 예를 들어, 종종 두 명 이상의 엔지니어가 무언가를 구축하기 위해 긴밀하게 협력해야하는 작업이 있습니다 (예 : 클라이언트와 서버).

서버를 작성하는 경우 클라이언트가 사용할 초안 인터페이스에 대한 코드를 작성하고 완전히 작동하지 않는 것으로 확인하여 클라이언트를 작성하는 엔지니어가 업데이트 할 수 있도록 할 수 있습니다. 이는 한 엔지니어에서 다른 엔지니어로 코드를 보내는 유일한 방법은 소스 제어 시스템을 통해서라는 정책이 있기 때문입니다.

작업이 충분히 오래 걸릴 경우 우리 둘이 작업 할 분기를 만드는 것이 좋습니다 (조직의 정책에 위배되지만 엔지니어와 개별 팀장은 필요한 권한이 없습니다). 소스 제어 서버). 궁극적으로 트레이드 오프이기 때문에 우리는 너무 많은 "항상"또는 "절대"정책을 수립하지 않으려 고 노력합니다.

나는 그것이 약간 순진하다고 말함으로써 주석없는 코드에 대한 정책에 대응할 것이다. 의도는 좋지만 궁극적으로는 목적을 달성 할 가능성이 낮습니다.

이 게시물을 보면 지난주에 확인한 코드를 다시 살펴보고 최종적이지 않은 주석 처리 된 부분을 제거하고 다시는 원하지 않을 수도 있습니다.

주석 처리 된 코드는 "폐기물"로 간주됩니다.

나는 당신이 팀 환경에서 일하고 있다고 가정하고 있습니다. 혼자서 작업하고 '할 일'로 코드를 주석 처리하고 다시 돌아 오면 그것은 다릅니다. 그러나 팀 환경에서는 일단 주석 처리 된 코드가 체크인되면 그대로 유지 될 것이며 만족보다 더 많은 고통을 유발할 것이라고 안전하게 가정 할 수 있습니다.

피어 코드 검토를 수행하는 경우 질문에 답할 수 있습니다. 다른 개발자가 귀하의 코드를 검토하고 "왜이 코드가 'blah'를 수행하려는 주석 처리 된 코드가 있습니까?"라고 말하면 코드 검토에 실패한 것이므로 어쨌든 확인해서는 안됩니다.

주석 처리 된 코드는 다른 개발자에게 의문을 제기 할 뿐이므로 시간과 에너지를 낭비하게됩니다.

" 왜 "코드가 주석 처리 되었는지 질문해야합니다 . 몇 가지 제안 :

"비즈니스 규칙을 잘 모르기 때문에"코드를 주석 처리하는 경우 "범위 크립"에 문제가있을 수 있습니다. "가지고 있으면 좋지만 시간이 없습니다."라는 요구 사항으로 코드 기반을 더럽 히지 않는 것이 가장 좋습니다. 구현하기 "-명확한 코드로 깔끔하게 유지하고 실제로 무엇이 있는지 테스트합니다.

"가장 좋은 방법인지 확실하지 않아"코드를 주석 처리하는 경우 코드 피어의 검토를 받으십시오! 시대가 변하고 있습니다. 2 년 안에 오늘 작성한 코드를보고 끔찍하다고 생각하게 될 것입니다! 그러나 당신이 '알고있는'부분이 더 잘 될 수 있다는 것을 주석으로 다룰 수는 없지만 지금은 방법을 찾을 수 없습니다. 코드베이스를 장기간 유지하는 사람이 더 나은 방법이 있는지 판단하게하세요. 코드를 작성하고 테스트하고 작업하고 계속 진행하세요.

"무언가가 작동하지 않아"코드를 주석 처리하는 경우 FIX IT ! 일반적인 시나리오는 "깨진 테스트"또는 "할 일" 입니다. 당신이 이것들을 가지고 있다면, 당신은 그것들을 고치거나 제거함으로써 많은 시간을 절약 할 것입니다. 일정 기간 동안 "파손"될 수 있다면 영원히 깨질 가능성이 높습니다.

이러한 모든 잠재적 시나리오 (및 여기서 언급하지 않은 시나리오)는 시간과 노력을 낭비하는 것입니다. 주석 처리 된 코드는 작은 문제처럼 보일 수 있지만 팀의 더 큰 문제를 나타내는 지표가 될 수 있습니다.

저장소는 코드의 백업입니다. 코드 작업을하고 있지만 완료되지 않았다면 주석 처리하고 하루가 끝날 때 체크인하십시오. 이렇게하면 하드 드라이브가 하룻밤 사이에 죽어도 작업을 잃지 않을 것입니다. 아침에 코드를 확인하고 주석 처리를 제거하고 계속 진행할 수 있습니다.

내가 그것을 언급하는 유일한 이유는 밤새 빌드를 깨고 싶지 않기 때문입니다.

1) 조기 체크인과 2) 항상 작동 상태로 저장소를 유지하는 것 사이에는 긴장감이 있습니다. 개발자가 몇 명 이상인 경우 한 명의 개발자가 자신의 개인 워크 플로를 위해 다른 모든 사람을 샅샅이 뒤질 수 없기 때문에 후자가 더 우선적으로 적용됩니다. 즉 , 첫 번째 지침의 가치를 과소 평가해서는 안됩니다. 개발자는 모든 종류의 멘탈 펜스 포스트를 사용하며 개별화 된 워크 플로는 훌륭한 개발자가 추가 X를 짜내는 한 가지 방법입니다. 관리자로서 이러한 모든 뉘앙스를 이해하려고하지 않는 것이 좋습니다. 천재가 아니고 모든 개발자가 바보가 아니면 실패 할 것입니다. 오히려 개발자가 자신의 의사 결정을 통해 최선을 다할 수 있도록합니다.

댓글에서 비공개 브랜치를 사용하지 않는다고 언급했습니다. 제 질문은 왜 안 되나요? 좋아요, 저는 TFS에 대해 아무것도 모르기 때문에 좋은 이유가있을 수 있습니다. 하지만 1 년 동안 git을 사용한 후 좋은 DVCS가이 긴장감을 완전히 분산 시킨다고 말해야합니다. 대체 코드를 작성할 때 코드를 주석 처리하는 것이 유용하다고 생각하는 경우가 있지만 다른 사람에게 코드를 가하면 잠을 잃게됩니다. 로컬에서 분기 할 수 있다는 것은 다운 스트림 개발자에게 일시적인 문제에 대해 걱정할 필요없이 (또는 알리지 않고도) 개별 프로세스에 대해 의미있는 커밋을 유지할 수 있음을 의미합니다.

코러스를 울리는 것뿐입니다. 어떤 대가를 치르더라도 이것을 피하십시오. 그것은 코드를 읽기 어렵게 만들고 사람들은 현재 응용 프로그램의 일부가 아닌 코드에 대해 좋은 / 나쁜 것이 무엇인지 궁금해합니다. 개정판을 비교하여 언제든지 변경 사항을 찾을 수 있습니다. 큰 수술이 있었고 코드가 한꺼번에 주석 처리 되었다면 개발자는 체크인 / 병합에 대한 개정 노트에이를 기록했을 것입니다.

미완성 / 실험적 코드는 개발을 완료하기 위해 분기에 있어야합니다. 헤드 / 트렁크는 항상 컴파일되고 배송되는 메인 라인이어야합니다. 실험 분기가 완료 / 수락되면 헤드 / 메인 라인에 병합되어야합니다. 지원 문서가 필요한 경우이를 설명하는 IEEE 표준 (IEEE 1042)도 있습니다.

나는 완전히 사용할 수없는 동일한 코드에 대해 아직 사용되지 않은 손상되고 액세스 가능한 코드를보고 싶습니다. 모든 버전 제어 소프트웨어는 트렁크에서 분리 된 일종의 '작업 복사본'을 허용하므로 이러한 기능을 대신 사용하는 것이 훨씬 더 좋습니다.

새롭고 작동하지 않는 코드는 새 것이기 때문에 트렁크에서 괜찮습니다. 이미 작동하는 것을 망가 뜨리지는 않을 것입니다. 작동하는 코드가 깨지면 다른 개발자가 (필요한 경우) 해당 분기를 확인하고 고장난 부분을 볼 수 있도록 분기로 이동해야합니다.

" 흉터 조직 "은 제가 주석 처리 된 코드라고 부르는 것입니다. 버전 관리 시스템이 널리 사용되기 며칠 전, Code Monkeys 는 기능을 되돌려 야 할 경우를 대비하여 주석 처리 된 코드를 파일에 남겨 두었습니다.

"흉터 티슈"를 체크인 할 수있는 유일한 시간은

1. 개인 지점이 있고
2. 당신은 오류없이 코드를 컴파일을 할 시간이 없어 및
3. 당신은 긴 휴가를 가고 있고
4. Visual Source Safe OR 을 사용하는 것처럼 VCS를 신뢰하지 않습니다 .
   [편집하다]
5. 잘못된 코드가 알림으로 남겨지지 않으면 다시 발생할 수있는 미묘한 버그가 있습니다. (다른 답변에서 좋은 점).

자유롭게 사용할 수 있고 강력한 VCS 시스템이 많기 때문에 # 4에 대한 변명의 여지가 거의 없습니다 . Git이 가장 좋은 예 입니다.

그렇지 않으면 VCS를 아카이브 및 코드 배포자로 두십시오. 다른 개발자가 당신의 코드를보고 싶어한다면 그에게 diff를 이메일로 보내고 그가 원하는 것을 직접 적용하도록하십시오. 어쨌든 병합은 두 파일의 코딩이 왜 또는 어떻게 갈라 졌는지 상관하지 않습니다.

코드이기 때문에 흉터 조직은 잘 작성된 주석보다 더 산만해질 수 있습니다. 코드로서의 특성상, 당신은 유지 보수 프로그래머가 상처 조직이 그의 변화와 관련이 있는지 알아 내기 위해 정신적 CPU 사이클을 소비하게합니다. 흉터가 1 주일이든 10 년이든 상관없이, 흉터 조직을 코드에 남겨두면 암호를 해독해야하는 사람들에게 부담이됩니다.

[편집] 구별해야 할 두 가지 주요 시나리오가 있다고 추가하겠습니다.

• 개인 프로젝트를 코딩하거나 개인 브랜치에 체크인하는 개인 개발
• 체크인중인 코드가 프로덕션에 투입되는 유지 보수 개발.

흉터 조직에 "아니오"라고 말하세요!

모르겠습니다. 변경하기 전에 항상 원래 줄을 주석 처리합니다. 마음이 바뀌면 원래 줄을 되 돌리는 데 도움이됩니다. 그리고 네, 체크인합니다.

그러나 이전 체크인에서 이전 주석 코드를 제거합니다.

변경된 내용을 확인하기 위해 diff 로그를 볼 수 있다는 것을 알고 있지만 고통 스럽습니다. 코드에서 바로 마지막 변경 내용을 확인하는 것이 좋습니다.

좋은 절충안은 체크 아웃 / 수정 된 파일을 네트워크 백업 드라이브에 덤프하는 작은 도구를 작성하는 것입니다. 그렇게하면 마음껏 내용을 수정하고 작업을 백업 할 수 있지만 실험적이거나 완성되지 않은 코드를 체크인 할 필요가 없습니다.

새로운 변경 사항이 테스트를 통과했기 때문에 주석 처리 된 코드를 체크인하는 것이 유효해야한다고 생각합니다. 이전에 무엇이 있었는지 확인하고 새로운 변경 사항이 실제로 개선되었는지 확인하는 것이 더 도움이 될 수 있습니다.

성능 저하로 이어지는 이전 변경 사항을 확인하기 위해 여러 버전으로 돌아 가야한다면 매우 성 가실 것입니다.

때로는 주석 처리 된 코드가 좋은 기록이지만 코드가 주석 처리 된 날짜를 적어 두십시오. 나중에 근처에서 일하는 사람은 필요하지 않은 것으로 입증되었으므로 주석 처리 된 코드를 삭제할 수 있습니다.

또한 누가 그 코드를 주석 처리했는지 아는 것도 좋을 것입니다. 그래야 어떤 근거가 필요한 경우 질문을받을 수 있습니다.

나는 새로운 기능을 작성하고, 단위 테스트가 통과하는지 확인하고, 체크인 한 다음 다른 사람들이 그것을 사용하고 어떻게 작동하는지 확인하는 것을 선호합니다.

개발자가 코드가 아직 완료되지 않았기 때문에 일부 코드를 주석 처리 한 경우이 문제를 처리하는 올바른 "소스 제어"방법 은 해당 코드 가 확인할 준비가 될 때까지 해당 개발자가 자신의 별도 분기에 코드를 보관하는 것입니다. 에.

DVCS (예 : git, bazaar 또는 mercurial)를 사용하면 중앙 저장소를 변경할 필요가 없기 때문에 매우 쉽습니다. 그렇지 않으면 개발자가 충분한 시간 (예 : 며칠)이 걸리는 특정 기능에 대해 작업하는 경우 개발자에게 서버의 자체 분기를 제공하는 것에 대해 이야기 할 수 있습니다.

어떤 상황에서는 주석 처리 된 코드를 체크인하는 데 아무런 문제가 없습니다. 이는 더 나은 방법이있을 수있는 한 가지 상황이기 때문에 개발자는 준비가되지 않았 더라도 소스의 변경 사항을 추적 할 수 있습니다. 메인 저장소에 체크인했습니다.

분명히 주석 처리 된 코드를 체크인하는 개발자는 필요에 따라 트렁크 브랜치의 변경 사항을 병합하여 별도의 브랜치에서 작업해야합니다.

이 워크 플로우에서 개발자를 지원하는 것은 VCS 시스템에 달려 있습니다 (git은이 작업과 매우 잘 작동하는 훌륭한 VCS 시스템 중 하나입니다).