코드를 주석 처리 한 다음 점진적으로 제거하여 이미 수행 한 작업과 수행 할 작업을 추적하는 것이 왜 잘못 되었습니까?

코드가 잘못되었거나 다른 이유로 인해 필요한 주요 아키텍처 변경 사항에 맞게 조정되어야하므로 코드의 많은 부분을 변경해야 할 때마다 이것이 일반적으로 수행하는 작업입니다.

1. 변경해야 할 것으로 의심되는 모든 코드를 주석 처리합니다. 주석 처리 된 코드를 일종의 TODO 목록으로 취급합니다.
2. 주석 처리 된 코드를 검토 하고이 코드의 주석 처리를 제거하거나 다른 곳에서 복사하여 붙여 넣은 다음 필요에 따라 편집하거나 주석 처리 된 코드를 참조 하여이 코드의 일부를 처음부터 다시 작성하십시오. 내가 주석 처리 된 코드의 일부로 끝났다고 생각할 때마다 제거합니다.
3. 주석 처리 된 코드가 더 이상 표시되지 않을 때까지이 작업을 계속합니다.

나는 혼자서 개발하고있는 개인 프로젝트에서 주로이 작업을 수행하고 있습니다.

그러나 나는 이것을 중단해야한다고 들었습니다. 대신 주석 처리 된 코드를 남기지 않고 이전 커밋을 참조하여 이전 커밋을 참조하여 git 사용을 시작해야한다고 들었습니다. 나는 들었다:

코드 주석 처리는 제거해야하는 나쁜 습관입니다. 당신은 경험이 부족하여 그것을 이해하지 못합니다. 몇 년 안에 코드 주석 처리를 좋아하는 다른 사람의 코드가 보이면이 사람에게 맹세하기 시작할 것입니다. 주석 처리 된 코드를 볼 때마다 코드를 보지 않고도 코드를 완전히 제거합니다. 일반적으로 이러한 코드는 완전히 가치가 없기 때문입니다. 소규모 1 인 프로젝트에서 코드 주석 처리의 단점을 확실히 보지 못할 것입니다. 그러나 직업을 찾고이 습관을 지키면 수치가 될 것입니다.

지금보고 있지 않은 내가하고있는 일의 단점을 물어봐도 될까요?

과거 코드를보기 위해 git 만 사용하고 싶지 않다고 말해야합니다. 앞서 말했듯이 코드 주석 처리를 일종의 할 일 목록으로 취급합니다. git은 코드가 어떻게 보였는지를 보여 주지만 여전히 검토해야 할 부분과 이미 수행 된 부분을 명확하게 보여주지 못합니다. 코드의 일부를 놓치고 버그가 발생할 수 있습니다.

완전성을 기하기 위해 인용하는 사람은 숙련 된 개발자이자 Bob 아저씨의 "Clean Code"의 팬이라고 덧붙여 야한다고 생각합니다. Bob 아저씨는 그의 책에서 코드를 거칠게 주석 처리하는 것을 비난했습니다.

주석 처리 된 코드를 모두 제거하면 실제로 아무런 문제가 없습니다. 주석 처리 된 코드를 코드베이스에 남겨 두는 것은 좋지 않은 방법이지만, 코드를 모두 처리하고 제거 할 경우에는 그렇게하지 않습니다. 나는 당신이 말하는 사람이 당신이 사용하고있는 과정을 이해하지 못하거나 독단적이라고 생각합니다.

실제로 주석 처리 된 코드는 무해합니다. 문제는 그것이 지저분하고 읽기가 어렵다는 것입니다. 훨씬 더 나쁜 죄가 있지만 제거하는 것은 매우 간단한 일입니다. 코드를 주석 처리 한 사람은 코드를 완전히 제거 할 수있는 최상의 위치에 있습니다.

많은 IDE와 코드 편집기는 주석에서 일종의 'TODO'구문을 이해합니다. 변경해야 할 사항을 표시하는 다른 방법입니다. 이를 표시 할 때 생각했던 것에 대한 정보를 조금 더 제공하므로이를 고려할 수 있습니다.

하루가 끝나면 최상의 결과를 얻을 수있는 방식으로 일을하십시오. 이것이 팀 프로젝트 인 경우에도 주석 처리 된 모든 코드를 제거하는 한 다른 사람에게 부담을주지 않습니다.

지금보고 있지 않은 내가하고있는 일의 단점을 물어봐도 될까요?

혼자서 일하고 버전 관리를 사용하지 않고 이런 식으로해도 좋다고 생각하는 사람은 없을 것입니다.

사실, 버전 제어가 없으면 코드는 항상 현재 파일이 운영 체제에서 "저장된"상태가되기 때문에 "시간"의 어느 시점에서 무엇을 하든지 중요하지 않습니다.

버전 관리를 사용하고 "할 일 목록"으로 많은 주석이 있고 일부를 수정하고 주석을 제거한 다음 반복하고 반복하는 등의 경우 "작업 진행 중"코드와 주석이 저장됩니다 개정 내역에서. 다른 커밋으로 롤백하거나 나중에 "체리 픽"할 필요가없는 경우에는 문제가되지 않습니다 (예 : 특정 커밋을 가져 와서 사용할 다른 브랜치로 가져 오는 위치). 그러나 그렇지 않으면 문제가 될 수 있습니다.

아마도 이것은 Windows와 같은 하드 드라이브 소프트웨어 "스냅 샷"과 비교할 수 있습니다 (복원 사물). 바이러스가 포함 된 스냅 샷을 생성하면 바이러스를 죽인 다음 나중에 롤백해야 바이러스가 다시 존재하는 지점으로 돌아갈 수 있습니다.

이 방법은 또한 가능성이 당신이 버전 제어 사용할 때 문제가 될 수 및 다른 DEVS과 일을 그들은보고 가지고, 당신 그들에게 아무 소용이없는 일 목록을. 사실, 그들은 무시하고 해결해야하는 혼란 스러울뿐입니다. 우리 팀에서는 이전 코드 또는 "노트"와 같은 모든 주석을 항상 제거합니다. 그들이 유용하지 않으면- "어떻게 작동 하는가"에 대한 문서와해야 할 일 (일명해야 할 일)을 추적하는 소프트웨어가 있기 때문에 이것은 매우 드 rare니다.

또한 더 큰 프로젝트에서 작업 할 때는 공동 작업을하고 자주 커밋하고 푸시하는 경향이 있으므로 작업중인 지점이 지점을 병합 할 경우 TODO 목록을 가질 수 있습니다. 그렇다면 TODO 목록은 모두의 비즈니스입니다 .D

요약하면, 혼자 작업하지 않고 특히 버전 제어를 사용할 때 기록이 복잡해져 다른 개발자들에게 혼란을 줄 수 있습니다.

그리고 이것은 어떤면에서 개인적인 일이지만 코드베이스를 "할 일 목록"으로 사용하는 것은 실제로 이상적이지 않습니다. 언젠가 우연히 무언가를 남겨 두거나 실수로 댓글을 달거나 주석을 해제하는 것을 잊을 수 있습니다.

아키텍처, 코딩 및 개인 또는 팀의 작업 방식에 대한 많은 접근 방식과 마찬가지로 각 시나리오는 다른 것을 요구할 수 있습니다. 따라서 언급 된 단점과 버전 제어 사용의 이점을 고려하고 그것이 적합한 지 결정 하십시오 .

리뷰어가 약간 독단적 인 것처럼 들립니다. 코드를 주석 처리 한 사람에게 맹세하는 것은 확실하지 않습니다 PC ;-) 또는 심지어 도움이됩니다 ;-)

그러나 더 진지하게, 나는 리뷰어가 옳다고 생각합니다 .git (또는 다른 소스 제어 시스템을 사용하는 것이 중요하지만 git은 합리적인 선택입니다).

그리고 그렇게하면 코드 주석 처리에 대한 일부 요구가 완화 될 수 있습니다.

그러나 코드 내에서 TODO 목록 (글 머리 기호 목록 또는 이전 코드)을 갖는 것은 내 의견으로는 상당히 합리적입니다. 그러나 어떻게하는지에 대해 조금 재고하고 싶을 수도 있습니다. 우선 다른 사람이 코드를 읽는 것에 대해 생각하는 것이 좋습니다. 프로젝트를 삭제하고 다시 참여한 후 1 년이 지나면 다른 사람이 당신이 될 수 있습니다. 아니면 다른 사람 일 수도 있습니다. 주석 처리 된 코드가 발생하는 것은 약간 혼란 스럽습니다. 어쩌면 다음과 같은 것 :

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

개인적으로 나는 다음과 같은쪽으로 더 많이 기대합니다.

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

도움이 될 때마다 이전 코드에서 '코드 스 니펫'을 자유롭게 던질 수 있습니다.

자식을 사용하는 것은 어렵습니다 (슬프게도). 배우는 데 시간이 걸리며, 달성하려는 내용의 일부가 아닌 것 같습니다. 그러나 프로그램을 유용하게 사용하려면 팀의 일원으로 그렇게하고 팀과 의사 소통하는 법을 배워야하며 git은 오늘날의 방식입니다. 그리고 일단 사용하면 매우 유용한 도구 / 버팀목을 찾을 수 있으므로 소프트웨어 개발이 쉬워집니다.

행운을 빌어 요!

코드를 주석 처리하는 데는 여러 가지 이유가 있습니다.

• 아직 옳지 않으며 준비가되면 주석을 해제합니다.
• 디버깅하는 동안 동작을 변경하기 위해 일시적으로 주석 처리합니다.
• 코드가 필요한지 확실하지 않지만 테스트를 마칠 때까지 코드를 삭제하지 마십시오.
• 일부 버전의 소프트웨어에는 코드가 필요하지만이 버전에는 필요하지 않습니다.
• 이 코드는 더 이상 사용되지 않지만 작성하는 데 오랜 시간이 걸리고 감정적으로 코드에 첨부됩니다. 게다가 언젠가는 유용 할 것입니다.

문제는 코드를 침대에 넣은 다음 몇 년 후에 다시 유지 보수를 수행하기 위해 다시 돌아옵니다. 주석 처리 된 코드로 흩어진 코드베이스를 찾을 수 있습니다. 더 이상 존재하지 않는 이유는 더 이상 명확하지 않으며 이제는 혼란 스럽습니다.

반 정도 버전 관리 도구를 사용하는 경우 버전 관리 시스템에 여전히 저장되어 있다는 사실을 알고 더 이상 필요하지 않은 코드를 대담하게 삭제할 수 있습니다. 버전 간 파일 차이는 삭제 된 내용을 나타냅니다. 버전 관리를 구현 한 후에는 주석 처리 만하면됩니다. 실제로 작업하지 않는 파일에서 주석 처리 된 코드를 찾은 경우 해당 코드를 삭제하면됩니다.

나는 한 사람의 프로젝트에도 소스 컨트롤을 사용해야하는 이유를 반복하지 않을 것입니다. 다른 리소스가 많기 때문에이 작업을 수행해야합니다. 그러나 현재 접근 방식의 한 가지 주요 단점은 코드를 주석 처리하면 IDE에서 코드를 숨 깁니다 (IDE를 사용하지 않는 경우 코드를 고려해야 함).

예를 들어, 메소드 또는 클래스의 이름을 바꾸거나 메소드가 취하는 매개 변수 수를 변경하려면 IDE에 리팩터링 옵션이 있어야 모든 적절한 참조를 찾고 그에 따라 업데이트 할 수 있습니다. 주석에서 검색하지 마십시오.

어디에서 변경해야하는지 추측하지 말고 변경 만하면 IDE에서 변경으로 인해 문제가 발생한 위치를 알려줍니다. 그런 다음 코드를 더 외과 적으로, 그리고 더 짧은 기간 동안 코드를 주석 처리 할 수 ​​있습니다.

그건 나쁜 당신은해야합니다 중지 .

그 이유는 한 번에 많은 양의 리팩토링을 시도하는 것으로 요약됩니다.

큰 코드 섹션을 주석 처리하고 약간 수정 한 후 체크인하면 작동하지 않는 코드를 체크인 한 것입니다. 다른 사람들이 낡고 무시할 수있는 주석 처리 된 내용의 전체로드

자주 체크인하지 않으면 병합 충돌이 누적되고 단계별 진행 상황이 기록되지 않습니다.

중간에 멈추어야 모든 것이 여전히 작동하도록 작업 방식을 변경해야합니다.

아기 발자국을 밟고 각각 후에 체크인하십시오.

• 인터페이스를 추출하다
• 시험을 쓰다
• 함수를 리팩토링

코드를 주석 처리하여 큰 코드 덩어리를 '귀하의 것'으로 표시하지 말고 완료되거나 실패 할 때까지 직접 처리하십시오.

수행해야 할 작업을 추적해야하는 경우 스크럼 또는 trello와 같은 작업 보드를 사용하십시오.