가장 좋은 방법은 무엇입니까? 그들을 위해 단위 테스트를 작성하거나 그들이 왜 있는지 질문합니까?

코드를 삭제하는 것이 좋습니다.

코드를 삭제할 수 없으면 @Deprecated 로 표시 하여 메소드를 제거하기 위해 어떤 주요 릴리스 를 문서화 할 수 있습니다 . 그런 다음 “나중에”삭제할 수 있습니다. 그 동안 새로운 코드를 추가해서는 안된다는 것이 분명합니다.

더 이상 사용되지 않는 방법에 대한 투자는 권장하지 않으므로 적용 범위 목표를 달성하기위한 새로운 단위 테스트는 없습니다.

이 둘의 차이점은 주로 메서드가 게시 된 인터페이스의 일부인지 여부 입니다. 게시 된 인터페이스의 일부를 임의로 삭제하면 인터페이스에 의존하는 소비자에게는 불쾌한 일이 될 수 있습니다.

나는 EclEmma와 대화 할 수 없지만 내 경험상주의해야 할 사항 중 하나는 반성입니다. 예를 들어, 텍스트 구성 파일을 사용하여 액세스 할 클래스 / 방법을 선택하는 경우 사용 / 사용하지 않는 구별이 명확하지 않을 수 있습니다 (연결된 시간에 불에 타버 렸습니다).

프로젝트가 의존성 그래프의 리프 인 경우 지원 중단 사례가 약화됩니다. 프로젝트가 라이브러리 인 경우 지원 중단 사례가 더 강력합니다.

회사에서 mono-repo를 사용하는 경우 삭제가 multi-repo 사례보다 위험이 적습니다.

l0b0 에 의해 언급 된 바와 같이 , 소스 제어에서 메소드가 이미 사용 가능한 경우, 삭제 후 메소드를 복구하는 것이 간단합니다. 그렇게해야한다고 정말로 걱정했다면 커밋을 구성하는 방법에 대해 생각해보고 삭제 된 변경 사항이 필요할 때이를 복구 할 수 있도록하십시오.

불확실성이 충분히 높으면 코드 를 삭제하지 않고 주석 처리하는 것이 좋습니다. 행복한 경로 (삭제 된 코드가 절대로 복원되지 않는)에서 추가 작업이지만 복원하기가 더 쉽습니다. 내 생각에 당신은 몇 번 그 (것)들에 의해 불에 타기까지 똑바로 삭제를 선호해야한다,이 문맥에서 “불확실성”을 평가하는 방법에 대한 통찰력을 줄 것이다.

그들이 왜 있는지 질문합니까?

지식을 포착하는 데 투자 된 시간이 반드시 낭비되는 것은 아닙니다. 필자는 코드에 대해 배운 내용을 설명하는 주석을 추가하고 커밋 한 다음 나중에 코드 (및 주석)를 삭제하여 두 단계로 제거를 수행하는 것으로 알려져 있습니다.

소스 코드를 사용하여 지식을 포착하는 방법으로 아키텍처 결정 레코드 와 유사한 것을 사용할 수도 있습니다 .

답변