JavaScript로 비디오 플레이어를 만들고 있다고 상상해보십시오. 이 비디오 플레이어는 재귀 기능을 사용하여 사용자의 비디오를 반복적으로 반복하므로 브라우저가 too much recursion RangeError때때로 트리거합니다 .

아마도 아무도 루프 기능을 많이 사용하지 않을 것입니다. 사용자가 응용 프로그램을 일주일 동안 반복 한 후에도 응용 프로그램에서이 오류를 발생시키지 않지만 여전히 존재합니다. 문제를 해결하려면 응용 프로그램에서 루핑이 작동하는 방식을 다시 디자인해야하는데 상당한 시간이 걸립니다. 너 뭐하니? 왜?

• 버그 수정

• 버그를 떠나

사람들이 걸려 넘어지는 버그만 수정해서는 안됩니까? 버그 수정은 언제 과잉이됩니까?

편집하다:

실제 버그를 유발하지 않는 재귀 적 접근이 문제가되는 경우 플레이어가 비디오를 반복 할 때마다 변수가 증가한다고 가정합니다 1. 2 ⁵³ 루프 후이 변수는 오버 플로우되며 프로그램은 예외를 처리하여 변수를 처리 할 수 ​​없습니다.

실용적이어야합니다.

실제 상황에서 오류가 발생하지 않고 수정 비용이 높으면 많은 사람들이 오류를 수정하기 위해 리소스를 잘 사용한다고 생각하지 않을 것입니다. 이를 바탕으로 남겨 두겠다고 말하지만 몇 달 안에 해킹이 문서화되었는지 확인하십시오 (마지막 단락 참조).

즉,이 문제를 "학습 경험"으로 사용해야하며 다음에 루핑을 할 때 재귀 루프를 불필요하게 사용하지 마십시오.

또한 해당 버그 보고서를 준비하십시오. 우수한 최종 사용자가 한계를 극복하고 결함을 발견하는 데 얼마나 놀랐는지 알게 될 것입니다. 최종 사용자에게 문제가된다면 문제를 해결해야합니다. 그러면 해킹을 문서화하게되어 기쁩니다.

Windows 95에는 49.7 일 후에 컴퓨터가 충돌 하는 비슷한 버그가있었습니다 . 어쨌든 Win95 시스템은 그다지 오래 유지되지 않았기 때문에 출시 후 몇 년 만에 주목되었습니다. 따라서 한 가지 중요한 점이 있습니다. 버그는 다른 더 중요한 버그와 관련이 없을 수 있습니다.

당신이해야 할 것은 인 위험 평가 전체 프로그램과에 대한 영향 평가 개별 버그.

• 이 소프트웨어는 보안 경계에 있습니까?
• 그렇다면이 버그로 인해 악용 될 수 있습니까?
• 이 소프트웨어는 의도 된 사용자에게 "미션 크리티컬"입니까? ( Java EULA에서 사용을 금지 한 사항 목록 참조 )
• 버그로 인해 데이터가 손실 될 수 있습니까? 재정적 손실? 명성 손실?
• 이 버그가 발생할 가능성은 얼마나됩니까? (시나리오에 이것을 포함 시켰습니다)

등등. 이 버그에 영향을 선별 , 수정 된 버그를 결정하는 과정을. 거의 모든 배송 소프트웨어에는 수정하기에 아직 중요하지 않은 사소한 버그 목록이 아주 많습니다.

다른 답변은 이미 훌륭하며 귀하의 예가 단지 예일 뿐이라는 것을 알고 있지만 아직 논의되지 않은이 과정의 큰 부분을 지적하고 싶습니다.

가정을 식별 한 다음 모퉁이와 비교하여 가정을 테스트해야합니다.

귀하의 예를 보면 몇 가지 가정이 있습니다.

• 재귀 접근 방식은 결국 오류를 발생시킵니다.
• 동영상이 스택 한도에 도달하는 데 너무 오래 걸리기 때문에이 오류가 표시되지 않습니다.

다른 사람들이 첫 번째 가정에 대해 논의했지만 두 번째 가정을 살펴보십시오. 내 비디오가 1 초 길이에 불과하면 어떻게 되나요?

그리고 아마도 그것은 매우 일반적인 사용 사례가 아닐 수도 있습니다. 그러나 아무도 매우 짧은 비디오를 업로드 하지 않을 것이라고 정말로 확신 하십니까? 당신은 비디오가 최소 지속 시간이라고 가정하고 있으며 아마도 당신이 아무것도 가정하고 있다는 것을 깨닫지 못했을 것입니다! 이 가정이 응용 프로그램의 다른 위치에 다른 버그를 일으킬 수 있습니까?

알 수없는 가정은 버그의 큰 원인입니다.

내가 말했듯이, 나는 당신의 예가 단지 예일 뿐이라는 것을 알고 있지만, 당신의 가정을 식별하고 (이것은 종종 들리는 것보다 어려운)이 가정에 대한 예외를 생각하는이 과정은 당신의 시간을 어디에서 보낼 것인지 결정하는 데 큰 요소입니다.

"내가 결코 일어나지 않을 것이기 때문에이 문제에 대해 프로그램 할 필요가 없다"고 생각한다면, 그 가정을 실제로 조사하기 위해 약간의 시간이 걸린다. 당신은 종종 원래 생각했던 것보다 더 일반적인 코너 케이스를 생각할 것입니다.

즉, 이것이 무용지물이되는 시점이 있습니다. JavaScript 응용 프로그램이 TI-89 계산기에서 완벽하게 작동하는지 신경 쓰지 않아도되므로 시간을 낭비하는 것만 낭비됩니다.

다른 답변은 이미 이것을 다루었지만 "이것은 중요하다"와 "이것은 시간 낭비입니다"사이의 줄을 찾는 것은 정확한 과학이 아니며, 그것은 하나와 완전히 다를 수있는 많은 요소에 달려 있습니다 사람이나 회사를 다른 사람에게.

그러나 그 과정의 큰 부분은 먼저 가정을 파악한 다음 그 가정에 대한 예외를 인식하려고합니다.

다음 논문을 읽는 것이 좋습니다.

신뢰성과 위협 : 분류법

무엇보다도 프로그램에서 발생할 수있는 다양한 유형의 오류에 대해 설명합니다. 설명한 내용을 휴면 결함 이라고 하며이 백서에서는 다음과 같이 설명합니다.

오류가 발생하면 오류가 활성화되고 그렇지 않으면 휴면 상태입니다. 활성 결함은 a) 이전에 휴면 상태이고 계산 프로세스 또는 환경 조건에 의해 활성화 된 내부 결함 또는 b) 외부 결함입니다. 결함 활성화는 휴면 결함을 활성화시키는 구성 요소에 입력 (활성화 패턴)을 적용하는 것입니다. 대부분의 내부 결함은 휴면 상태와 활성 상태 사이에서 순환합니다.

이것에 대해 설명하면 모두 비용-이익 비율로 요약됩니다. 비용은 세 가지 매개 변수로 구성됩니다.

• 문제가 얼마나 자주 발생합니까?
• 결과는 어떻습니까?
• 개인적으로 얼마나 귀찮게합니까?

처음 두 가지는 중요합니다. 푸른 달에 한 번 나타나고 아무도 신경 쓰지 않는 버그이거나 완벽하고 훌륭하고 실용적인 해결책이 있다면 버그를 알려진 문제로 안전하게 문서화하고 더 도전적이고 더 진행할 수 있습니다 중요한 작업. 그러나 버그로 인해 돈 거래가 실패하거나 긴 등록 프로세스를 중단하여 최종 사용자를 실망 시키면 조치를 취해야합니다. 세 번째 매개 변수는 내가 강력히 권장하는 것입니다. Vito Corleone의 말에서 :

개인적이 아닙니다. 사업입니다.

당신이 전문가라면, 감정을 제쳐두고 최적의 행동을하십시오. 그러나 작성하는 응용 프로그램이 자신의 취미라면 감정적으로 관련되어 있으며 세 번째 매개 변수는 버그 수정 여부를 결정하는 데있어 유효합니다.

이 버그는 누군가가 24 시간 연중 무휴 회사 프레젠테이션을 실행하는 로비 화면에 플레이어를 배치 할 때까지만 발견되지 않습니다. 그래서 여전히 버그입니다.

당신은 무엇에 대한 답변 입니까? 실제로 엔지니어링 결정이 아닌 비즈니스 결정입니다.

• 버그가 사용자의 1 %에게만 영향을 미치고 플레이어가 다른 20 %에 필요한 기능에 대한 지원이 부족한 경우 선택이 분명합니다. 버그를 기록한 다음 계속하십시오.
• 버그 수정이 할 일 목록에 있으면 새 기능을 추가하기 전에 수정하는 것이 좋습니다. 무결점 소프트웨어 개발 프로세스의 이점을 누릴 수 있으며, 목록에 포함되어 있기 때문에 많은 시간을 허비하지 않습니다.

특히 대기업 (또는 대기업)에는 무엇을해야 할지를 결정하는 실질적인 방법이 있습니다.

수정 비용이 수정으로 인한 수익보다 큰 경우 버그를 유지하십시오. Viceversa 수정 프로그램이 비용보다 더 많이 반환되면 버그를 수정하십시오.

샘플 시나리오에서는 값 비싼 버그를 수정하는 대신 새로운 기능을 개발할 경우 얼마나 많은 사용자를 잃을 것으로 예상되는지에 따라 다릅니다.

tl; dr 이것이 이유 RESOLVED/WONTFIX입니다. 과도하게 사용하지 마십시오. 조심하지 않으면 기술 부채가 쌓일 수 있습니다. 이것이 디자인에 근본적인 문제입니까, 앞으로 다른 문제를 일으킬 가능성이 있습니까? 그런 다음 수정하십시오. 그렇지 않으면? 우선 순위가 될 때까지 그대로 두십시오.

설명하는 상황에는 실제로 세 가지 오류가 있습니다.

1. 기록 된 모든 오류를 평가하는 프로세스가 부족합니다 (티켓 / 백 로그 / 사용중인 시스템에 오류를 기록 했습니까?). 수정 여부를 결정합니다. 이것은 관리 결정입니다.

2. 팀에 기술이 부족하여 이와 같은 잘못된 솔루션을 사용하게됩니다. 향후 문제를 피하기 위해이 문제를 해결하는 것이 시급합니다. (실수에서 배우기 시작하십시오.)

3. 오랜 시간이 지난 후 비디오 표시가 중단 될 수있는 문제입니다.

세 가지 오류 중 (3) 만 수정하지 않아도됩니다.

여기에 버그를 남기지 않고 수정되는 버그 비용을 평가하는 것에 대한 많은 답변이 있습니다. 모두 좋은 조언이 포함되어 있지만 버그 비용이 종종 과소 평가되거나 아마도 과소 평가되고 있다고 덧붙이고 싶습니다. 그 이유는 기존의 버그가 지속적인 개발과 유지를 위해 물을 흐트러 뜨리기 때문입니다. 테스터가 새로운 버그 를 찾으려고 소프트웨어를 탐색하는 동안 몇 가지 "수정하지 않는"버그를 추적 하게하면 작업 속도가 느려지고 오류가 발생하기 쉽습니다. 최종 사용자에게 영향을 미치지 않는 몇 가지 "수정하지 않는"버그는 계속 개발 속도를 늦추고 결과는 더 나빠질 것입니다.

몇 년 동안 코딩에서 배운 한 가지는 버그가 다시 발생한다는 것입니다. 최종 사용자는 항상이를 발견하고 다시보고합니다. 버그 수정 여부는 "단순히"우선 순위 및 마감일입니다.

우리는 하나의 릴리스에서 수정에 반대하는 주요 버그 (내 의견으로는 주요)를 가지고 있으며, 최종 사용자가 반복해서 넘어 졌기 때문에 다음 릴리스의 쇼 스토퍼만이되었습니다. 그 반대의 경우도 마찬가지입니다. 우리는 아무도 사용하지 않는 기능의 버그를 수정하도록 강요 당했지만 경영진이 쉽게 볼 수있었습니다.

여기에는 세 가지가 있습니다.

원칙

이것은 동전의 한면입니다. 어느 정도 까지도 아무도 알아 채지 못하더라도 버그 (또는 "작동"하더라도 잘못된 구현)를 고치는 것이 좋다고 생각 합니다.

이런 식으로보세요 : 실제 문제는 반드시 버그 일 필요는 없지만, 프로그래머가 이런 방식으로 루프를 구현하는 것이 처음에는 좋은 아이디어라고 생각했습니다. 첫 번째 순간부터 이것은 좋은 해결책이 아니라는 것이 분명했습니다. 이제 두 가지 가능성이 있습니다.

• 프로그래머는 방금 눈치 채지 못했습니다. 글쎄 ... 프로그래머는 코드가 어떻게 실행되는지 직관을 개발해야합니다. 재귀는 매우 어려운 개념과는 다릅니다. 그는 버그를 수정하고 (추가 작업을 모두 땀으로 흘림) 미래의 추가 작업을 피하기 위해 무언가를 배우고 기억할 수 있습니다. 그 이유가 시간이 충분하지 않았기 때문에 경영진은 프로그래머 가 고품질 코드를 작성 하는 데 더 많은 시간 이 필요 하다는 것을 알게 될 것입니다 .

• 프로그래머는 알아 차 렸지만 "문제가 아님"으로 간주했습니다. 이것이 견딜 수 있다면 laissez-faire의 문화가 개발되어 궁극적으로 실제로 상처를주는 버그로 이어질 것입니다. 이 특별한 경우에, 누가 관심을 갖습니다. 그러나 그 프로그래머가 다음에 은행 응용 프로그램을 개발하고 특정 별자리가 발생하지 않기로 결정하면 어떻게 될까요? 그럼 그렇습니다. 나쁜 시간.

프래그머티즘

이것은 다른 쪽입니다. 의 물론 당신은 가능성이 특정한 경우에, 버그를 수정하지 않을 것입니다. 그러나 조심하십시오-실용주의가 있고 실용주의가 있습니다. 좋은 실용주의는 문제에 대한 신속하면서도 견고하고 잘 확립 된 해결책을 찾는 것입니다. 즉, 과도하게 디자인하는 것을 피하지만 실제로 구현하는 것은 여전히 ​​잘 생각됩니다. 나쁜 실용주의는 단지 "그렇게 작동하는"무언가를 해킹하고 첫 번째 기회에서 깨질 때입니다.

빨리 실패, 열심히 실패

의심스러운 경우 빨리 실패하고 열심히 실패하십시오.

이것은 무엇보다도 코드 가 환경이 아니라 오류 조건을 감지 한다는 것을 의미 합니다.

이 예제에서는 사용자가 할 수있는 어려운 예외로 대체하여 하드 런타임 오류 ( "스택 깊이 초과"등)가 발생하지 않도록하는 것이 가장 좋습니다. 예를 들어, 전 세계 카운터를 보유하고 1000 개의 비디오 이후에 구제 할 것을 임의로 결정할 수 있습니다. 그런 다음 해당 예외 (일반적인 예외 (예 : RuntimeExceptionJava 또는 JavaScript 또는 Ruby의 간단한 문자열))에 의미있는 메시지를 제공하십시오. 새로운 유형의 예외 또는 특정 프로그래밍 언어에서 수행하는 모든 것을 만들기 위해 어느 정도까지 갈 필요는 없습니다.

이런 식으로, 당신은

• ... 코드 내부의 문제를 문서화했습니다.
• 결정적인 문제가되었습니다. 당신 은 당신의 예외가 일어날 것이라는 것을 알고 있습니다. 기본 브라우저 기술 (PC 브라우저뿐만 아니라 스마트 폰, 태블릿 또는 미래 기술도 고려)에 변화가 있습니다.
• ... 결국 고칠 필요가있을 때 쉽게 고칠 수 있습니다. 문제의 근원은 당신의 메시지에 의해 지적되며, 당신은 의미있는 역 추적을 얻을 것입니다.
• ... 실제로 "실제"오류 처리를 수행하는 데 시간이 낭비되지 않았습니다 (오류가 발생할 것으로 예상하지 마십시오).

내 규약은 이러한 오류 메시지 앞에 "Paranoia :"라는 단어를 붙이는 것입니다. 이것은 저와 그 밖의 모든 사람들에게 그 오류가 발생 하지 않을 것이라는 분명한 표시 입니다. "실제"예외와 명확하게 구분할 수 있습니다. GUI 나 로그 파일에서 이와 같은 것을 본다면, 나는 진지한 문제가 있음을 알고 있습니다. 결국 전혀 일어날 것으로 예상하지 못했습니다. 에 이 (필자는 문제가 발생한 정확한 위치를 알고있는 의사 디버깅을 많이에서 저를 저장, 신속하고 오히려 쉽게 해결 할 수있는 좋은 기회) 점 I는 위기 모드로 이동합니다.

내 직장의 선임 개발자 책상에 포스트잇

누구에게 도움이 되나요?

나는 그것이 종종 사고 과정의 좋은 출발점이라고 생각합니다. 항상 수정하고 개선해야 할 것이 많이 있지만 실제로 얼마나 많은 가치를 추가하고 있습니까? ... 사용성, 신뢰성, 유지 관리 성, 가독성, 성능 또는 기타 측면에 관계없이.

세 가지가 생각납니다.

먼저 , 코드에 버그를 남기는 결정을 책임감있게 수행하기 전에 식별 된 버그의 영향을 철저히 조사해야합니다. (귀하의 예에서 나는 끊임없이 증가하는 스택이 나타내는 메모리 누수에 대해 생각했으며 매번 재귀 할 때마다 브라우저가 느리고 느려질 수 있다고 생각했습니다.)이 철저한 조사는 종종 버그 수정보다 시간이 오래 걸리므로 수정하는 것을 선호합니다 대부분의 경우 버그.

둘째 , 버그는 처음에 생각하는 것보다 더 큰 영향을 미치는 경향이 있습니다. 이것은 "정상적인"사례이기 때문에 작업 코드에 매우 익숙합니다. 반면에 버그는 "예외"입니다. 물론, 우리 모두는 많은 버그를 보았지만 전반적인 작업 코드가 더 많았습니다. 따라서 버그가있는 코드의 작동 방식보다 작동 코드의 작동 방식에 대한 경험이 더 많습니다. 워킹 코드와 어떤 상황에서 어떤 일을하는지에 대한 책이 많이 있습니다. 버그가있는 코드의 동작에 대해서는 거의 없습니다.

그 이유는 간단합니다. 버그는 질서가 아니라 혼돈 입니다. 그들은 종종 질서의 흔적을 남겼습니다 (또는 다른 방법으로 정리하십시오 : 그들은 질서를 완전히 파괴하지 않습니다). 그러나 그들의 버그가있는 성격은 프로그래머가 원하는 질서의 파괴입니다. 혼돈 자체는 정확하게 추정되는 것을 무시하는 경향이 있습니다. 버그가있는 프로그램이 더 이상 우리의 정신 패턴에 맞지 않기 때문에 올바른 프로그램이하는 것보다 말하는 것이 더 어렵습니다.

셋째 , 귀하의 예에는 버그를 수정하면 프로그램을 다시 디자인해야한다는 측면이 포함되어 있습니다. (이 부분을 제거하면 대답은 간단합니다. 버그를 수정하십시오. 다시 디자인 할 필요가 없기 때문에 너무 오래 걸리지 않아야합니다. 그렇지 않으면 :) 그런 경우 현재 설계된 방식대로 프로그램에 대한 신뢰를 잃게됩니다. 재 설계는 그러한 신뢰를 회복시키는 방법이 될 것입니다.

말했다 모든 프로그램은 사람들이 사용하는 일이 있고, 다른 곳에서 누락 된 기능 또는 두 번째, 정말 성가신 버그는 버그를 수정 우선 순위를 가질 수 있습니다. 물론 실용적인 방법으로 다른 일을 먼저하십시오. 그러나 버그의 영향에 대한 첫 번째 빠른 평가가 완전히 잘못 될 수 있다는 것을 잊지 마십시오.

낮은 확률 / 가벼운 결과 = 낮은 우선 순위 수정

• 발생 확률이 매우 낮은 경우
• 발생의 결과가 경미한 경우
• 그런 다음 버그는 위협이되지 않으며 우선 순위 수정이 아닙니다.

그러나 이것은 게으른 개발자에게 버팀목이 될 수 없습니다 ...

• "매우 낮은 발생률"이란 무엇을 의미합니까?
• "가벼운 결과"란 무엇을 의미합니까?

발생 확률이 매우 낮고 결과가 경미하다는 것을 나타 내기 위해 개발 팀은 코드, 사용 패턴 및 보안을 이해해야합니다.

대부분의 개발자는 원래 힘든 일이 결코 일어나지 않을 것이라는 사실에 놀랐습니다.

우리의 교육 시스템은 확률과 논리를 잘 가르치지 않습니다. 대부분의 소프트웨어 엔지니어를 포함하여 대부분의 사람들은 논리가 깨졌고 생산성 직관이 깨졌습니다. 실제 문제에 대한 경험과 광범위한 시뮬레이션 경험은이 문제를 해결하는 유일한 방법입니다.

실제 데이터로 직관에 맞서십시오

사용 패턴을 따를 수 있도록 여러 로그를 작성하는 것이 중요합니다. 발생하지 말아야 할 것들의 주장으로 코드를 채우십시오. 그들이하는 것에 놀랄 것입니다. 그렇게하면 직관에 하드 데이터를 대면하고 다듬을 수 있습니다.

경미한 문제와 통제력에 대한 나의 예

전자 상거래 사이트에서 오래 전에 일한 다른 프로그래머가 실수를했습니다. 일부 모호한 조건에서 시스템이 로그에 등록 된 것보다 클라이언트를 1 % 적게 인출했습니다. 회계 시스템의 복원력을 높이기 위해 로그와 계정 공차 간의 차이점을 식별하는 보고서를 작성했기 때문에 버그를 발견했습니다. 차이가 매우 작기 때문에이 버그를 수정 한 적이 없습니다. 차이는 매일 계산되었으며 매월 US $ 2.00보다 낮았습니다. 우리는 1 년 안에 현재의 시스템을 대체 할 완전히 새로운 시스템을 개발하고있었습니다. 매월 미화 2.00 달러의 비용이 들고 적절한 통제 수단이 적용되는 문제를 해결하기 위해 잠재적으로 수익성있는 프로젝트에서 자원을 전환하는 것은 의미가 없습니다.

결론

예, 즉시 수정하지 않아도되며 새로운 기능 개발을 지연시킬만큼 중요하지 않은 버그가 있습니다. 그러나 우리는 우리 자신의 직감을 믿을 수 없기 때문에이 버그가 작은 지 확인하기 위해이 버그의 발생을 제어 할 수 있어야합니다.

나는 이것이 처음부터 잘못된 질문을하고 있다고 생각합니다.

문제는 "이 버그를 수정해야합니까, 아니면이 버그를 수정해서는 안됩니다"는 아닙니다. 모든 개발자는 시간이 제한되어 있습니다. 따라서 문제는 "1 시간, 4 시간 또는 1 주일 동안 할 수있는 가장 유용한 방법"입니다.

해당 버그를 수정하는 것이 가장 유용한 방법이라면 대부분의 사람들이 소프트웨어를 가장 많이 향상시키기 때문에 버그를 수정하십시오. 다른 곳에서 더 많은 개선을 할 수 있거나 사람들이 누락 한 기능을 추가하거나 더 중요한 버그를 수정하여 이러한 다른 작업을 수행 할 수 있습니다. 또한 향후 개발을 더욱 효율적으로 만드는 데 필요한 추가 보너스 포인트.

버그 수정 은 항상 과잉입니다

먼저 버그 부분을 분류 해 봅시다 .

그것은인가 정직한 실수 , 예를 들면 일회성 오류 또는 테스트를 탈출 변수 그림자? 이 경우, 나는 확실히뿐만 아니라 당신이 새로운 단위 테스트를 쓴 문제는 모든 후자가 근처 코드 리팩토링 할 수있는 기회를했다 "고정"할 수 있기를 바랍니다 유용한 작업을 .

그러나 실제로 디자인상의 결함 인 경우 에는 디자인을 재평가 하거나 최악의 경우이 기능을 비활성화 해야합니다.

따라서 문제를 해결 하려고 시도하지 마십시오 .

물론 더 나빠질 수 있습니다 --- 핵 해킹 방법론을 시도 할 수 있습니다. 비디오 루핑은 해킹입니다 (나쁜 아키텍처 및 알려진 손상이 있음). 루프 제한을 추가하여 테스트 한 N 반복 (브라우저 제한보다 낮음) 후에 루프가 종료되도록 할 수 있습니다.

그 결과는 명백합니다. 이제 깨진 코드와 새로운 루프 제한을 모두 지원해야합니다.

극단적 인 견해를위한 PS 사과.

PPS 용어에 대한 참고 사항 : 버그를 "수정"할 수 없습니다. 수의사는 아마 할 수 있지만 거기에 가지 않겠습니다. ;-). 버그가 해결되거나 해결되는 동안 문제가 해결되거나 "수정"됩니다.