입력되지 않은 것처럼 보이는 코드를 어떻게 안전하게 삭제합니까?

불필요한 코드를 발견했으며 컴파일러는이를 알지 못합니다. 이 코드를 삭제해도 회귀 현상이 발생하지 않도록하려면 어떻게해야합니까?

두 가지 아이디어가 떠 오릅니다.

1. "간단하게"코드가 실행되어야하는지 여부에 따라 추론을 사용하십시오. 그러나 때로는 막대한 비즈니스 수익이 없기 때문에 복잡하고 시간이 많이 걸리는 작업 일 수 있습니다 (평가에 오류가 발생하기 쉽습니다).

2. 해당 코드 섹션에 로깅을 배치하고 실제로 얼마나 자주 입력되는지 확인하십시오. 충분한 실행 후에는 코드를 제거해도 안전하다는 합리적인 확신이 있어야합니다.

더 나은 아이디어 나 정식 접근법과 같은 것이 있습니까?

100 % 단위 테스트 적용 범위를 가진 완벽한 판타지 세계에서는 삭제하고 단위 테스트를 실행하며 테스트가 빨간색으로 바뀌지 않으면 커밋합니다.

그러나 불행히도 매일 아침 일어나서 많은 코드가 단위 테스트가 없거나 가능한 경우 모든 가능한 경우를 다룰 수 있다고 믿을 수없는 거친 현실에 직면해야합니다. 따라서 위험 / 보상을 고려하고 그만한 가치가 없다는 결론에 도달했습니다.

• 보상 : 코드는 미래에 유지하기가 조금 더 쉽습니다.
• 위험 : 내가 생각하지 않았던 모호한 일부 사례에서 코드를 깨뜨리고, 최소한 기대할 때 사고를 일으키며, 코드 품질 OCD를 충족시키고 비즈니스 가치없이 인식 할 수 있어야했기 때문에 오류가 발생했습니다. 코더가 아닌 이해 관계자에게

이 과정에는 두 가지 반이 있습니다. 첫 번째는 코드가 실제로 죽었 음을 확인하는 것입니다. 두 번째는 잘못된 비용을 이해하고 올바르게 완화시키는 것입니다.

여기에 많은 답변이 전반에 대한 훌륭한 해결책이 있습니다. 정적 분석기와 같은 도구는 데드 코드를 식별하는 데 유용합니다. grep어떤 경우에는 친구가 될 수 있습니다. 내가 자주 취하는 한 가지 특이한 단계는 코드의 원래 목적이 무엇인지 식별하는 것입니다. “X는 더 이상 제품의 기능이 아니며 코드 세그먼트 Y는 기능 X를 지원하도록 설계되었습니다.”는“코드 세그먼트 Y의 목적이 보이지 않습니다.”라고 말하는 것보다 훨씬 쉽습니다.

후반부는 코드를 제거해야하는지에 대한 그리드 락을 깨는 핵심 단계입니다. 답변이 잘못되었다는 의미를 이해해야합니다. 대답이 틀리면 사람들이 죽을 경우주의를 기울이십시오! 어쩌면 코드 크래프트가 시간이 지남에 따라 발전한다는 것을 받아들이고 대신 더 많은 크래프팅을 작성하지 마십시오. 사람들이 죽지 않을 경우 자신을 어떻게 용서하는지 물어보십시오. 문제가 발생하여 고객 관계를 유지하는 경우 핫픽스를 보낼 수 있습니까? 이와 같은 문제를 찾기 위해 비용을 지불 한 Q & A 팀이 있습니까? 이러한 종류의 질문은 삭제 키를 누르기 전에 얼마나 확신해야 하는지를 이해하는 데 필수적입니다.

의견에서 rmun은 코드를 제거하기 전에 코드의 원래 목적을 이해하는 개념에 대한 훌륭한 표현을 지적했습니다. 인용문은 현재 체스터턴의 울타리 로 알려져 있습니다. 주석에 직접 인용하기에는 너무 크지 만 여기에 올바르게 인용 할 가치가 있다고 생각합니다.

그것들을 변형시키는 것과 구별되는 것들을 개혁하는 문제에는 분명하고 단순한 한 가지 원칙이있다. 아마도 역설이라고 불리는 원칙. 이 경우 특정 기관이나 법률이 있습니다. 단순성을 위해 도로를 가로 질러 울타리 나 문을 세웠습니다. 보다 현대적인 유형의 개혁가는 그것을 기꺼이 받아 들여서 말합니다.“저는 이것을 사용하지 않습니다. 보다 지능적인 유형의 개혁가가 대답 할 수있는 좋은 방법은 다음과 같습니다.“어떻게 사용하지 않으면 분명히 지울 수 없습니다. 저리 가서 생각하십시오. 그런 다음 다시 돌아와서 그 사용법을 볼 수 있다고 말하면, 나는 그것을 파기 할 수 있습니다.

또한 grep코드에서 함수 / 클래스 이름을 사용하는 경향이 있는데, 예를 들어 주석이나 문서 파일 또는 스크립트에 이름이 언급 된 경우와 같이 코드 분석기가 제공하지 않을 수있는 추가적인 이점이 있습니다. 소스 트리의 파일에서 grep을 실행하고 결과를 파일에 저장합니다. 일반적으로 결과는 압축 된 정보 (파일 이름 / 경로, 행 번호 및 이름이있는 행)를 제공하며, 이는 의미 적 의미없이 함수 / 클래스가 호출되거나 언급 된 위치에 대한 단서를 제공 할 수 있습니다 (코드 분석기와 달리) ) 및 파일 확장자에 관계없이 확실히 최고의 솔루션은 아니지만 분석에 대한 훌륭한 추가 기능입니다.

• 죽은 것처럼 보이는 코드를 식별하십시오 (정적 분석 등).
• 죽은 것으로 의심되는 코드가 호출 될 때마다 로그 메시지를 추가하십시오 . 함수 / 메소드로 쉽습니다. 상수와 같은 정적 멤버를 사용하면 까다 롭습니다. 때로는 코드를 더 이상 사용되지 않는 것으로 표시하고 런타임에서 자동으로 메시지를 기록합니다. 그렇지 않으면 코드를 그대로 두십시오.
  • 죽은 모듈이로드 될 때 메시지를 기록합니다. 대부분의 언어에는로드시 정적 초기화를 실행할 수있는 방법이 있습니다.
  • 로그 메시지에 합리적인 스택 추적이 포함되어 있는지 확인하여 데드 코드라고하는 것이 무엇인지 이해 하십시오.
• 모든 테스트 스위트를 통해 변경된 코드를 실행하십시오. 테스트 스위트는 또한 자정을 건너는 것과 같은 특별한 시간, 1/4 분기, 1 년 차례 등을 테스트해야합니다. 로그를보고 죽은 내용에 대한 이해를 업데이트하십시오. 단위 테스트는 데드 코드를 구체적으로 테스트 할 수 있지만 다른 단위 테스트 및 통합 테스트는 해당 코드를 건드리지 않습니다.
• 몇 주 동안 프로덕션 환경에서 변경된 코드를 실행하십시오. 한 달에 한 번 ETL cron 작업과 같은 모든 주기적 프로세스가이 기간 동안 실행되는지 확인하십시오.
• 로그를보십시오. 기록 된 것은 실제로 죽지 않았습니다. 죽은 코드의 나머지 부분을 통해 콜 그래프의 전이 폐쇄는 또한 이 호출되지 않은 경우에도, 잠재적으로 죽지 않았어. 분석하십시오. 어쩌면 일부 브랜치는 안전하게 죽었을 수도 있습니다 (예 : 현재 소멸 된 서비스의 API로 작업). 전체 모듈 / 클래스는 정의 된 상수에 대해서만로드 될 수 있으며 쉽게 폐기 할 수 있습니다.
• 남은 것은 안전하게 죽어 제거 할 수 있습니다.

언급 된 기존 답변 외에도 여러 버전에서 반복적으로 코드를 제거 할 수 있습니다.

초기 버전에서는 코드 블록이 계속 작동하면서 사용 중단 경고를 표시 할 수 있습니다. 이후 버전에서는 코드 블록을 제거 할 수 있지만 사용자에게이 기능은 더 이상 사용되지 않으며 더 이상 사용할 수 없다는 오류 메시지를 남길 수 있습니다. 최종 버전에서는 코드 블록과 모든 메시지를 제거합니다.

이는 최종 사용자에게 경고없이 예기치 않은 기능을 식별하는 데 도움이 될 수 있습니다. 가장 좋은 시나리오에서 코드는 실제로 아무것도하지 않으며 필요한 모든 코드는 제거되기 전에 여러 버전으로 유지됩니다.

많은 사람들이 "안전한"할 일은 코드가 사용되지 않았다는 것을 증명할 수 없다면 코드를 그대로 두는 것입니다.

그러나 코드는 자산이 아니며 책임입니다.

중요한 이유를 설명하고 테스트를 지시하지 않는 한 "safer"대안은 삭제하는 것이 좋습니다.

여전히 확실하지 않은 경우 최소한 좀비 코드를 테스트하기위한 테스트를 추가해야합니다.

기능 토글을 사용하여 해당 코드를 완전히 무시하도록 소프트웨어의 실행 경로를 변경할 수 있습니다.

이렇게하면 사용하지 않는 코드를 사용하여 변경 사항을 안전하게 배포하고 해제 할 수 있습니다. 코드와 관련된 주요 결함이 발견되면 토글을 다시 켜고 가능한 경로를 조사하십시오.

이 방법을 사용하면 오랜 시간 동안 문제가 발생하지 않고 배포없이 실시간으로 다시 켤 수있는 능력이있는 경우 자신감을 가질 수 있습니다. 그러나 더 나은 방법은 해당 영역 주위에 추가 로깅 및 테스트 적용 범위를 적용하여 사용 여부에 대한 더 많은 증거를 제공하는 것입니다.

토글에 대한 자세한 내용은 https://martinfowler.com/articles/feature-toggles.html을 참조 하십시오.

정적 분석은 물론 ... 새로운 도구는 필요하지 않습니다. 컴파일러에는 필요한 모든 정적 분석 도구가 있습니다.

그냥 방법 (예를 들면 변경의 이름 변경 DoSomething에를 DoSomethingX) 다음 빌드를 실행합니다.

만약 당신의 빌드가 성공한다면,이 방법은 어떤 것도 사용하지 않는 것입니다. 삭제해도 안전합니다.

빌드가 실패하면 코드를 호출하는 코드 라인을 분리 if하고 호출을 둘러싸는 명령문을 확인하여 트리거 방법을 결정하십시오. 트리거하는 가능한 데이터 유스 케이스를 찾을 수 없으면 안전하게 삭제할 수 있습니다.

실제로 코드를 삭제하는 것이 걱정된다면 코드를 유지하면서 ObsoleteAttribute (또는 해당 언어의 해당 속성)로 표시하십시오 . 한 버전에 대해 그런 식으로 릴리스 한 다음 문제가 없으면 코드를 제거하십시오.

• 코드 분석기를 사용하여 이것이 죽은 코드인지 확인합니다.
• 테스트를 확인하고 코드에 도달하려고 시도했습니다. 테스트 케이스 내에서 코드에 도달 할 수 없으면 죽은 코드 일 수 있습니다.
• 코드를 제거하고 대신 예외를 throw합니다. 한 릴리스에서는 예외가 활성화되고 두 번째 릴리스에서는 예외를 제거 할 수 있습니다. 안전을 위해 고객이 예외를 발견하면 원래 코드를 활성화 할 수 있도록 긴급 플래그 (Java에서 시스템 특성)를 배치하십시오. 따라서 프로덕션 환경에서 예외를 비활성화하고 원본 코드를 활성화 할 수 있습니다.

도달 할 수없는 코드 제거

원칙적으로 정적으로 유형이 지정된 언어에서는 코드가 실제로 도달 가능한지 여부를 항상 알아야합니다. 코드를 제거하고 컴파일 할 수 있으며 오류가없는 경우 도달 할 수 없습니다.

불행하게도, 모든 언어가 정적으로 입력되는 것은 아니며 모든 정적으로 유형이 지정된 언어가 원칙적으로 정해지는 것은 아닙니다. 잘못 될 수있는 것은 (1) 반성 및 (2) 원치 않는 과부하입니다.

동적 언어 또는 충분히 강력한 리플렉션이있는 언어를 사용하여 조사중인 코드 조각을 리플렉션을 통해 런타임에 액세스 할 수있는 경우 컴파일러를 사용할 수 없습니다. 이러한 언어에는 Python, Ruby 또는 Java가 포함됩니다.

원칙적으로 과부하가 걸리지 않는 언어를 사용하는 경우 단순히 과부하를 제거하면 과부하 해결이 다른 과부하로 자동 전환 될 수 있습니다. 이러한 언어를 사용하면 코드 사용과 관련된 컴파일 타임 경고 / 오류를 프로그래밍 할 수 있습니다. 그렇지 않으면 컴파일러에 의존 할 수 없습니다. 이러한 언어에는 Java (use @Deprecated) 또는 C ++ (use [[deprecated]]또는 = delete)가 포함됩니다.

따라서 엄격한 언어로 작업하는 것이 운이 좋지 않으면 (Rust 염두에 두어야 함) 컴파일러를 신뢰하여 실제로 발을 쏠 수 있습니다. 불행히도 테스트 스위트는 일반적으로 불완전하므로 더 이상 도움이되지 않습니다.

다음 섹션 큐 ...

잠재적으로 사용되지 않는 코드 제거

더 많은 가능성이 코드가 실제로 참조, 그러나 당신은 의심 실제로 그것을 참조하는 코드의 분기가 취해지지 않습니다 것을.

이 경우 언어에 관계없이 코드에 도달 할 수 있으며 런타임 계측 만 사용할 수 있습니다.

과거에는 이러한 코드를 제거하기 위해 3 단계 접근 방식을 성공적으로 사용했습니다.

1. 취하지 않을 것으로 의심되는 각 지점에서 경고를 기록하십시오.
2. 한 사이클 후에 특정 코드를 입력 할 때 예외를 던지거나 오류를 반환하십시오.
3. 다른주기 후에 코드를 삭제하십시오.

주기는 무엇입니까? 코드 사용주기입니다. 예를 들어, 금융 응용 프로그램의 경우 월간 짧은주기 (월말에 급여가 지급됨)와 긴주기는 예상됩니다. 이 경우 연말 재고가 달리 사용되지 않는 코드 경로를 사용할 수 있다는 경고가 발생하지 않는지 확인하기 위해 최소 1 년을 기다려야합니다.

바라건대, 대부분의 응용 프로그램은 더 짧은주기를 갖습니다.

TODO 의견을 날짜와 함께 다음 단계로 넘어갈 때 조언하는 것이 좋습니다. 그리고 당신의 달력에서 알림.

프로덕션에서 코드를 제거하는 것은 집 청소와 같습니다. 다락방에서 물건을 버리는 순간 다음날 아내는 1923 년에 사망 한 이웃으로부터 증조 할머니의 세 번째 조카의 귀향 선물을 버리기 위해 다음 날 당신을 죽일 것입니다.

진지하게, 모든 사람들이 이미 언급 한 다양한 도구를 사용하여 커서 분석을 한 후, 이미 언급 된 단계적 사용 중단 접근법을 사용한 후에는 실제 제거가 수행 될 때 회사에서 퇴출 될 수 있음을 명심하십시오. 코드를 유지하고 실행을 기록하게하고 실행에 대한 경고가 반드시 귀하 (또는 후임자와 할당)에게 전달되도록하는 것이 필수적입니다.

이 방법을 따르지 않으면 아내가 살해 당할 가능성이 있습니다. 모든 유품과 같이 코드를 유지하면 무어의 법칙이 구조에 온다는 사실과 "내 신발 속의 바위"처럼 느껴지는 코드에 사용되는 정크 디스크 공간의 비용으로 양심을 쉴 수 있습니다. 그리고 당신은 복도에서 여러 개의 물 냉각기 험담과 이상한 외모의 중심이 될 위험이 없습니다.

추신 : 의견에 대한 답변으로 명확히하기 위해. 원래의 질문은 "당신은 어떻게 안전하게 삭제 합니까? "입니다. 물론, 내 대답에는 Version Control이 있다고 가정합니다. 쓰레기를 파서 마치 귀중한 것을 찾는 것처럼 가정합니다. 어떤 의미로든 코드를 버릴 수있는 기관은 없으며 모든 개발자가 엄격하게 코드를 관리해야합니다.

문제는 불필요한 코드에 관한 것입니다. 실행 경로의 100 %가 도달하지 않는다고 보장 할 수 없다면 코드 조각이 불필요하다는 것을 결코 알 수 없습니다. 그리고 이것은 이것이 보장 할 수 없을만큼 충분히 큰 소프트웨어라고 가정합니다. 그리고 질문을 잘못 읽지 않는 한이 대화의 전체 스레드와 관련된 유일한 시간은 제거 된 코드가 호출되어 런타임 / 생산 문제가있는 생산 중입니다. 버전 관리는 생산 실패로 인해 누군가의 배후를 저장하지 않으므로 "버전 제어"에 대한 의견은 질문이나 원래의 요점과 관련이 없습니다.

IMHO의 의견은 불필요하며 삭제 후보입니다.

어쩌면 컴파일러 는 눈치 채지 않을 것입니다.

크기에 맞게 전체 컴파일러 최적화로 빌드를 실행하십시오. 그런 다음 의심스러운 코드를 삭제하고 빌드를 다시 실행하십시오.

이진을 비교하십시오. 그것들이 동일하다면, 컴파일러는 코드를 알아 차리고 자동으로 삭제했습니다. 소스에서 안전하게 삭제할 수 있습니다.

바이너리가 다르면 결정적이지 않습니다. 다른 변화 일 수도 있습니다. 일부 컴파일러에는 바이너리에 컴파일 날짜 및 시간이 포함되어있을 수도 있습니다 (아마도 구성 가능).

저는 최근에 "deleteFoo"라는 방법으로이 정확한 상황을 접했습니다. 전체 코드베이스에서 메소드 선언 이외의 문자열이 발견되지는 않았지만 메소드 상단에 로그 줄을 작성하는 것이 현명합니다.

PHP :

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

코드가 사용 된 것으로 나타났습니다! 일부 AJAX 메소드는 "method : delete, elem = Foo"를 호출 한 다음 call_user_func_array () 로 연결하여 호출 합니다.

확실하지 않은 경우 로그하십시오! 로그가 채워지지 않은 채 충분한 시간을 보냈다면 코드 제거를 고려하십시오. 그러나 코드를 제거하더라도 로그를 유지하고 날짜를 적어두고 Git에서 커밋을 쉽게 찾을 수 있도록하십시오!

grep먼저 사용 가능한 도구를 사용 하거나 코드에 대한 참조를 찾을 수 있습니다. (원래 나의 지시 / 조언이 아닙니다.)

그런 다음 코드를 제거 할 위험이 있는지 또는 내 제안을 사용할 수 있는지 결정하십시오.

함수 / 코드 블록을 수정하여 로그 파일에 사용되었음을 기록 할 수 있습니다. 이러한 메시지가 로그 파일에 "기록되지 않은"경우 로깅 코드를 제거 할 수 있습니다.

두 가지 문제 :

1. 다른 사용자로부터 로그 가져 오기 아마도 종료시 프로그램을 중단시키고 사용자에게 오류 로그를 보내달라고 요청하는 전역 플래그를 설정할 수 있습니다.

2. 발신자를 추적합니다. 일부 고급 언어 (예 : Python)에서는 쉽게 역 추적을 얻을 수 있습니다. 그러나 컴파일 된 언어에서는 리턴 주소를 로그에 저장하고 종료시 코어 덤프를 강제 실행해야합니다 (포인트 1).
   C에서는 매우 간단해야합니다. 조건부 블록 (예 : #ifdef ... #endif)을 사용하면 작동한다는 것을 알았을 때만이를 사용하고 (반드시이를 테스트 한 경우) 리턴 주소를 읽으십시오. 스택에서 (인라인 어셈블리 언어가 필요할 수도 있고 필요하지 않을 수도 있음).

로그 파일에 인수를 저장하면 유용하거나 유용하지 않을 수 있습니다.

주변 코드가 무엇인지 아는 경우 테스트 하여 코드가 깨져 있는지 확인하십시오. 이것은 작업하는 코드를 리팩토링하는 가장 간단하고 비용 효율적인 방법이며, 작업중인 코드의 변경 사항을 개발할 때 먼저 수행해야합니다.

반면에 코드가 무엇인지 모르는 부분을 ​​리팩토링하는 경우 제거하지 마십시오 . 먼저 이해 한 다음 안전하다고 판단되면 리팩토링하십시오 (리팩토링이 시간을 올바르게 사용한다고 결정할 수있는 경우에만).

이제 '죽은'코드가 실제로 아무 것도 연결되어 있지 않은 상황이있을 수 있습니다 (내가 직접 봤다는 것을 알고 있습니다) . 계약자가 개발 한 코드 라이브러리와 같이 앱이 제공 된 직후에 사용되지 않아 실제로 구현되지 않은 코드 라이브러리와 같은 이유는 무엇입니까? (예, 구체적인 예가 있습니다. 어떻게 알았습니까?)

나는 개인적 으로이 코드를 모두 없애 버렸지 만이 변경이 잠재적으로 영향을 줄 수 있는 코드의 양에 따라 (당신이 뭔가 간과했을 가능성이 항상 있기 때문에) 가볍게 복용하지 않는 것이 큰 위험입니다. 이 고대 레거시 코드를 제거하면 응용 프로그램이 중단되는지 확인하기 위해 매우 신중하고 공격적인 단위 테스트를 실행해야합니다.

이제 모든 것을 말하면, 그런 코드를 제거하려고 시도하는 시간이나 정신이 가치 가 없을 것입니다. 응용 프로그램에 심각한 문제가되지 않는 한 (예 : 응용 프로그램 팽창으로 인해 보안 검색을 완료 할 수없는 이유는 무엇입니까? 왜 그래도 예제가 있습니까?) 그렇지 않으면 권장하지 않습니다. 그러한 상황에서 코드가 실제로 썩기 시작했습니다.

간단히 말해-코드의 기능을 알고 있다면 먼저 테스트하십시오. 그렇지 않으면 아마 그대로 둘 수 있습니다. 당신은 당신이 알고있는 경우에 할 수없는 혼자두고, 변경 사항을 구현하기 전에 적극적으로 변화를 테스트하는 시간을 바칩니다.

이 경우 항상 업계 표준이라고 생각한 나의 접근 방식은 이상하게도 언급되지 않았습니다.

두 번째 눈을 얻으십시오.

"사용되지 않는 코드"에는 여러 종류가 있으며 어떤 경우에는 삭제가 적절하고, 다른 경우에는 리팩토링해야하며, 다른 경우에는 가능한 한 멀리 돌아가서 다시 돌아 보지 않아도됩니다. 당신은 그것이 어느 것인지 알아 내야하며, 그렇게하려면 두 번째 경험이있는 사람과 가장 잘 어울립니다! -개발자, 코드베이스에 매우 익숙한 개발자. 이를 통해 불필요한 실수의 위험을 크게 줄이고 코드베이스를 유지 관리 가능한 상태로 유지하기 위해 필요한 개선 작업을 수행 할 수 있습니다. 이 작업을 수행하지 않으면 코드베이스에 대해 잘 알고있는 개발자가 부족할 수 있습니다.

로깅 접근법도 보았습니다. 더 정확하게 말하자면 로깅 코드를 보았습니다 .10 년 동안 더 많은 죽은 코드가 남아 있습니다. 로깅 기능은 전체 기능을 제거하는 것에 대해 이야기하고 있지만 작은 데드 코드를 제거하는 것은 아닙니다.

질문에 대한 간단한 대답은 이해하지 못하는 코드를 안전하게 삭제할 수 없다는 것입니다. 여기에는 코드가 어떻게 호출되는지 이해하지 못하는 것이 포함됩니다. 약간의 위험이 있습니다.

피할 수없는 위험을 완화하는 최선의 방법을 판단해야합니다. 다른 사람들은 로깅에 대해 언급했습니다. 물론 로깅은 사용되었음을 증명할 수 있지만 그렇지 않다는 것을 증명할 수는 없습니다. 데드 코드의 주요 문제점은 유지 보수된다는 것이므로, 데드 코드로 의심되는 내용을 추가하지 않고 주석을 추가하지 않아도됩니다.

코드가 소스 제어하에있는 경우 언제든지 코드가 추가 된시기를 확인한 후 호출 방법을 결정할 수 있습니다.

궁극적으로, 당신은 그것을 이해하거나 홀로 남겨 두거나 기회를 얻습니다.

문제의 코드 개발자가 여전히 사용 가능한 경우 코드 제거를 검토하십시오 . 또한 코드에서 주석을 읽으십시오 .

적절한 설명,이 코드가 추가 된 이유 및 어떤 기능을 제공하는지 알 수 있습니다. 특정 사용 사례를 쉽게 지원할 수 있거나 실제로 필요하지 않은지 판단 할 충분한 전문 지식이 없을 수도 있습니다. 극단적 인 경우, C 프로그램에서 사용 가능한 모든 명령문을 제거하고 문제점을 발견하지 못할 수 있습니다 (메모리가 부족하면 몇 분이 걸릴 수 있음).

코드 작성자가 당신 옆에 앉아 있으면 정말 나쁜 문화이지만, 그가 잘못된 코드를 작성한다는 확신이 있기 때문에 말할 이유가 없습니다. 물론 그는 주석에 임의의 단어를 쓰므로 시간을 낭비하지 않아도됩니다.

코드에 주석을 작성하는 가장 중요한 이유 중 하나는 왜 이런 식으로 구현되었는지 설명하는 것입니다. 솔루션에 동의하지 않을 수도 있지만 문제를 고려해야합니다.

저자와의 토론은 또한 코드가 제거되었거나 완료되지 않은 것의 역사적 잔재이므로 삭제해도 안전하다는 것을 알 수 있습니다.

Markus Lausberg의 첫 번째 요점에 강력하게 동의합니다. 도구를 사용하여 코드를 분석해야합니다. 원숭이 뇌는 이런 종류의 임무를 신뢰해서는 안됩니다 !!

대부분의 표준 프로그래밍 언어는 IDE 및 "모든 사용에 대한 찾기"기능을 갖춘 IDE 및 모든 종류의 IDE에 사용될 수 있습니다.이 기능은 이러한 상황에 적합한 도구입니다. (예를 들어 Eclipse의 Ctrl + Shift + G)

물론 : 정적 분석기 도구는 완벽하지 않습니다. 문제의 메소드가 호출되는 결정이 런타임시에만 발생하고 더 빨리 발생하지 않는보다 복잡한 상황을 알고 있어야합니다 (Reflection을 통한 호출, 스크립팅 언어의 "eval"함수 호출 등).

두 가지 가능성 :

1. 99 % 이상의 테스트 범위가 있습니다 . 코드를 삭제하고 완료하십시오.
2. 신뢰할 수있는 테스트 적용 범위가 없습니다. 그에 대한 답변은 지원 중단 경고 를 추가하는 것 입니다. 즉, 제정신을 수행하는 코드를 해당 위치에 추가합니다 (예 : 응용 프로그램의 일상적인 사용과 충돌하지 않는 쉽게 볼 수있는 위치에 경고를 기록). 그런 다음 몇 개월 / 년 동안 끓으십시오. 해당 항목이 발견되지 않은 경우 사용 중단을 예외를 발생시키는 것으로 대체하십시오. 잠시 기다려주세요. 마지막으로 모든 것을 완전히 제거하십시오.