태그 보관물: clean-code

clean-code

입력되지 않은 것처럼 보이는 코드를 어떻게 안전하게 삭제합니까? 때문에 복잡하고 시간이

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

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

  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을 참조 하십시오.