• NAME
• SYNOPSIS
• DESCRIPTION
• 나의 디버깅 철학
• 제가 쓰는 방법
• AUTHOR
• COPYRIGHT

---

NAME

brian's Guide to Solving Any Perl Problem

voltar para o topo

---

SYNOPSIS

이 가이드에 따라서 건전함을 유지하세요.

voltar para o topo

---

DESCRIPTION

나의 디버깅 철학

전 이 세가지를 믿습니다

개인적인 일이 아닙니다

코드를 쓴 사람에 대해서는 잊어버리세요. 당신은 자신이 아티스트라고

생각할지는 모르겠지만 어떤 달인이라도 잘못을 해왔습니다. 어느 누구의

코드라도 잘못된 곳은 있습니다. 즉, 제 코드도 그렇고, 당신의 코드도

마찬가지로 틀린 곳이 있습니다. 하지만 그것이 좋은 일이라고 생각하세요.

뭔가 문제가 있으면, 당신이 먼저 ``내 이상한 코드에 뭔가 문제가 있나봐''

라고 생각해야 합니다. Perl 탓을 해서는 안된다는 것을 의미하구요.

이건 개인적이지 않기때문입니다.

당신이 한 것에 대해서는 잊어버리세요. 당신이 한 것이 잘 돌아간다면,

이런 건 읽지 않겠지만, 잊어버리는 것은 나쁜 게 아니에요.

오히려 발전할 때입니다. 우리도 그래왔어요.

개인의 책임

만약 당신의 스크립트에 문제가 있다면 그것은 당신의 문제입니다.

그리고 당신은 그것을 풀기 위한 최선의 노력을 해야합니다. 하지만,

기억해세요. 스크립트가 다른 누군가의 것이라면 그것은 그들의 문제라는 것을.

다른 사람에게 당신이 가지고 있는 문제를 공유하기 전에 스스로 당신의 일을

최선을 다해서 수행하세요. 이 가이드에 있는 대로 모든 것을 수행했음에도

문제가 해결되지 않는다면 그것이 바로 최선을 다한 것입니다.

그때가 바로 다른 사람에게 문제를 제시할 때인 것이죠.

당신의 방법을 바꾸세요

두번 다시 같은 문제가 일어나지 않게 문제를 고칩니다. 문제는

당신이 무엇을 코딩했느냐 가 아니라 어떻게 코딩했냐는 것입니다.

편안한 삶을 위해서 방법을 바꾸세요. Perl 을 당신에게 맞춰봤자

안되니까, 모든 것을 Perl 에 맞춰보세요. Perl 은 언어일 뿐이지

삶의 방법이 아닙니다.

제가 쓰는 방법

엄밀하게 컴파일하고 있나요?

아직 엄밀성을 사용하고 있지 않다면, 당장 사용하세요. Perl 구루들은

그것이 다른 문제들을 해결하고, 새로운 것을 배우고, CPAN 에 모듈을

업로드할 시간을 벌기위해서 strict 를 사용하고 있습니다.

스크립트에서 strict 프라그마를 사용함으로 엄밀성있게 사용할 수 있습니다.

        use strict;

Perl 의 -M 스위치를 사용하면 커맨드라인에 엄밀성을 적용할 수 있죠.

        perl -Mstrict script.pl

엄밀성에 곤혹스러우실 지도 모르겠지만, 그것을 켜둔 채로 몇주간

프로그래밍하다보면 더 나은 코드를 쓰고, 짧은 시간에 간단한 에러들을

추적해내서 아마도 이 가이드가 필요없어질 지도 모릅니다.

경고는 뭘까요?

Perl 은 의문이 많은 구축에 경고를 던져줍니다. warnings 를 사용해서

Perl 이 당신을 돕도록 하세요.

shebang 라인에 Perl의 -w 스위치를 사용할 수 있습니다.

        #!/usr/bin/perl -w

물론 커맨드라인에도 warnings 를 켤 수 있죠.

        perl -w script.pl

모든 흥미있는 특색들과 함께 렉시컬 warnings 를 사용할 수 있습니다.

자세한 내용은 warnings 를 참조하세요.

        use warnings;

만약에 경고의 의미를 모르겠다면, perldiag안의 warnings 의 내용을

볼 수 있으며, 또는 코드 안에서 disanostics 프라그마를 사용할 수 있습니다.

        use diagnostics;

첫번째 문제를 제일 처음에 해결하세요

에러 또는 경고 메시지를 Perl 에게서 받은 다음, 먼저 첫번째 메시지를

해결한 다음에 아직도 Perl 이 다른 메시지를 내는 가를 확인하세요.

다른 메시지들이 맨 처음의 메시지의 내용과 복합적인 것일지도 모르기

때문입니다.

에러 메시지에 있는 줄의 앞에 위치한 코드를 보세요!

Perl 은 곤란한 시점에서 경고메시지를 줍니다. Perl 이 곤란한 시점까지는

문제가 발생하고 있는 것이며, Perl 이 말하는 줄 번호는 실제로는

문제 다음의 것입니다. 경고받은 줄 위치의 앞의 코드를 보세요.

그 값은 당신이 생각했던 것인가요?

추측하지 마세요! 사전에 예상하고 있던 값인지 어떤지를 검증하세요.

최선의 디버거는 print 입니다.

        print STDERR "The value is [$value]\n";

저는 $value 를 [ ] 로 감싸고, 그리고 앞과 뒤를 스페이스나 줄바꿈으로

볼 수 가 있습니다.

만약 스칼라가 아닌 다른 것을 원한다면, 전 데이터 구조를 찍기위해서

Data::Dumper 를 사용합니다.

        require Data::Dumper;

        print STDERR "The hash is ", Data::Dumper::Dumper( %hash ), "\n";

값이 예상하고 있는 것과 다르다면, 몇 단계 앞으로 돌아와서 다시 한번 해보세요!

이런 것을 값이 관계하고 있지 않은 곳까지 반복하세요!

Perl -d 스위치를 사용하면 내장 디버거도 사용할 수 있습니다.

자세한 내용은 perldebug 를 참조하세요.

        perl -d script.pl

ptkdb( 그래피컬한 Tk 기반의 디버거 ) 나 Komodo( 모질라 기반의 ActiveState? 의

Perl IDE ) 같은 다른 디버거나 개발환경도 사용할 수 있습니다.

함수를 바르게 사용하고 있나요?

저는 꽤 오랜 시간동안 Perl 로 프로그래밍 해왔지만, 거의 매일을 perlfunc 를

보고 있습니다. 어떤 것은 기억할 수 없고, 어떤 때는 잠에 겨워서 머리가 멍한 채로

sprintf() 가 왜 화면에 찍지 않는 가 신기하다고 생각한 적도 있습니다.

perldoc 커맨드와 -f 스위치를 사용하면 보고싶은 함수를 조사할 수 있습니다.

        perldoc -f function_name

모듈을 사용하고 있다면, 바르게 사용하고 있는 가 확인하기 위해서, 문서를 체크해

주세요. perldoc 을 사용해서 그 모듈의 문서를 체크할 수 있습니다.

        perldoc Module::Name

바른 특수변수를 사용하고 있나요?

또, 전 항상 perlvar 를 참조하고 있습니다. 흠, The Perl Pocket Reference를

사용하는 게 편리하기때문에 사실이 아닐지도 모르죠.

제대로 된 버젼의 모듈을 가지고 있나요?

어떤 모듈은 버젼이 바뀔때에 행동이 바뀝니다. 예상하고 있는 버젼의 모듈을

가지고 있나요? 간단한 Perl 원라이너로 모듈의 버젼을 체크할 수 있습니다.

        perl -MModule::Name -le 'print Module::Name->VERSION';

http://www.perldoc.om 이나 http://search.cpan.org 처럼 온라인에서 읽는다면,

문서로 버젼의 차이를 알 수 있을 겁니다.

작은 테스트 케이스를 만든 적이 있나요?

뭔가 새로운 것을 하려하거나, 특정 코드가 이상하다고 생각될 때,

그것을 나타내는 짧은 프로그램을 만드세요. 그러면 생각에 방해가 되는 요소들을

없앨 수 있습니다. 작은 테스트 프로그램이 예상한 일을 해준다면 아마도

그 코드에는 문제가 없을 겁니다. 그 프로그램이 당신이 생각한대로 움직여 주지

않으면, 아마도 그것은 당신이 문제를 발견한 것입니다.

동작환경을 체크했나요?

어떤 것은 환경변수에 의존합니다. 환경변수가 제대로 설정되어 있는 지

확인하고 있나요? 프로그램이 움직일 때와 같은 환경인가요?

CGI 프로그램 또는 cron Job 을 위한 프로그램은 인터랙티브 셸에서의 환경과는

(특히 다른 머신에서) 다른 것을 보고 있을 지도 모른다는 것을 기억해두세요.

Perl 은 환경을 %ENV에 저장합니다. 그런 변수 중에 하나가 필요하다면,

테스트만을 위해서라도, 존재하지 않을 때는 기본값을 설정하세요.

그래도 문제가 있다면 환경변수를 조사하세요.

        require Data::Dumper;

        print STDERR Data::Dumper::Dumper( \%ENV );

Google 에서 체크했나요?

문제가 있다면, 다른 누군가도 그런 문제를 가졌을 지도 모릅니다.

다른 누군가가 usenet 그룹 comp.lang.perl.misc 에 글을 적었는지,

Google Groups(http://groups.google.com) 를 검색하세요.

usenet 에서 질문하는 사람과 그에 답변하는 사람의 차이는 Google Groups를

효율적으로 사용하는 기량이 있냐는 것입니다.

어플리케이션의 프로파일을 가지고 있나요?

프로그램의 느린 부분을 추적하고 싶을 때, 그 프로파일을 얻은 적이

있나요? 당신을 위해 Devel::SmallProf 에게 중노동을 시키세요.

Devel::SmallProf 는 코드의 줄을 Perl 이 실행하는 시간을 계측함과 동시에

어느정도 시간이 걸렸는지 훌륭한 보고서를 뽑아줍니다.

어떤 테스트가 실패했나요?

테스트 슈트가 있다면 어떤 테스트를 실패했나요? 각각의 테스트는

코드의 극히 일부분을 단순히 실행하고 있을 뿐이기때문에 에러를 당장

찾아낼 수 있을 겁니다. 테스트 슈트가 없다면 왜 만들지 않나요?

작은 스크립트가 있거나 한줄의 스크립트라도 저는 테스트를 쓴다고

하지 않습니다. 테스트 스크립트에게서 얻을 수 있는 것은 테스트를

쓰는 것보다도 어떤 이점이 있습니다. Test::Harness 는

변명의 여지가 없을 만큼 이 작업을 간단하게 처리합니다.

시간이 없다면 테스트없는 디버그는 더욱 시간이 걸릴 것입니다.

MakeMaker? 는 결국 모듈만을 위한 것이 아닙니다.

곰돌이에게 얘기했나요?

큰소리로 문제를 설명하세요. 어떤 말이든요.

2, 3년 동안 전 대부분의 일을 해결할 수 있는 훌륭한 프로그래머와 일을 한

좋은 경험이 있습니다. 막혔을 때는 그에게로 가서 문제를 설명했습니다.

보통 ``걱정하지마, 해결했어'' 라는 두 마디이외에는 필요없었습니다.

그는 거의 실수도 하지 않았습니다.

당신이 이 일을 더욱 필요로 할 것이기 때문에, 동료를 곤란하게 하지

않기 위해 Perl 테라피스트로써 호화로운 완구를 소개합니다. 전 책상에

작은 곰돌이를 놓아두고, 그 곰돌이에게 문제를 설명합니다.

요즘 제가 혼잣말을 하고 있을 때는, 제 여자친구는 어떤 신경도 쓰지 않습니다.

문제는 종이 위에서 다르게 보이나요?

보통 컴퓨터 스크린으로 시작하지만, 다른 미디어에서는 일이 다른 새로운

방법으로 보일지도 모릅니다. 프로그램을 종이 위에 찍어봅시다.

Jon Stewart 의 Daily Show 를 보나요?

장난이 아니구요. 당신이 Jon Stewart 를 싫어한다면, 다른 사람을 골라도

좋습니다. 쉬세요. 잠깐 문제를 잊고 마음을 편안하게 하세요.

나중에 문제로 돌아오고, 해결방법이 나타날지도 모릅니다.

자신의 자아를 억제하고 있나요?

아직 전혀 해결되지 않고 있다면, 그것은 심리적인 문제일지도 모릅니다.

감정적으로 코드의 일부분을 공격하고 있다거나 하는 것으로는 그것을

바꿀 수 없습니다. 당신은 자신 이외의 누군가가 틀렸다고 생각하고 있을지도

모릅니다. 그렇다면 버그의 가장 근원이 되는 부분을 제대로 생각하지

않은 것이 됩니다. 즉, 당신 자신입니다. 모든 일에 맘편히 생각하고,

모든 것을 검증하세요.

voltar para o topo

---

AUTHOR

brian d foy, <bdfoy@cpan.org>

voltar para o topo

---

COPYRIGHT

Copyright 2002, Perl Documentation Project, All Rights Reserved

voltar para o topo