Print 문을 사용하는 것은 코드를 디버깅하고 탐색하는 간편한 방법입니다

본문은 2018년 9월 9일에 발표되었다. https://nickjanetakis.com/blog/using-print-statements-are-a-handy-way-to-debug-and-explore-code
과거에 나는 rubber duck debugging라고 썼는데, 이것은 문제 해결을 돕는 방법의 하나이다.Rubber duck 디버깅은 문제를 자세히 설명해야 하기 때문에 매우 편리합니다. break it down
하지만 이제는 당신이 무엇을 하고 싶은지 알고 그것을 실현하기 위해 노력하고 있다고 가정해 봅시다.print 문장을 사용하면 비작업 코드에서 작업 코드로 빠르게 변환할 수 있습니다.

왜 인쇄 문장을 번거롭게 사용합니까?

소프트웨어를 작성할 때 지식은 힘이다.너는 발생한 일에 대해 많이 알면 알수록 좋다.보고서를 인쇄하는 것은 상황을 신속하게 이해하는 방법의 하나다.이것은 심지어 디버깅 문제에 국한되지 않는다.그것은 일반 코드에 대한 통찰에 매우 유용하다.
이것이 바로 내가 쓴 코드가 첫 번째 시도에서 작용하지 않을 때, 나는 영웅이 되는 시도를 건너뛰고, 인쇄문만 여기저기 사용하기 시작하는 이유이다.나는 문제의 속도가 빨라질수록 다음 단계로 진입할 수 있다는 것을 발견했다.

프린터 문장은 언제 사용하면 유용합니까?

다음은 내가 인쇄문을 사용하는 세 가지 상황을 발견한 것이다.

어떤 물건의 가치를 빨리 보고 싶을 때

비교적 긴 함수에서 나누어 고치려는 방법

새로운 코드 라이브러리를 탐색하려면 추적 코드 라이브러리에 대한 도움이 필요합니다

곧 어떤 물건의 가치를 볼 수 있다

최근 몇 년 동안 내가 배운 가장 큰 교훈 중 하나는 어떤 가설도 하지 말라는 것이다.만약 당신이 어떤 일이 무엇인지에 대해 약간의 의심이 있다면 인쇄해서 확인해 보세요.
인쇄하고 확인하는 데 몇 초밖에 걸리지 않습니다.이것은 당신의 많은 추측 시간을 절약할 수 있다. (유튜브에서 마음을 분산시키면 몇 시간을 초래할 수 있기 때문이다.)

나누어 다스리다

In a previous article about microservices 나는 코드의 추상적인 차원에 대해 이야기했다.
상당히 복잡한 논리를 처리할 때, 나는 논리를 계산할 때까지 대부분의 코드를 단일 함수에 연결하는 경향이 있다.나는 단지 이런 스타일이 가장 잘 어울린다고 생각한다.
이 문제는 이미 매우 어려운데, 왜 내가 문제를 이해하지 못하거나 해결 방안을 작성하기 전에 명명 함수와 재구성을 걱정해서 문제를 복잡하게 만들까?
이것은 통상적으로 내가 상당히 긴 함수로 끝날 것이라는 것을 의미한다.처음으로 30줄이나 40줄 함수를 쓰는 것은 적지 않다.
어떤 조건이나 코드의 일부 줄이 실행 중인지 확인하지 못할 때도 있지만, print 문장을 삽입하는 것은 코드의 실행 경로를 확인하는 매우 빠른 방법이다.
그것은 print("Is this being executed?")를 어딘가에 던질 정도로 간단하다.

새 코드 라이브러리 탐색

프리랜서 개발자로서, 나는 항상 기존의 코드 라이브러리에 대해 뭔가를 요구받는다.이것은 새로운 기능을 추가하거나 버그를 복구하거나 테스트를 추가할 수 있습니다.그것은 아마도 어떤 것일 것이다.
이 응용 프로그램들은 매우 큰 복잡성을 가지고 있다.그 중 일부는 100줄 Flask 응용 프로그램이고, 다른 일부는 100000여 줄 Rails 응용 프로그램이지만, 나는 흔히 볼 수 있는 추세는 인쇄물에 의존해서 새로운 코드 라이브러리를 신속하게 추적하는 것이다.
일단 당신이 선택한 웹 프레임워크에 익숙해지면 코드의 존재 위치에 따라 코드의 운행 시간을 대체적으로 알 수 있지만, 이것은 당신이 무엇을 하는지에 달려 있다. 특히 많은 원 프로그래밍이 긴장을 풀어야 한다면.

더 나은 분할 치료의 예:
너는 네가 작성하지 않은 코드의 질을 조절할 수 없다.
때때로, 너는 결국 400줄 함수가 도대체 무엇을 하고 있는지 알아야만 한다. 물론, 그것을 쓴 사람은 이미 없어졌다.
나는 가능한 한 빨리 등식에서 가능한 한 많은 코드를 삭제한 후에 블록을 나누는 것을 좋아한다.
예를 들어, 만약 200번째 줄에 인쇄 문장을 입력한다면, 출력된 문장을 보면, 적어도 199번째 줄이 실행 중인 것을 틀림없이 알 것이다.200번째 줄에서 변수의 값을 출력하기를 원할 수도 있습니다.
그리고 100번째 줄에서 이 변수를 다시 출력할 수 있습니다. 만약 이 변수의 값이 100번째 줄에서 정확하지만 200번째 줄에서 정확하지 않다면, 101줄과 199줄 사이에 문제가 생겼다는 결론을 안전하게 내릴 수 있습니다.
현재 150번째 줄에서 print 문장을 팝업하고 변수를 검사할 수 있습니다.만약 그것이 옳다면, 151행과 199행 사이를 알고 있거나, 만약 그것이 정확하지 않다면, 101행과 149행 사이를 알고 있을 것이다.
이런 사용 디버깅의 형식을 이분법 검색 또는 이진 검색이라고 하는데, 구체적으로는 어디에서 배우느냐에 달려 있다.분할 검색 방식으로 인쇄 문장을 사용하면 코드를 100% 안심하고 무시할 수 있어 문제의 근원을 신속하게 찾을 수 있습니다.

빠른 인쇄 보고서 찾기

많은 웹 프레임워크가 개발 과정에서 매우 상세한 로그 기록을 가지고 있기 때문에 매우 좋다.앞서 말씀드렸듯이, 어떤 경우에는 더 많은 정보를 가지는 것이 좋습니다.
이것은 또한 당신의 인쇄 보고서를 찾기가 매우 어렵다는 것을 의미한다.다음은 현재 개발 중인 Phoenix 애플리케이션의 로깅 출력입니다.

web_1       | [info] GET /
web_1       | [debug] QUERY OK source="users" db=1.7ms
web_1       | SELECT u0."id", u0."admin", u0."confirmed_email_at", u0."deactivated_at", u0."email", u0."email_auth_token", u0."name", u0."profile_hexcolor", u0."professional_title", u0."signed_in_at", u0."profile_photo", u0."username", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."id" = $1) [33]
web_1       | [debug] Processing with LMSWeb.PageController.index/2
web_1       |   Parameters: %{}
web_1       |   Pipelines: [:browser]
web_1       | [info] Sent 200 in 3ms

여기에 너무 미친 것은 없다. 이것은 단지 홈페이지를 보여주는 것일 뿐이지만, 우리가 믹스에 프린트 문장을 넣었다고 가정하면:

web_1       | [info] GET /
web_1       | [debug] QUERY OK source="users" db=1.7ms
web_1       | SELECT u0."id", u0."admin", u0."confirmed_email_at", u0."deactivated_at", u0."email", u0."email_auth_token", u0."name", u0."profile_hexcolor", u0."professional_title", u0."signed_in_at", u0."profile_photo", u0."username", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."id" = $1) [33]
web_1       | Hi
web_1       | [debug] Processing with LMSWeb.PageController.index/2
web_1       |   Parameters: %{}
web_1       |   Pipelines: [:browser]
web_1       | [info] Sent 200 in 3ms

인쇄된 메시지를 찾기가 쉽지 않습니다. 로그 출력을 몇 줄만 처리합니다.터미널 버퍼의 행 수가 5배나 된다면 상상해 보세요.
그에 비해

web_1       | [info] GET /
web_1       | [debug] QUERY OK source="users" db=1.7ms
web_1       | SELECT u0."id", u0."admin", u0."confirmed_email_at", u0."deactivated_at", u0."email", u0."email_auth_token", u0."name", u0."profile_hexcolor", u0."professional_title", u0."signed_in_at", u0."profile_photo", u0."username", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."id" = $1) [33]
web_1       | ------------------------------------------------------- Hi
web_1       | [debug] Processing with LMSWeb.PageController.index/2
web_1       |   Parameters: %{}
web_1       |   Pipelines: [:browser]
web_1       | [info] Sent 200 in 3ms

이제 우리는 1초 안에'헤이'의 메시지를 쉽게 볼 수 있다.우리의 눈은 즉각 끌렸다.
단행 출력에 있어서, 나는 항상 메시지 앞에 문자를 한 무더기 붙이는 경향이 있다.나는 항상 사용하지 않는다-.정말, 네가 볼 수만 있다면 괜찮아.
때때로, 만약 내가 몇 개의 변수를 출력한다면, 나는 모든 변수에 서로 다른 문자를 사용할 것이다.아마도 ---------------과~~~~~~~~~~~~~~~일 것이다.만약 그것이 여러 줄에서 같은 변수라면, 나는 --------------- L150: 또는 의미 있는 변수를 포함할 것이다.
만약 내가 몇 줄의 텍스트를 출력할 계획이라면, 나는 때때로 그것들을 선택할 것이다. 예를 들어:

web_1       | [info] GET /
web_1       | [debug] QUERY OK source="users" db=1.7ms
web_1       | SELECT u0."id", u0."admin", u0."confirmed_email_at", u0."deactivated_at", u0."email", u0."email_auth_token", u0."name", u0."profile_hexcolor", u0."professional_title", u0."signed_in_at", u0."profile_photo", u0."username", u0."inserted_at", u0."updated_at" FROM "users" AS u0 WHERE (u0."id" = $1) [33]
web_1       | -------------------------------------------------------
web_1       | Name: Foo
web_1       | Email: [email protected]
web_1       | -------------------------------------------------------
web_1       | [debug] Processing with LMSWeb.PageController.index/2
web_1       |   Parameters: %{}
web_1       |   Pipelines: [:browser]
web_1       | [info] Sent 200 in 3ms

이것이 바로 내가 인쇄 문장을 기반으로 하는 디버깅을 어떻게 하는가이다.내 프로그래밍 도구 모음에서, 그것은 매우 유용한 도구이다.
당신은 인쇄 문장을 디버깅할 수 있는 어떤 기교가 있습니까?다음은 내가 알게 해줘!