Q & A
ATDD와 TDD의 순서
ATDD는 학습 비용이 높기 때문에 TDD를 공부하고 ATDD를 공부하는 것이 좋습니다.
실제 현업에서는 AcctanceTest를 먼저 만들어 서버와 클라이언트간 제대로 통신하는지 확인하고, 이후 그 안의 로직을 TDD 기반으로 개발을 한다고 합니다. 즉, ATDD먼저하고 TDD를 이후에 하는 것입니다(Out-In 방식)
주니어 개발자로써 ATDD까지는 기대안하지만 TDD와 Refactoring은 필수라고 합니다.
ATDD가 익숙해지면 브라우저를 띄우지 않고 구현이 가능합니다!
HTTP status 301와 302의 차이
브라우저는 Status Code를 기반으로 먼저 상태를 확인하고, 이후에 Body를 불러옵니다.
200대(정상적인 응답), 300대(다른 쪽에 일을 위임 - redirect 등), 400대(클라이언트의 fault), 500대(서버의 fault - NullPointException 등)
redirect시 브라우저에게 302 상태로 보냅니다. 브라우저는 헤더에 Location 안에 있는 경로정보(path)로 다시 요청(이전에 이렇게 전달되는 것을 살펴본 적이 있죠)을 보냅니다.
301과의 차이에 대해 문서를 살펴보면 301은 영구적, 302는 일시적으로 나옵니다.
영구적, 일시적이라는 말은 무슨 뜻일까요?
302는 redirect요청할 때마다 클라이언트에서 다시 받은 path로 요청을 보내는데요. 301은 클라이언트에서 다시 받지 않고 바로 redirect된 주소로 보내주는 것입니다. 이러한 처리는 클라이언트쪽에서 캐쉬로 이전에 매핑해줘서 가능한 일입니다. 하지만 주의할 점은 서버에서 redirect된 주소를 바꿀 때 클라이언트 쪽에서 캐쉬가 걸려있다면 경로가 어긋날 수 있다는 것입니다.
HandlerMethodArgumentResolver
의 정체(더 알아보고 싶은 부분)- 이를 상속하여 사용자가 구현할 수 있습니다.
resovleArgument()
가 실행되기 위해선supportsParameter()
가 true가 되어야 합니다.- 위 코드에선
@LoginUser
가 추가되어 있으면resovleArgument()
가 실행되도록 하고 있습니다. - 이 부분이 파라미터에 특정타입이 왔을 때 처리해주는 곳(예를들어 Model, HttpSession)입니다.
HTTP에서 Accept와 Content-Type
- Accept는 해당 요청에 대해 브라우저에서 처리할 수 있는 능력(컨텐츠 타입)에 대한 것들을 말합니다.
- 그것에 따라 서버에서는 해당 컨텐츠를 만든다음 클라이언트로 보낼 때 Content-Type을 통해 컨텐츠 타입을 명시합니다.
- 그러니까 Accept와 Content-Type은 컨텐츠 타입을 명시한다는 점에서 공통점이 있지만 클라이언트의 능력이냐, 서버의 능력이냐가 다른 것입니다.
- 이 부분은 나중에 성능 처리를 할 경우 이런 부분에 대한 지식이 필요합니다.
로그인 처리 과정
template
은 브라우저와 같은 클라이언트 역할을 합니다.- basicAuth와 관련해서는 nextStep 내에 '이미 구현되어 있는 코드 리뷰' 글 참고하면 됩니다. 이 매커니즘에 따라 로그인된 사용자, 로그인 안된 사용자가 구별됩니다.
preHandle()
메서드를 통해 메서드가 실행되기 전에 BasicAuth와 관련하여 실행됩니다.- 로그인 흐름을 이해하려면 Interceptor에 대한 공부가 선행되어야 합니다! Spring에서는 Interceptor라는 용어가 쓰이고, Servlet에서는 filter라는 용어로 쓰입니다.
TDD할 경우 접근제한자를 뭘 사용해야 할까요?
문자열 계산기를 만든다고 할 때 TDD 기반으로 한다면 뭐부터 시작해야할까요?
- Input과 Output를 기반으로 테스트를 만들어놓습니다
여러가지 방법
- default접근제한자를 사용합니다.
- public으로 메서드로 커버가 가능하다면 private 테스트는 지웁니다.(대부분 경우 이를 사용)
- 새로운 클래스로 분리합니다.
이 문제에 대한 논의는 유명한 slipp 사이트에서 찾아볼 수 있습니다.
Gradle 빌드도구
what is Gradle?
이전 세대의 빌드 툴(Ant, Maven)의 장점을 모아서 만든 차세대 빌드 툴입니다.
- 그렇기 때문에 Maven과 Gradle의 디렉터리 구조가 같습니다. Maven에서 디렉터리 구조를 정해뒀는데 Gradle이 이를 본딴 것이죠.
- 이를 통한 장점은 어디에 어떤 파일들이 있다는 것을 예측할 수 있기 때문에 좋습니다.
가장 큰 특징은 간단하게 작성이 가능하다는 점입니다.
Andorid의 기본 빌드도구입니다.
빌드툴이 뭘까요?
많은 빌드 과정을 한번에 처리해주는 도구입니다. 이게 없다면 수작업으로 일련의 작업들을 해줘야겠죠. 이를 통해 개발에만 집중할 수 있는 환경을 제공해줍니다.
규칙에 따라 디레거리 구조를 만들어 스크립트 내용을 크게 줄일 수 있습니다.
중앙저장소로 MavenRepository를 사용하고 있습니다.
- 어떤 Library를 추가하고 싶다면(예를들어 Lombok 등) MavenRepository에서 찾아서 gradle에서 어떻게 추가하는지 찾아서 사용하면 됩니다.
- 이를 통해 새로운 API를 사용할 수 있습니다!!(현재 레벨에서 필수적인 능력)
- groovy의 형식이 다양하기 때문에 만약 통일하고 싶다면 비슷하게 맞춰쓰면 잘 작동됩니다!
Core Concept
- Gradle을 통해 실행되는 단위를 task라고 합니다.
task brad << {
println "빵은 맛있다"
}
- 의존관계가 있으면 의존관계 먼저 실행하고 이후에 자신이 실행됩니다.
- 태스크 정의를 하지 않아도 이미 태스크가 정의되어 있는 것을 '내장 태스크'라고 합니다.
- 아래를 보면 여러 Task들이 빌드된 것을 볼 수 있습니다.
- 이런 task들을 추가하고 이런 과정들을 LifeCycle이라고 합니다.
build.gradle
buildscript { // 외부 라이브러리를 클래스path에 추가
ext { // extra(특별한) - 전역변수의 개념
springBootVersion = '2.1.0.RELEASE'
}
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}") // 스프링 부트 플러그인 의존성
}
}
apply plugin: 'java' // 자바로 개발할 때 필요한 기본적인 기능들이 담겨져 있습니다.
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
version = '1.0.0'
sourceCompatibility = 1.8 // 자바소스버전
repositories {
mavenCentral() // 메이븐 중앙 저장소를 저장소로 지정합니다. 이 지정을 통해 dependencies에 있는 것을 가져오는 것입니다.
}
dependencies {
compile("org.springframework.boot:spring-boot-devtools") // 컴파일시에 사용하는 라이브러리
compile('org.springframework.boot:spring-boot-starter-data-jpa')
compile('org.springframework.boot:spring-boot-starter-web')
compile('org.hibernate:hibernate-java8')
compile('pl.allegro.tech.boot:handlebars-spring-boot-starter:0.3.1')
runtime('com.h2database:h2') // 런타임 시에 사용하는 라이브러리
runtime('net.rakugakibox.spring.boot:logback-access-spring-boot-starter:2.7.1')
testCompile('org.springframework.boot:spring-boot-starter-test') // 테스트시 사용하는 라이브러리
testCompile('org.assertj:assertj-core:3.10.0')
testCompile('org.apache.httpcomponents:httpclient:4.5.6')
}
라이브러리 작성법
- 그룹 : 기업 및 단체 / 이름 / 버전
'TIL' 카테고리의 다른 글
Today's Dev Notes(2018-12-11) (0) | 2018.12.11 |
---|---|
Today's Dev Notes2(2018-12-10) (0) | 2018.12.10 |
Today's Dev Notes(2018-12-09) (0) | 2018.12.09 |
Today's Dev Notes(2018-12-08) (0) | 2018.12.08 |
Today's Dev Notes(2018-12-06) (0) | 2018.12.06 |