최적 공사 실천: 어떻게 오류를 복구합니까?

나는 일련의 문장에서 기본적인 공사 실천을 소개하고 싶다. 가장 중요한 것부터: 어떻게 버그를 복구합니까?
우선, 왜 나는 버그를 복구하는 것이 가장 중요하다고 생각합니까?
오류가 항상 발생하기 때문이다.만약 네가 코드를 쓴다면, 너는 버그를 쓴다.
이것은 근본적으로 문제가 아니다.Repeatable Software Development Process, 우리가 견지하는 것은 이 기초 위에서 일하는 것이다. 사람들은 실수를 할 것이다.
얼마 전에 나는 그것에 관한 글을 한 편 썼다.
중요한 것은: 당신과 다른 사람들이 만든 버그에 어떻게 대처합니까?당신은 장래에 이런 상황이 발생하는 것을 방지하기 위해 어떤 조치를 취할 것입니까?너는 어떻게 이런 상황이 심지어 존재한다는 것을 알았니?

오류 발견

네가 진정으로 어떤 것을 복구하기 전에, 너는 부정확한 행위를 찾아내야 한다.
이것은 매우 까다로울 수 있다.다음 두 가지 상황을 고려합니다.

오류로 인해 모든 사용자가 이 계정에 로그인할 수 없습니다.

로컬 기기에서 사용자의 이상한 행동을 자주 볼 수 있는 사용자만 있다.

어느 것이 더 쉽게 발견할 수 있습니까?나는 네가 맞혔다고 생각한다. 첫 번째.
어떤 버그는 다른 버그보다 더 뚜렷하다.

몇 가지 요소가 결함의 발견성에 영향을 줄 수 있다.

몇 명의 사용자가 이 오류의 영향을 받았습니까?만약 이 숫자가 충분하다면, 틀림없이 누군가가 너에게 알려줄 것이다.사용자를 모니터링 서비스로 사용하는 것이 합리적입니까?이것은 우리가 본문에서 토론하지 않을 또 다른 문제다.

코드는 어디에서 실행됩니까?서버에서 대부분의 의외의 사건을 포착하고 알림을 주는 감시 서비스를 만들기 쉽습니다.생성된 제품에 액세스할 수 없는 경우가 있습니다.예를 들어 자신의 인프라를 사용하는 회사 고객에게 운송될 때.자신의 서버에 고정된 환경을 만드는 것도 훨씬 쉬워야 합니다. 이렇게 하면 어떤 제3자 실체도 당신의 프로젝트를 방해하지 않습니다.

번식이 얼마나 어려운가?몇몇 오류는 복제하기 쉽다.이 링크를 누르고 이 텍스트를 입력한 다음enter 키를 누르십시오.벌레가 미쳤어!특수한 환경을 설정하고 특정한 소프트웨어를 설치하고 이상한 동작을 수행하면 이 버그를 재현할 수 있습니다.특히 일부 버그는 복제할 수 없다.무시할 수 있습니다.

물론, 오류를 발견하고 오류가 발생했을 때 알려줄 수 있는 도구가 있습니다.

Sentry 코드의 오류를 추적하는 데 도움을 줍니다.그것은 거의 모든 언어를 지원하며, 무료 위탁 관리 버전이 있다.그것은 또한 사용자로부터 직접적인 구두 피드백을 수집할 수 있다.

Prometheus는 가장 유행하는 모니터링 도구 중의 하나이다. docker-compose up to jump start를 통해 얻을 수 있습니다.

, NewRelic, Wombat, DataDog 및 기타 많은 서비스와 같은 유료 서비스도 있습니다.

Lifehack: Sentry부터 시작할 수 있습니다. 가장 간단한 설정으로 대부분의 수요를 충족시킬 것입니다.필요할 때 더 많은 서비스와 도구를 추가할 수 있습니다.

오류 보고

일단 오류가 발견되면 보고가 필요하다.쉬워 보이지 않습니까?응, 사실 이것은 보기에는 매우 쉬워 보이지만, 그것은 틀림없이 이 과정에서 가장 중요한 부분이다.좋은 버그를 보고하려면 대량의 정보를 제출해야 합니다.질문은 다음과 같은 내용을 담고 있어야 합니다.

왜 당신은 이것이 버그라고 생각합니까?어쩌면 이것은 기능일지도 몰라...

무슨 일이 일어날 것 같아?명확한 정의가 없는 예상 행위의 버그는 복구하기 어려울 수 있습니다.기능 요청으로 확장할 수 있습니다.이것은 마땅히 다른 방식으로 해결해야 한다.

왜 이 버그가 중요합니까?너는 그것이 즉시 복구되어야 한다는 것을 증명해야 한다.몇몇 버그는 매우 작기 때문에 잠시 무시할 수 있습니다.

문제를 어떻게 재현합니까?이것은 반드시 이 문제에 관한 모든 기술 정보를 포함해야 한다.어떤 버전을 사용했습니까?어떤 브라우저/운영 체제를 사용합니까?어떤 설정을 적용했습니까?때로는 문제의 복사를 표시하기 위해 별도의 저장소를 만들 수도 있다.

로그, 스택 추적, 화면 캡처, 모니터링 보고서, 필요한 입력 데이터, 관련 오류 및 기능 등 추가 정보를 어디서 찾을 수 있습니까? 모든 링크는 제출에 있어야 합니다.그렇지 않으면 시간의 추이에 따라 이 문제를 해결하기 어렵다.

Lifehack: screenshots 및 gifs rock for system with UI!가능한 한 자주 그것들을 사용해라.단, 캡처를 사용하여 창고 추적과 디버깅 출력에서 텍스트 정보를 포획하지 마십시오. 다른 개발자들이 이 정보를 복사할 수 없기 때문입니다.
이제 같은 프로젝트에서 만든 두 개의 다른 버그의 예시를 봅시다.첫 번째는 버전, 거슬러 올라가는 범위에 대한 엄격한 요구이다.It is a good bug report .

The second one was reported by me . 이것은 잘못된 보고의 나쁜 예이다.

그것은 우리가 이전에 정의한 모든 규칙을 거의 위반했다.이것은 바쁜 과정이다. 나와 나의 한 사용자가 휴대전화 통화를 한 후에 이 표를 잊지 마라.그러지 마세요.
다음은 프로젝트에서 사용할 수 있는 실제 오류 보고서templates입니다.

Template for GitHub and open-source

Template for GitLab and commercial software

github-issue-templates repo에는 또 다른 버그 템플릿이 있습니다.당신은 그 중의 어떤 도구를 마음대로 사용하여 당신의 개발 과정을 개선할 수 있습니다!

복제 오류

지금 이 버그를 복사해야 합니다.너의 손뿐만 아니라 너의 코드도 있다.기억해라. 너의 목표는 다시는 같은 실수를 하지 않는 것이다.그게 말이 돼?
너는 a regression test를 써야 실패할 것이다.
단원 테스트나 E2E 테스트일 수도 있습니다. 이것은 중요하지 않습니다.이것은 단지 실패한 테스트일 뿐, 당신이 해결하고자 하는 버그를 폭로했습니다.
Lifehack: 때때로 당신의 지점에 나쁜 코드를 제출하려고 할 수도 있습니다. 그러면 CI 구축을 촉발할 수 있습니다.생성되면 프로젝트에 저장됩니다.너의 동료는 이 문제와 연락할 수 있을 것이다.너의 다음 약속은 반드시 이 문제를 해결해야 한다.

어떤 기구가 당신이 복잡한 오류를 복제하는 것을 도울 수 있습니까?그래, 몇 개 있어.

디버거는 어떤 상황에서도 당신의 가장 친한 친구입니다.

병발 오류를 발견하는 것은 매우 어렵고 때로는 복제하기도 더욱 어렵다.이 경우 static analysis 로 돌아가서 버그를 정적으로 찾을 수 있습니다.

때로는 인프라 시설을 조정해야 할 수도 있다. 이것이 바로 infrastructure-as-code 유용한 곳이다.

일부 버그는 합리적인 시간 내에 복제할 수 없다는 것을 기억하십시오.
너는 내가 wemake-python-styleguide 를 위해 만든 회귀 테스트를 좀 볼 수 있다.다음은 우리의 테스트 구조에 적용되는 잠재적인 최고치입니다.

code_that_breaks = '''
def current_session(
    telegram_id: int,
    for_update: bool = True,
) -> TelegramSession:
    ...
'''


def test_regression112(default_options):
    """
    There was a conflict between ``pyflakes`` and our plugin.

    We were fighting for ``parent`` property.
    Now we use a custom prefix.
    See: https://github.com/wemake-services/wemake-python-styleguide/issues/112
    """
    ...

    # It was failing on this line:
    # AttributeError: 'ExceptHandler' object has no attribute 'depth'
    flakes = PyFlakesChecker(module)

    assert flakes.root

오류 수정

현재, 우리가 오류를 발견하고, 보고하고, 복사할 때, 우리는 반드시 실제적으로 그것을 복구해야 한다.
이것은 의외의 행동을 삭제하기 위해 코드 라이브러리를 실제로 수정하는 부분입니다.이것은 어쨌든 그렇게 어렵지 않아야 한다!
코드를 수정하고 커밋하면 CI 구성이 통과되어야 합니다.이 경우 오류가 수정되었습니다.하지만 한 가지 더 해야 할 일이 있습니다.
잠깐만, 뭐야?
네, 그리고 대부분의 개발자들이 하기 싫은 일이 하나 있습니다 postmortem.어떤 버그는 정말 쉽다. 이 단계는 필요 없지만, 어떤 버그는 우리에게 많은 시간과 돈을 썼다.우리는 반드시 각별히 그들에게 관심을 가져야 한다.부검은 비기술적인 이야기로 경영진에게 보여줄 수 있다.부검에는 무엇이 포함되어야 합니까?

왜 오류가 발생했습니까?이것은 반드시 이 문제를 야기하는 모든 행동의 비기술적인 총결이어야 한다.원본 오류 보고서를 가리키는 링크를 포함해야 합니다.

우리는 이 버그를 복구하기 위해 무엇을 했습니까?마찬가지로 기술 디테일에 깊이 들어가지 말고 간단하게 유지해야 한다.제출이 이 문서에 연결되어 있는지 확인하십시오.

제품/사용자/고객에게 어떤 영향을 미칩니까?그것은 계산이나 지능적인 추측이 필요하다.

시간표는 무엇입니까?로그/모니터링 등 모든 링크를 언제 저장했는지 기억나세요?시간표를 세우면 매우 유용할 것이다.우리가 이 병에 걸린 지 얼마나 되었습니까?언제 해결했어요?

이것이 바로 부검이 필요한 이유입니다. 미래의 팀에게 이 버그에 대한 이야기를 할 것입니다.가장 중요한 오류의 일치 목록을 유지하면 프로젝트의 문서를 크게 개선할 수 있습니다.여느 때와 마찬가지로 여기에는 different postmortem templates 로 가는 링크가 있다.

후기

이것이 바로 고기능 엔지니어가 버그를 복구하는 방법이다.일부 실현은 다를 수 있지만 원칙은 항상 변하지 않는다. 발견, 보고, 복제, 복구, 기록이다.
나는 이 문장이 너의 프로젝트의 성장을 도울 수 있기를 바란다.Subscribe to my github 현재 개발자를 위해 어떤 도구를 구축하고 있는지 알고 싶으면 계정에 로그인하십시오.