현재 fare 미션에서 DB...
- QS. 4개의 WAS가 모두 하나의 DB Table을 공유 중인데 괜찮나요?
- 파피 서버에서 등록한 역이 내 서버에서도 보이게 됨
- Ans. 구구의 피드백
- DB 인스턴스 하나만 쓰더라도 데이터베이스를 분리해줘야함 (데이터베이스가 섞임)
- A유저의 서버에서 쌓은 데이터가 B유저의 서버에 영향 주면 X
- Ans. 씨유의 피드백
- 같은 DB 인스턴스 이면서 같은 DB를 구성했다면 트랜잭션/동시성을 고려해야 함
- 만약 논리적으로 구분되어 있다면 커넥션 관리, 메모리 관리 등 리소스 관리만 해주면 됨
- 아마도 이번 미션의 의도 자체가 독립적으로 동작하는 백엔드 서버를 만드는 것이였던 것 같음!
- 우리 팀원들은 약간 load balancing 감성의 WAS 구성을 했던 것 같음
핵심 내용
- 에외를 처리할 때 반드시 지켜야 할 핵심 원칙
- 모든 예외는 적절히 복구
- 작업 중단 시키고 개발자에게 통보
- 자바에서 throw를 통해 발생시키는 에외는 크게 3가지
- Error
- 시스템 레벨에서 특별한 작업하는게 아니라면 애플리케이션에서 신경 쓸 필요 X
- Exception... (CheckedException)
- 자바 언어와 JDK의 초기 설계자들은 체크 예외를 발생 가능한 예외에 모두 적용하려고 했음
- RuntimeException... (UncheckedException)
- 프로그램의 오류가 있을 때 발생하도록 의도된 것
- 피할 수 있지만 개발자가 부주의해서 발생할 수 있는 경우 사용
- 자바에서 예외를 처리하는 방법은 3가지
- 예외 복구
- 예외 처리 코드를 강제하는 체크 예외들... 어떤 식으로든 복구 가능성이 있는 경우 사용
- 예외 처리 회피
- 예외 복구 처럼 의도가 분명해야 함
- 긴밀한 관계에 있는 다른 오브젝트에게 에외처리 책임 분명히 지게 하거나
- 자신을 사용하는 쪽에서 예외처리하는게 최선의 방법인 경우 사용하자
- 예외 전환
- 발생한 예외를 그대로 넘기는 게 아닌, 적절한 에외로 전환해서 던짐
- 전환 예외는 발생한 예외를 담아 "중첩 에외"로 만들어 주자
- 체크 예외 --> 런타임 에외
- 예외 처리 전략
- 낙관적인 예외처리 기법
- 예외가 생겨도 런타임... 시스템에서 알아서 처리
- 런타임 예외라도 잡아서 복구하거나 대응해줄 수 있음
- 서버 환경... 수많은 사용자가 동시에 요청을 보내고 각 요청이 독립적인 작업으로 취급
- 해당 작업만 중단시키면 그만
- 항상 복구할 수 있는 예외가 아니라면 언체크 예외로 만듬
- 대개 복구가 불가능한 상황이라 포장해서 던져야 할테니, API 차원에서 런타임 예외를 던지도록 함
- 런타임 예외 사용하는 경우 API문서나 레퍼런스 설명을 통해 예외 종류/원인/활용법을 잘 설명해둘 것
- 애플리케이션 예외
- 애플리케이션 자체의 로직에 의해 의도적으로 발생시키고 반드시 catch 해서 무엇인가 조치를 취하도록 요구하는 예외
- 의도적으로 체크 예외를 만들기
- SQLException은?
- 대부분의 SQLException은 복구 불가능... 언체크/런타임 예외로 전환해줄것!
- 스프링의 JdbcTemplate... SQLException을 DataAccessException으로 포장해서 던져줌
- 예외 전환
- 목적
- 런타임 예외로 포장해서 굳이 필요하지 않은 catch/throws 줄여주기
- 로우레벨의 예외를 좀 더 의미 있고 추상화된 예외로 변경
- JDBC의 한계
- DB마다 비표준 SQL이 있음
- DB마다 에러의 종류와 원인이 제각각
- SQLException을 던져주는데...
- 다양하게 발생하는 예외를 그냥 SQLException 하나로 퉁침
- DB에 독립적이고 유연한 코드를 작성하는 것 불가능
- JdbcTemplate은 SQLException을 DataAccessException으로 포장
- 스프링은 DB별 에러코드를 분류해 에외 클래스와 매핑해 놓은 매핑정보 테이블 만들어 이를 활용
- DAO 인터페이스와 구현의 분리
- DAO는 인터페이스를 사용해 구체적인 클래스 정보와 구현 방법 감추고 DI를 통해 제공되도록 하는 것이 바람직
- 근데 DB 접근 구현 기술마다 던지는 예외가 다름
- DAO 사용하는 사용기술에 따라 예외 처리 방법이 달라져야함
- DAO에서 사용하는 기술의 종류와 상관없이 동일한 예외 얻고 싶다면... 커스텀 예외 정의해두고 이걸로 전환해야함
단위 테스트
- 프로그램의 기본 단위인 모듈을 테스트
- A가 실행되면 B가 나온다
- 내부 구조를 모두 확인 가능한 "화이트 박스" 테스팅 수행
- 응용 프로그램의 내부 구조, 동작을 디테일하게 검사
- 가장 작은 단위의 테스트, 보통 메서드 레벨
- 즉각적인 피드백
통합 테스트
- 단위 테스트가 끝난 모듈을 "통합"하는 과정에서 버그를 찾는 테스트
- 모듈간의 상호작용이 잘 이루어지는지 확인
- 모듈간의 호환성 문제 확인해보자
- 동시식/하향식/상향식/연쇄식
인수 테스트
- 사용자 스토리에 맞춰 테스트 작성
- 사용자 환경에서 테스트한다!
- 시나리오를 받아서 거기에 맞춰 개발하기 위함
- 시나리오가 정상적으로 동작하는가?
- 시나리오: 누가, 어떤 목적으로, 무엇을 하는가
- 기획자/클라이언트 대표/개발자 등 프로젝트에 참여하는 사람들이 토의해서 시나리오 만들고 코드로 옮겨오는 방식