버그 종류를 수정하는 것을 목표로 하세요.

휴대용 퍼스널 컴퓨터
때로는 버그를 수정하고 나면 기분이 좋아질 때도 있습니다. 하지만 상황이 더 악화된 것 같은 느낌이 들 가능성이 높습니다. 버그를 수정하면 코드를 읽기가 좀 더 어려워지고 이해하기가 좀 더 어려워지는 경우가 많습니다. 게다가 버그를 수정하면 실수로 더 많은 버그가 발생할 수도 있습니다.
대부분의 경우 프로그래머가 프로그램의 가능한 모든 런타임 동작을 상상할 수 없기 때문에 버그가 발생합니다. 이러한 처리되지 않은 동작을 극단적인 경우라고도 합니다. 일반적으로 극단적인 경우는 간단한 방법으로 쉽게 해결할 수 있습니다. if 성명서: 이 사건이 발생하면 다른 조치를 취하십시오. 그러나 그렇게 하면 독자가 머리 속에 여러 코드 경로를 시각화해야 하기 때문에 프로그램을 이해하기가 더 어려워질 수 있습니다. 우리가 쌓은 여러 가지 극단적인 경우가 있을 때 상황은 더욱 악화됩니다. if 진술. 일부 관련 코드를 리팩터링할 때가 되면 다음과 같은 코드를 사용하세요. ifs는 리팩토링을 수행해야 하며 이로 인해 회귀 가능성이 높아집니다.
내가 쌓여가는 걸 발견했을 때 if 버그를 수정하기 위한 설명을 작성하면서 프로그램을 더 이해하기 어렵게 만들지 않고 더 많은 버그가 발생할 가능성 없이 문제를 해결할 수 있는 더 좋은 방법이 있는지 자문해 봅니다. 있는 경우 일반적으로 데이터가 모델링되고 처리되는 방식을 리팩터링하는 작업이 포함됩니다. 아래는 그 당시의 일화입니다.
Rescale에서 사용자는 클라우드에서 데스크톱 인스턴스를 시작할 수 있습니다. 이러한 데스크탑은 다음 위치에 있을 수 있습니다. not_started, starting, running, stoppingstopped 상태. 데스크톱과 알려진 최신 상태는 데스크톱을 사용자에게 표시할 때 폴링한 API 끝점에서 반환됩니다.
데스크탑의 로컬 UI 상태와 관련된 버그가 있었습니다. 데스크탑의 상태는 낙관적으로 설정되어 있습니다. stopping 사용자가 데스크톱 중지를 요청할 때. 이는 데스크톱을 중지할 작업을 대기열에 추가하기 위해 메시지를 보내는 중지 요청의 성공 여부에 관계없이 설정되므로 낙관적입니다.
사용자가 데스크톱 목록을 다시 요청하면 API가 반환되는 시간이 있었습니다. running 데스크톱 중지 작업이 여전히 대기열에 있고 아직 실행되지 않았기 때문에 방금 중지하도록 요청된 데스크톱의 경우. UI는 최신 상태로 업데이트되고 사용자는 데스크톱이 다음에서 이동한 것을 볼 수 있습니다. stoppingrunning. 중지 작업이 최종적으로 실행되면 사용자는 다음에서 전환되는 것을 볼 수 있습니다. runningstopping. 봄 stopping 그때 running 그때 stopping 사용자에게 불편한 경험이므로 이 문제를 해결해야 했습니다.
이 문제를 해결하는 방법은 데스크탑이 stopping 상태를 로컬로 지정하고, 그렇다면 상태 업데이트를 건너뛰세요. running. 이것은 "위에 쌓인 것"입니다. if 성명” 접근 방식.
대신 각 데스크톱에 대한 일련의 상태를 유지하기로 결정했습니다. 그런 다음 데스크탑의 목록 API 응답이 돌아올 때마다 각 데스크탑의 최신 상태를 해당 상태 세트에 추가합니다. 일련의 상태를 가져와 사용자에게 적절한 상태를 표시하는 기능이 있습니다. 예를 들어, runningstopping 세트에 있으면 그냥 표시됩니다 stopping하지만 이 함수에는 처리 규칙도 있습니다. startingrunning.
표시되는 상태는 도착한 순서가 아니라 상태 세트의 내용에만 의존하기 때문에 상태 도착 순서가 더 이상 중요하지 않기 때문에 문제가 해결됩니다. 즉, 더 이상 볼 수 없었다. stopping다음, running, 다시 stopping.
이것의 좋은 점은 제가 잊어버린 유사한 문제를 해결했다는 것입니다. 사용자가 데스크탑을 시작할 때 UI는 데스크탑이 현재 위치에 있다는 것을 긍정적으로 보여줍니다. starting 상태이지만 다음 API 호출은 다음과 같이 응답할 수 있습니다. not_started, 사용자는 데스크톱이 다음에서 이동했음을 알 수 있습니다. startingnot_started, 결국에는 다시 starting. 이 문제는 무료로 효과적으로 해결되었습니다.
결론적으로, 버그 수정 작업을 맡게 되면 처음에는 간단한 솔루션이 괜찮아 보일 수도 있지만, 솔루션이 나중에 더 복잡해지게 만드는지 생각해 봐야 합니다. 예를 들어 이전 예에서는 간단한 방법으로 두 경우를 모두 해결할 수 있었습니다. if 진술. 하지만 상태가 변경되는 데 문제가 있는 경우 stoppedstopping, 그러면 다른 프로그래머가 다른 프로그래머를 추가하도록 권장될 수 있습니다. if 성명. 때로는 버그뿐만 아니라 문제가 나타내는 버그 클래스를 해결하는 데 시간을 좀 더 투자하는 것이 가치가 있습니다.

비슷한 게시물