경고 및 통지를 피하는 것이 좋습니다?

필자는 이미 실제 프로덕션 환경에있는 많은 프로젝트에서 작업하기 때문에 일반적으로 PHP 경고 및 알림 작업을 해왔습니다. 이제 라이브 프로덕션 웹 사이트에서 경고 및 알림을 켜면 과부하가 발생합니다.

집에서, 현지에서 작업하는 프로젝트는 일반적으로 모든 경고와 알림을 없애려고 노력합니다. 때로는 통지가없는 해결책이 없기 때문에 통지를 완전히 끄기로 결정할 때까지 통지를보고해야합니다.

결국, 나는 모든 경고와 통지를 없애려고 시간을 낭비하고 있는지 또는 실제로 더 큰 이익을 위해 이것을하고 있는지 모르겠습니다.

따라서 내 질문은 경고와 통지를 모두 피하는 것이 좋은 습관입니까, 아니면 실제로 중요하지 않습니까?

php warnings

— 오디 말로
소스

"때로는 통지를받지 못하는 해결책이 없습니다"PHP를 사용한 지 얼마되지 않았지만, 통지 / 경고를 피하거나 적어도 로 로컬에서이를 억제@ 할 수있는 경우에 대해서는 생각 나지 않습니다 .

— 코드 InChaos

내가 본 가장 설득력있는 주장은 "이러한 메시지는 이유가 있기 때문에 존재합니다. 경고의 홍수를 무시하도록 스스로를 조절하면 피할 수있는 실제 문제를 간과 할 수 있습니다." 다시 말해서, 정상 작동 중에 경고 나주의가 없다면, 경고 나주 의는 잠재적 인 문제의 징후입니다. 모든 것이 소음 일 경우 SHTF 이후 (그리고 아마도 고객이 수행 한 이후)에만 문제를 알리기 시작합니다.

— Piskvor

일반적으로 @를 사용하여 알림을 억제하는 것은 일반적으로 나쁜 것으로 간주됩니다. 잠재적 인 문제를 숨 겼기 때문에 모든 알림을 끄는 것이 더 나쁩니다. 15 년 동안의 PHP 프로그래밍에서 나는 내가 제어하는 코드에서 통지를 억제 해야하는 경우를 아직 보지 못했습니다.

— Cerad

당신은 단순히 이러한 통지의 표시를 끄고 error_reporting(0);있습니까? 난 항상 사용 error_reporting(E_ALL);및 개발과 생산 사이의 유일한 차이점은 ini_set('display_errors', 'on');대 ini_set('display_errors', 'off');. 나는 항상 코드가 마음에 새기는 동안 통지 및 경고를 수정하는 것을 목표로합니다. 프로덕션 시스템의 로그를 자주보고 누락 된 추가 경고 및 알림이 있는지 확인합니다.

— MonkeyZeus

@Cerad가 말한 것에 매우 동의합니다 @. 몇 년과 몇 년 동안 PHP 프로그래밍을 한 후에는 그 연산자를 사용하지 않았습니다. 한 번도 아닙니다. 못. 잠재적 인 문제를 숨길뿐만 아니라 성능에 영향을 미칩니다. 배후에서 PHP는 코드를 호출하기 전에 오류보고를 끄고-> 코드를 호출합니다-> 원래 값으로 다시 설정합니다. @코드에 수십 또는 수백 개의 코드 가 있는 경우 이러한 단계는 비용이 많이 듭니다 .

— Radu Murzea

답변:

이 라이브 프로덕션 웹 사이트에서 경고 및 알림을 켜면 과부하됩니다.

개발, 테스트 및 QA에서 항상 경고를 설정해야하지만 프로덕션에서는 그렇지 않습니다. 실제로, 그것이 dogfooding 응용 프로그램, 즉 당신이 사용하는 응용 프로그램이라면, 그것들을 프로덕션에서 켜야합니다.

기본적으로 : 자신을보고있는 사람이 자신에 대해 무언가를 할 수있는 위치에있는 경우이를 설정해야합니다 (개발 및 테스트 개발자가 직접 문제를 해결할 수 있고 QA의 테스터가 버그를 신고 할 수 있음) 또한 사용자는, 그는 또한) 생산에 문제를 해결할 수 있지만 하지 않는 보는 사람도) 어떻게 프로그램 모르는 그들에 대해 아무것도 (생산의 사용자를 할 수없는 경우에 그들을 켜십시오.

이상적으로는 경고를 오류로 취급하도록 설정하고 싶지만 ;-)로 시작할 필요가없는 경우에만 작동하지만 목표로 명심하십시오! 파일 단위로이 기능을 켜거나 끌 수 있으면 모든 새 파일에 대해 파일을 켜고 경고없는 모든 파일에 대해 파일을 켜고 한 번 켜진 후에는 다시 끄지 마십시오 .

그렇다면 과부하에 대해 어떻게해야합니까?

모든 경고 및주의 사항 목록을 작성한 후 다음 규칙을 준수하십시오.

절대 어떤 상황에서도 목록에 새로운 경고를 추가하지 마십시오. 모든 커밋 코드의 모든 새로운 조각, 모든 편집, 모든 변경, 모든 패치, 안 새 경고를 소개합니다, 그것은 오직 수 있습니다 해결 을.
코드를 만질 때마다 해당 코드의 모든 경고를 수정하십시오. (보이 스카우트 규칙 : 캠프장을 찾은 것보다 항상 더 좋은 상태로 두십시오.) 그렇게하면 중요하지 않은 코드는 경고로 가득 차있을 수 있지만 중요한 코드는 시간이 지남에 따라 더 깨끗해집니다. "코드 조각"은 함수, 클래스, 파일 일 수 있습니다. 하나 이상의 경고를 수정하기 위해이 규칙을 완화 할 수도 있습니다. 요점은 : 당신이 그들을 찾을 때 그들을 수정합니다.

참고 :이 두 가지 모두 일종의 로그 데이터베이스 및 로그 필터링 메커니즘이 필요합니다. 또한 "로그 데이터베이스"및 "로그 필터링 메커니즘"은 텍스트 파일 일 수 있습니다 grep.

이것은 중요한 부분입니다. 데이터베이스가 없으면 새 경고를 추가 할 때를 알 수 없으며 필터링하지 않으면 여전히 과부하 문제가 있습니다.

참고 # 2 : 이것은 경고에만 적용되는 것이 아니라 스타일 검사기, 복잡성 메트릭, 코드 적용 범위, 정적 분석 도구 등에서도 작동합니다. 원래:

새로운 문제를 추가하지 마십시오.
당신이 그들을 우연히 발견으로 오래된 문제를 해결합니다.

이를 통해 쉽게 우선 순위를 정할 수 있습니다. 자주 편집되므로 읽기 쉽고 유지 관리하기 쉬운 코드는 시간이 지남에 따라 더 좋아집니다. 자주 다루지 않는 코드는 더 나아지지는 않지만 어쨌든 아무도 볼 필요가 없기 때문에 괜찮습니다. 그리고 적어도 그것은 나 빠지지 않을 것입니다.

물론, 경고를 사냥하고 죽이는 것 외에는 아무것도하지 않기 위해 특별히 시간을 할당하는 데 방해가되지 않습니다. 이것은 종종 경제적으로 실행 가능하지 않으며이를 염두에 두는 것은 엔지니어로서의 일입니다. "엔지니어는 1 달러로 만들 수있는 사람이며, 어떤 바보도 2로 만들 수 있습니다."

— 요 르그 W 미타 그
소스

필터링되지 않은 사용자에게 도달하는 경고 및 오류를 해제하는 또 다른 요점 : 경고는 개발자에게 중요한 정보이므로 민감한 정보 (파일 이름, 다른 관련 서버 이름, 사용 된 SQL 쿼리 구조 등)가 유출 될 수 있습니다. )

— Hagen von Eitzen 2016 년

프로덕션 경고는 사용자가 아닌 로그로 이동해야합니다! 오류 는 사용자가 아닌 로그로 이동해야합니다. 오류를 포착하지 않고 기록하고 사용자에게 적합한 오류 페이지를 제공하는 웹 사이트는 제작 준비가되어 있지 않습니다. PHP는 이것을 잘못하는 것을 매우 쉽게 만들어 주지만 여전히 올바르게해야합니다.

— 홉

코드에서 경고 및 알림이 오는 경우 가장 확실하게 수정하십시오. 내 경험에 따르면 95 %에서는 양성일 수 있지만 5 %는 쫓는 데 많은 시간이 걸리는 실제 문제를 강조합니다.

어떤 이유로 든 써드 파티 코드에서 가져온 것이면 일반적으로 선택의 여지가 없습니다.

레거시 코드베이스가 실제로 큰 경우 다른 질문입니다. 레거시 코드를 타사로 취급 할 수 있지만 새 코드에는 경고가 필요 없습니다.

— 알렉산더 포그 렙 냐크
소스

나는 분명히 PHP와는 다른 Java / Eclipse에서 일하지만 일반적으로 1) 컴파일하는 것이지만 명백한 실수를 저지른 것 또는 2) 지금은 괜찮지 만 길을 나쁘게 만드는 것에 의해 경고가 발생한다는 것을 알았습니다.

— corsiKa

@corsiKa 귀하의 의견을 PHP 로 번역하고 있었지만 한 단어 만 변경하면됨을 깨달았습니다.

— wizzwizz4

물론, 이러한 경고가 귀하의 using진술서 주문에 관한 StyleCop으로부터 온 것이 아니라면

— Dan Pantry

그것은 중요. 경고는 테스트를 중단하지 않거나 한동안 야생에 나타날 수도 있지만, 버그가 발생할 수 있습니다. 저는 현재 C # / C ++에서 주로 개발하고 코드 기반에서 경고를 제거하고 제거하는 정의 된 전략을 가지고 있습니다. 운 좋게도 그것은 로켓 과학이 아닙니다 =).

작업중인 언어에 경고를 오류로 처리 할 수 있고 다양한 경고 수준이있는 경우 다음을 수행합니다.

경고가 표시되지 않도록 경고 수준을 충분히 낮추십시오. 경고 수준이 가장 낮고 여전히 경고가 표시되면 수정하십시오. 당신이 그들을 고칠 수 없다면, 당신은 지금 끝난 것이지만, 당신 이 고칠 수 있기를 바랍니다. 큰.
이제 경고가 거의 없으므로 (낮은 경고 수준에서) 스위치를 뒤집고 모든 경고를 오류로 처리하십시오.
경고 수준을 높이고 모든 새 경고를 수정하십시오. 할 수 없다면 경고 레벨을 다시 낮추십시오. 그러나 경고를 오류로 취급하지 마십시오.

나는 이것이 내 코드에서 경고를 작동시킬뿐만 아니라 경고를 유지 한다는 것을 알았다 .

— 페리 C
소스