04~05일 한일

- 트렐로 시작 전 객체에 대한 UML, ERD 그려보기

이틀에 걸쳐 TIL을 작성하게 된 원인으로 UML, ERD에 잘 못 알고 접근하다 첫날 삽질 함…

- Spring DI에 대한 QnA 시간

ApplicationContext에 등록할 AppConfig 클래스에서

@Bean
public DataSource dataSource() {
  BasicDataSource ds = new BasicDataSource();
  ds.setDriverClassName(DB_DRIVER);
  ds.setUrl(DB_URL);
  ds.setUsername(DB_USERNAME);
  ds.setPassword(DB_PW);
  return ds;
}
@Bean
public JdbcTemplate jdbcTemplate(DataSource dataSource) {
  System.out.println("jtjtjtjtjtj");
  return new JdbcTemplate(dataSource);
}

Controller, Service, Repository 객체 외에 위처럼 @Bean으로 Spring 빈 컨테이너의 빈으로 등록하면 생기는 이점으로 간편히 내가 원하는 JdbcTemplate를 바꿔 등록하는 것만으로 손쉽게 다른 Jdbc를 사용할 수 있다.

applicationContext를 이용하면 bean factory를 사용할 때와 다른 점은 이벤트를 지원한다는 것인데 자바스크립트의 리스너와 비슷하게 특정 동작이 실행되면 그에 따른 후속 동작을 설정할 수 있다. (관련 키워드 : 트리거, 리스너, 콜백, 옵저버 패턴)

빈 컨테이너의 생명 주기는

ServletRegistration.Dynamic dispatcher = servletContext.addServlet("next", new DispatcherServlet(webContext));

보시다시피 서블릿과 같이 한다.

Bean Initialize와 Destroy : 빈이 생성되고 소멸(?) 될 때 자동적으로 수행 시켜야 할 초기화, 제거 작업들을 구현할 수 있다.
특정 Interface를 구현해 Initialize와 Destroy 작업을 구현할 수 있다.
- XML 설정 파일은 init-method, destroy-method를 지정해 Initialize와 Destroy 작업 메소드를 지정
- 메소드 레벨 @PostConstuct, @PreDestroy 애노테이션을 통해 Initialize와 Destroy 작업 메소드를 지정
빈 컨테이너를 이용하는 경우
```
public class AnswerDao {
	private static AnswerDao answerDao;

	private AnswerDao() {}

	public static AnswerDao getInstance() {
		if (answerDao == null) {
			answerDao = new AnswerDao();
		}
		return answerDao;
	}
```
위와 같이 static 인스턴스 하나를 통해 싱글톤을 유지하는 것이 아니라 빈 컨테이너에 일반적인 인스턴스 하나를 저장해 둔다.

차후 빈 컨테이너를 통해 해당 빈을 이용하면 계속 같은 인스턴스를 받게 된다.

- Java static의 공유 범위

Java static의 공유 범위는 Classloader 기준이다.

Tomcat7의 Classloader 구조도

톰켓은 각 Web Application마다 classloader를 따로 사용
메모리에 불려 오는 순서
```
Bootstrap -> System -> Common -> Webapp1, Webapp2
```
이 순서로 해당 static 인스턴스를들이 메모리에 적재되기 때문에 차후에 불려오는 곳에선 이미 존재하는 static 인스턴스를들을 참조 가능하다.

즉, Common에 static으로 선언되면 Webapp1과 Webapp2가 동일한 인스턴스를 참조한다. (출처)

- ATDD 강의

atdd

VModel

아주 당연하게 설명하면 TDD가 단위 테스트부터 시작하듯이 인수 테스트부터 시작하면서 개발

통합 테스트 (출처)
- 모듈을 통합하는 과정에서 수행 되는 테스트
- 모듈 간의 상호 작용이 올바르게 되는지를 검사하는 테스트
- 통합 테스트에서 오류가 발생 되는 경우
  - 개별적인 모듈에 대한 테스트가 불충분하여 오류가 발생
  - 제한된 상황만을 고려하여 작성한 테스트 스텁으로 인해, 실제 모듈과 통합 하는 과정에서 오류가 발생
  - 전역 변수 등으로 인해 모듈간의 예기치 못한 상호 작용이 발생하여 오류 발생
인수 테스트
- 사용자 입장에서, 실제 사용자 환경에서 테스트를 수행
- 인수 기준을 만족하는 가를 검사하는 것이 주요 목적

04~05일 느낀점

UML, ERD에 대해 아예 잘못 접근하는 바람에 4일 작업 한건 다 날리다시피 했는데… 그래도 오늘은 ERD에 대한 큰 그림은 어느 정도 끝난 것 같다.(그러나 영 불안하다..) 일단 UML도 작업해 본 다음 제대로 그려보자.
Spring DI에 대한 QnA 시간을 가졌는데 요즘 머리가 굳은 느낌이었는데 포비가 답변을 유도하는 과정에서 오랜만에 두뇌 활동을 제대로 한 것 같다. 그 감각을 제대로 유지해 두 자. 아, 빈 컨테이너에 대해 확신도 못 가지고, 개념도 제대로 세우지 못하고 있었는데 QnA 시간을 통해 제대로 알아 둘 수 있게 된 것 같아 다행이다. (질답 시간에 제대로 이해 못한 개념이 있는데, 오늘은 잠 좀 푹 자고 좀 더 정신이 맑은 상태서 더 생각해보자)
Classloader 관련해서 static 인스턴스의 참조 가능 영역을 위에 참조한 그림 상에서 위에 위치하는 것을 상위 클래스라고 아예 거꾸로 생각하는 바람에 이해가 안 됐는데 그 부분을 포비가 교정을 해주셔서 제대로 이해하고 넘어 가게 됐다. 해당 부분을 질문할까 말까 하다가 물어봤는데 안 했으면 큰일 날뻔했다. 해당 자료를 준 브라이언한테도 감사하다. static인 경우와 빈 컨테이너로 관리할 때의 차이에 대해 어렴풋이 생각하던 개념을 정리할 수 있었다.
ATDD에 대해 배웠는데 저녁에 해당 내용 좀 보다가 잠시 아밍과 대화 중 통합 테스트와 인수테스트의 차이점에 대해 구분이 잘 안돼서 고민 하다가, 야근 중이시던 JK한테 문의! V 모델을 통해 설명을 해주셨는데
원래 주말에 자꾸 잊어버려 가는 레벨 4를 복습해보려 했는데 ATDD가 재밌어 보인다. 이미 자주 해본 반복 주기 내용을 ATDD로 개발을 해보면 좋은 연습이 될 것 같다. 흐음… 좀 더 급한 건 복습인데 주말에 아마도 ATDD 연습을 할 확률이 높을 것 같다.

내일 할일

trello에 대한 UML, ERD 작성
ATDD 연습 혹은 레벨 4 복습 시작
Spring DI에 대한 복습

180104~5-TIL

January 05, 2018