SqueakByExample:1.10: Difference between revisions

From 흡혈양파의 번역工房
Jump to navigation Jump to search
(문장 및 몇몇 내용 수정)
(번역수정)
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
==새로운 메서드 정의하기==
==새로운 메서드 정의하기==


테스트 주도 개발(Test Driven Development)<ref name="주석1-4">Kent Beck, Test Driven Development:By Example. Addison-Wesley, 2003, ISBN 0–321–14653–0.</ref>의 출현은 코드를 작성하는 방식을 바꾸었습니다. TDD 또는 행동 주도 개발(Behavior Driven Development)이라고 하는 테스트 주도 개발(Test Driven Development)의 배경 개념은, 코드 자체를 ''작성하기 전에'', 원하는 코드 동작을 정의하는 테스트를 작성하는 것에 있습니다. 그 다음, 테스트를 만족하는 코드를 작성하는거죠.


[[image:MethodFinder-example1.png|none|467px|thumb|그림 1.19: 예(例)로 메서드 찾기]]
이제부터 해야할일이 "무엇인가를 강조하여 크게 말하기"<ref name="역자주1">원문은 '''say something loudly and with emphasis'''</ref> 를 수행할 메서드를 만드는것이라고 가정해봅시다. 이건 정확하게 어떤 의미가 될까요? 메서드에 붙일 좋은 이름은 무엇일까요? 무엇을 해야 할 지 모호한 동작 설명을 가지도록 나중에 메서드를 관리해야 하는 프로그래머들에게 어떻게 이해시킬 수 있을까요? 이런 질문들에 대한 답은 아래와 같습니다.




테스트 주도 개발(Test Driven Development)<ref name="주석1-4">Kent Beck, Test Driven Development:By Example. Addison-Wesley, 2003, ISBN 0–321–14653–0.</ref>의 출현은 우리가 코드를 쓰는 방식을 바꾸었습니다. TDD 또는 행동 주도 개발(Behavior Driven Development)로 불리는 테스트 주도 개발(Test Driven Development)은, 우리가 코드 자체를 기록하기 전에, 원하는 코드의 동작을 정의하는 테스트를 기록하는 것입니다. 이러한 일이 끝난 후에, 우리는 테스트를 만족시키는 코드를 기록하기만 하면 됩니다.
<center>shout 메시지를 문자열 "Don't panic"에 보내면, 그 결과는 "DON'T PANIC"이 되어야 합니다.</center>


우리가 해야 할 과제가 "say something loudly and with emphasis"(무엇인가를 강조하여 크게 말하기)라는 메서드를 기록하는 것이라고 가정해 봅시다. 이 말이 정확하게 무엇을 의미할까요? 이 메서드에 좋은 이름은 무엇일까요? 모호한 동작 설명을 갖고 있는 이 메서드를 앞으로도 유지해야만 하는 프로그래머들에게 우리는 어떻게 명료화를 시킬 수 있을까요? 우리는 예를 제공하여 이러한 질문들에 답할 수 있습니다.


 
시스템이 사용할 수 있는 무언가에 예시를 만들려면, 예를 test 메서드로 변환해야 합니다:
<center>우리가 메시지 shout을 문자열 "Don't panic"에 보내면, 그 결과는 "DON'T PANIC"이 될 것입니다.</center>
 
 
시스템이 사용가능 한 어떤 대상 내부에, 예(例)를 만들려면, 우리는 그 예를 test 메서드로 변환해야 합니다:




Line 23: Line 19:




스퀵으로 어떻게 이 새로운 메서드를 만들 수 있을까요? 먼저 우리는 어떤 클래스에 메서드가 소속될 것인지를 결정해야만 합니다.
스퀵에서는 어떻게 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 메서드를 넣을 것인지 결정해야 합니다.
이번 경우, 우리가 테스트할 “shout” 메서드는 클래스 문자열 (class String)속으로 들어가게 될 것이며, 그러므로 이에 대응하는 테스트는 관례적으로, StringTest라고 명칭을 부여하겠습니다.
경우, String 클래스에 테스트할 “shout” 메서드를 넣고, 관례적으로 이 클래스에서 실행할 관련 테스트 클래스를 StringTest라고 하겠습니다.  
 
 
{{CommentSqueak|클래스 StringTest에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우 그림 1.20에서 볼 수 있듯이 {{HighlightGray|tests-converting}}이 적합한 프로토콜입니다.}}




Line 33: Line 26:




아래의 패널에 있는 음영으로 강조된 텍스트는 스몰토크 메서드가 어떤 모습을 갖추었는 지 여러분께 상기시켜 줍니다. 이 부분을 지우고, 메서드 1.1에서 가져온 코드를 입력합니다. 일단 여러분이 브라우저에 텍스트를 입력하면, 아래의 패널이 빨강색으로 강조됩니다. 이것은 이 창이 저장되지 않은 변경사항들을 포함하고 있음을 알려줍니다.  
{{CommentSqueak|StringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우 그림 1.20에서 보시는 바와 같이 {{HighlightGray|tests - converting}}이 적당한 프로토콜입니다. 하단 창의 강조된 텍스트는 스몰토크 메서드가 어떻게 생겼는지 알려주는 템플릿입니다. 이 부분을 지우고 메서드 1.1에 코드를 입력하십시오.}}
그러므로, 아래의 패널 속에서, 노랑색 버튼 메뉴를 불러 {{HighlightGray|accept(s)}}를 선택하거나, 여러분의 메서드를 컴파일하고 저장하기 위해 CMD-s를 입력합니다.


그 이유는, 아직 어떤 메서드도 “Shout”로 명칭을 부여 받지 않았기 때문에, 브라우저는 그 Shout라는 이름이 여러분이 정말로 원하는 이름인지를 확인할 것이고, 여러분이 의도했을 수 있는 몇 가지 다른 이름들(그림 1.21)을 제안해 드릴 것입니다. 이 작업은 만약 입력 실수를 하였을 경우에 꽤 유용할 수 있지만, 이번의 경우, 우리가 지금 만들려고 하는 메서드가 "shout’이고, 우리가 정말로 의도한 입력과 일치하기 때문에, 그림 1.21에 보이는 것처럼 메뉴 선택 첫 번째 옵션을 선택하여 확인을 해야만 합니다.
브라우저에 텍스트를 입력하고 나면, 하단 창이 빨간 테두리로 둘러 쳐짐을 보십시오. 이는 저장하지 않은 내용이 창에 있음을 알려주는 알리미입니다.
따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 창의 노랑 버튼 메뉴에서 {{HighlightGray|accept(s)}}를 선택하거나, CMD-s를 입력하십시오.


아직 “shout”라고 하는 메서드가 없기 때문에, 브라우저에서 이 이름을 정말 사용할 것인지 물어보고 여러분이 의도하는 다른 이름들을 제안할 것입니다(그림 1.21). 이러한 동작은 입력을 실수했을 때 약간 쓸모있을 수도 있지만, 이번과 같은 경우에는 정말로 만들고자 하는 ''shout'' 메서드를 ''실행'' 하려는 의미이므로, 그림 1.21에서 보시는 바와 같이 메뉴 선택으로부터 첫번째 옵션을 선택하여 이를 확인해야 합니다.


{{CommentSqueak|새롭게 만든 여러분의 테스트를 실행하십시오. 도구 플랩(Tool flap)에서 드래그 하거나 {{HighlightGray|World▷open…▷Test Runner}}를 선택하여 {{HighlightBold|SUnit TestRunner}}를 여십시오.}}
[[image:testShoutConfirm.png|none|601px|thumb|그림 1.21: StringTest 클래스의 testShout 메서드 수락]]


{{CommentSqueak|새로 만든 테스트를 실행하십시오. Tools flap에서 끌어 옮기거나 {{HighlightGray|World▷open…▷Test Runner}}를 선택하여 {{HighlightBold|SUnit TestRunner}}를 여십시오.}}


맨 왼쪽 두 개의 패널은 시스템 브라우저의 맨 위의 패널들과 약간 유사합니다. 왼쪽의 패널은 시스템 카테고리의 목록을 포함하지만, 그 패널은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.


가장 왼쪽 두 개의 창은 시스템 브라우저의 상단 창과 약간 비슷합니다. 왼쪽 창에는 시스템 카테고리의 목록이 들어있지만, 이 창은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.


{{CommentSqueak|{{HighlightBold|Collections Tests-Text}}를 실행하면 오른쪽에 있는 패널은 클래스 {{HighlightBold|StringTest}}를 포함하는 카테고리의 위치에 모든 테스트 결과를 보여드릴 것입니다. 클래스의 이름들을 이미 선택했다면, 이 모든 테스트를 실행하기 위해 {{HighlightGray|Run selected}}를 클릭하십시오.}}


{{CommentSqueak|{{HighlightBold|Collections Tests-Text}}를 선택하면 오른쪽에 있는 패널은 클래스 {{HighlightBold|StringTest}}를 포함한 카테고리의 모든 테스트 클래스를 보여줄 것입니다. 클래스 이름을 이미 선택했다면, 이들 테스트를 실행하기 위해 {{HighlightGray|Run selected}}를 클릭하십시오.}}


[[image:testShoutConfirm.png|none|601px|thumb|그림 1.21: StringTest 클래스의 testShout 메서드 수락]]


[[image:testRunnerOnStringTest.png|none|705px|thumb|그림 1.22 String 테스트 실행]]


[[image:testRunnerOnStringTest.png|none|705px|thumb|그림 1.22 문자열 테스트 실행]]


그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 창에 보여줍니다. 보시다시피 StringTest>>#testShout가 주범입니다.
(참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다.


여러분은 그림 1.22에 보이는 것처럼, 테스트 실행시 오류가 있었음을 가리키는 메시지를 볼 수 있어야만 합니다.
오류 메시지가 떠 있는 창이 바로 스몰토크 디버거 입니다(그림 1.23 참조). 6장에서 디버거와 이를 어떻게 사용하는지 보겠습니다.


여러분이 보시는 바와 같이, 우측 아래쪽 창에서 보이는 오류를 일으킨 테스트의 목록은, StringTest>>#testShout가 주범입니다.
[[image:Predebugger.png|none|451px|thumb|그림 1.23: (선-)디버거]]
(StringTest>>#testShout는 문자열테스트 클래스(the StringTest Class)의 "testShout" 메서드를 감지하기 위한 스몰토크 방식임을 주목해 주십시오) 만약 여러분이 텍스트의 라인을 클릭하면, 오류가 생긴 테스트는 다시 실행될 것이며, 이번 경우에 여러분은 그와 같은 방식으로, 발생한 "MessageNotUnderstood:ByteString>>shout" 오류를 보게 됩니다




[[image:Predebugger.png|none|451px|thumb|그림 1.23: (pre-)debugger]]
물론 이 오류가 확실히 기대하던 바입니다. 테스트를 실행하면 오류가 발생하는데. 어떻게 "shout" 할 지 아직 작성하지 않았기 때문입니다. 그럼에도 불구하고, 테스트가 실패했음을 분명히 해두는 것은 바람직한 습관인데, 테스트 장치를 정확하게 설정했고 새 테스트가 실제로 실행중임을 확인시켜주기 때문입니다. 오류를 보고 나면, 디버거 창을 닫아서 실행 중인 테스트를 {{HighlightBox|Abandon(포기)}}할 수 있습니다. 참고로 스몰토크에서는 {{HighlightBox|CreateNote}} 버튼을 사용하여 빠진 메서드를 정의하고, 새로 만든 메서드를 디버거에서 편집하며, 테스트를  {{HighlightBox|Proceed(진행)}}할 수 있습니다.




물론 정확히 우리가 기대하던 오류가 생겼습니다. 테스트를 실행하면 오류가 발생합니다. 그 이유는 우리가 어떻게 "shout"를 할지에 대해 문자열에게 말해주는 메서드를 아직 만들지 않았기 때문입니다. 그럼에도 불구하고, 그 테스트가 실패를 하였다는 것을 분명히 해두는 것이 좋습니다. 그 이유는 그 작업이 우리가 테스트 기구(the testing machinery)를 정확히 설정하였고, 새로운 테스트가 실제 실행 중이라는 사실을 확인해 주기 때문입니다. 일단 오류가 발생하면 여러분은 실행중인 테스트를 {{HighlightBox|Abandon(포기)}}할 수 있으며 버튼을 누른다면 디버그 창(the debugger window)을 닫히게 됩니다. 여러분은 종종 스몰토크에서 {{HighlightBox|Create}} button(생성버튼)을 사용하여 누락된 메서드를 정의하고, 디버그를 하여 새롭게 만들어진 메서드를 편집하고 그 테스트를 {{HighlightBox|Proceed(진행)}}할 수 있다는 사실에 주목해 주십시오.<BR>
이제 테스트를 성공으로 이끌 메서드를 정의해보도록 하겠습니다!
이제. 성공한 테스트를 만들 메서드를 정의하겠습니다.




{{CommentSqueak|시스템 브라우저에서 클래스 {{HighlightBold|String}}선택하고 {{HighlightGray|Converting(변환)}} 프로토콜을 선택한 후 메서드 생성 탬플릿(the method creation template)위의, 메서드 1.2에서 "the text"를 입력한 후 {{HighlightGray|accept}}하십시오. (주의 ↑를 얻기 위해, ^를 입력하십시오.)}}
{{CommentSqueak|시스템 브라우저에서 {{HighlightBold|String}} 클래스를 선택하고, {{HighlightGray|Converting(변환)}} 프로토콜을 선택한 후, 메서드 생성 탬플릿에, 메서드 1.2를 입력하시고 {{HighlightGray|accept}}를 실행하십시오(참고: ↑를 입력하려면, ^를 입력하십시오).}}




Line 77: Line 71:
</syntaxhighlight>
</syntaxhighlight>


쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" 오브젝트와 "Shout" 메시지의 대문자 버전 문자열에 느낌표를 붙입니다.↑는 뒤에 이어진 표현식이 메서드에서 반환한 답이라는 것을 스퀵에 알려주며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다.




콤마는 문자열 결합 연산자입니다. 따라서 이 메서드의 바디에서는 "String"(문자열) 오브젝트와 "Shout" 메시지를 보낸 모든 대문자 문자열에 느낌표를 붙입니다.↑는 뒤에 이어진 표현식이, 메서드에서 리턴한 답변이 되도록 하며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다.
{{CommentSqueak|테스트 러너에서 {{HighlightGray|Run Selected}}를 다시 클릭하면, 이번에는 모든 테스트가 실패와 오류없이 실행되었음을 가리키는 녹색 표시줄을 볼 수 있을 것입니다.}}
 
 
{{CommentSqueak|test runner에서 {{HighlightGray|Run Selected}}를 다시 클릭하면, 이번에 여러분은 모든 테스트가 실패와 오류없이 실행되었음을 가리키는 녹색 표시줄을 볼 수 있을 것입니다.}}
 


여러분이 녹색 표시줄을 보신다면,<ref name="주석1-5">실제로, 여러분은 몇가지 이미지가 버그 테스트를 포함하고 있고 여전히 수정될 필요가 있기 때문에 녹색 표시줄을 볼 수 없을 수도 있습니다. 이 문제에 대해 걱정하지 마십시오. 스퀵은 계속해서 진화하고 있습니다.</ref> 하시던 작업을 저장하고 잠시 쉴 좋은 시간입니다. 그러면 이제 좀 쉬도록 하겠습니다.


녹색 표시줄을 보셨다면,<ref name="주석1-5">실제로, 여러분은 몇가지 이미지가 버그 테스트를 포함하고 있고 여전히 수정될 필요가 있기 때문에 녹색 표시줄을 볼 수 없을 수도 있습니다. 이 문제에 대해 걱정하지 마십시오. 스퀵은 계속해서 진화하고 있습니다.</ref> 하시던 일을 저장하고 잠시 쉴 좋은 때입니다. 그러면 이제 좀 쉬도록 하겠습니다.


[[image:String-Shout.png|none|602px|thumb|그림 1.24: 클래스 "string"에 정의된 "Shout" 메서드]]
[[image:String-Shout.png|none|602px|thumb|그림 1.24: 클래스 "string"에 정의된 "Shout" 메서드]]

Revision as of 04:45, 14 March 2013

새로운 메서드 정의하기

테스트 주도 개발(Test Driven Development)[1]의 출현은 코드를 작성하는 방식을 바꾸었습니다. TDD 또는 행동 주도 개발(Behavior Driven Development)이라고 하는 테스트 주도 개발(Test Driven Development)의 배경 개념은, 코드 자체를 작성하기 전에, 원하는 코드 동작을 정의하는 테스트를 작성하는 것에 있습니다. 그 다음, 테스트를 만족하는 코드를 작성하는거죠.

이제부터 해야할일이 "무엇인가를 강조하여 크게 말하기"[2] 를 수행할 메서드를 만드는것이라고 가정해봅시다. 이건 정확하게 어떤 의미가 될까요? 메서드에 붙일 좋은 이름은 무엇일까요? 무엇을 해야 할 지 모호한 동작 설명을 가지도록 나중에 메서드를 관리해야 하는 프로그래머들에게 어떻게 이해시킬 수 있을까요? 이런 질문들에 대한 답은 아래와 같습니다.


shout 메시지를 문자열 "Don't panic"에 보내면, 그 결과는 "DON'T PANIC"이 되어야 합니다.


시스템이 사용할 수 있는 무언가에 이 예시를 만들려면, 이 예를 test 메서드로 변환해야 합니다:


메서드 1.1: “shout” 메서드를 위한 테스트

testShout
self assert: ('Don''t panic' shout = 'DON''T PANIC!')


스퀵에서는 어떻게 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 메서드를 넣을 것인지 결정해야 합니다. 이 경우, String 클래스에 테스트할 “shout” 메서드를 넣고, 관례적으로 이 클래스에서 실행할 관련 테스트 클래스를 StringTest라고 하겠습니다.


그림 1.20: StringTest 클래스에 있는 새로운 메서드 탬플릿


Squeak comment.pngStringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우 그림 1.20에서 보시는 바와 같이 tests - converting이 적당한 프로토콜입니다. 하단 창의 강조된 텍스트는 스몰토크 메서드가 어떻게 생겼는지 알려주는 템플릿입니다. 이 부분을 지우고 메서드 1.1에 코드를 입력하십시오.

브라우저에 텍스트를 입력하고 나면, 하단 창이 빨간 테두리로 둘러 쳐짐을 보십시오. 이는 저장하지 않은 내용이 창에 있음을 알려주는 알리미입니다. 따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 창의 노랑 버튼 메뉴에서 accept(s)를 선택하거나, CMD-s를 입력하십시오.

아직 “shout”라고 하는 메서드가 없기 때문에, 브라우저에서 이 이름을 정말 사용할 것인지 물어보고 여러분이 의도하는 다른 이름들을 제안할 것입니다(그림 1.21). 이러한 동작은 입력을 실수했을 때 약간 쓸모있을 수도 있지만, 이번과 같은 경우에는 정말로 만들고자 하는 shout 메서드를 실행 하려는 의미이므로, 그림 1.21에서 보시는 바와 같이 메뉴 선택으로부터 첫번째 옵션을 선택하여 이를 확인해야 합니다.

그림 1.21: StringTest 클래스의 testShout 메서드 수락

Squeak comment.png새로 만든 테스트를 실행하십시오. Tools flap에서 끌어 옮기거나 World▷open…▷Test Runner를 선택하여 SUnit TestRunner를 여십시오.


가장 왼쪽 두 개의 창은 시스템 브라우저의 상단 창과 약간 비슷합니다. 왼쪽 창에는 시스템 카테고리의 목록이 들어있지만, 이 창은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.


Squeak comment.pngCollections Tests-Text를 선택하면 오른쪽에 있는 패널은 클래스 StringTest를 포함한 카테고리의 모든 테스트 클래스를 보여줄 것입니다. 클래스 이름을 이미 선택했다면, 이들 테스트를 실행하기 위해 Run selected를 클릭하십시오.


그림 1.22 String 테스트 실행


그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 창에 보여줍니다. 보시다시피 StringTest>>#testShout가 주범입니다. (참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다.

오류 메시지가 떠 있는 창이 바로 스몰토크 디버거 입니다(그림 1.23 참조). 6장에서 디버거와 이를 어떻게 사용하는지 보겠습니다.

그림 1.23: (선-)디버거


물론 이 오류가 확실히 기대하던 바입니다. 테스트를 실행하면 오류가 발생하는데. 어떻게 "shout" 할 지 아직 작성하지 않았기 때문입니다. 그럼에도 불구하고, 테스트가 실패했음을 분명히 해두는 것은 바람직한 습관인데, 테스트 장치를 정확하게 설정했고 새 테스트가 실제로 실행중임을 확인시켜주기 때문입니다. 오류를 보고 나면, 디버거 창을 닫아서 실행 중인 테스트를 Abandon(포기)할 수 있습니다. 참고로 스몰토크에서는 CreateNote 버튼을 사용하여 빠진 메서드를 정의하고, 새로 만든 메서드를 디버거에서 편집하며, 테스트를 Proceed(진행)할 수 있습니다.


이제 테스트를 성공으로 이끌 메서드를 정의해보도록 하겠습니다!


Squeak comment.png시스템 브라우저에서 String 클래스를 선택하고, Converting(변환) 프로토콜을 선택한 후, 메서드 생성 탬플릿에, 메서드 1.2를 입력하시고 accept를 실행하십시오(참고: ↑를 입력하려면, ^를 입력하십시오).


메서드 1.2: "shout" 메서드

shout                                                                
self asUppercase, '!'

쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" 오브젝트와 "Shout" 메시지의 대문자 버전 문자열에 느낌표를 붙입니다.↑는 뒤에 이어진 표현식이 메서드에서 반환한 답이라는 것을 스퀵에 알려주며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다.


Squeak comment.png테스트 러너에서 Run Selected를 다시 클릭하면, 이번에는 모든 테스트가 실패와 오류없이 실행되었음을 가리키는 녹색 표시줄을 볼 수 있을 것입니다.


녹색 표시줄을 보셨다면,[3] 하시던 일을 저장하고 잠시 쉴 좋은 때입니다. 그러면 이제 좀 쉬도록 하겠습니다.

그림 1.24: 클래스 "string"에 정의된 "Shout" 메서드

Notes

  1. Kent Beck, Test Driven Development:By Example. Addison-Wesley, 2003, ISBN 0–321–14653–0.
  2. 원문은 say something loudly and with emphasis
  3. 실제로, 여러분은 몇가지 이미지가 버그 테스트를 포함하고 있고 여전히 수정될 필요가 있기 때문에 녹색 표시줄을 볼 수 없을 수도 있습니다. 이 문제에 대해 걱정하지 마십시오. 스퀵은 계속해서 진화하고 있습니다.