2019.11.16 KSUG 하반기 가을세미나 참석 후기
더 자바 코드를 테스트하는 다양한 방법 - 백기선
최근 MSA 환경에서 다른 시스템이나 데이터 중심의 테스트코드를 작성해야 하는데, 이를 해결하기 위한 좋은 방법이 될것 같다는 생각이 들었다.
그리고 테스트환경을 실제 환경하고 동일하게 해야한다에 대해서 여러 의견이 많지만, 동일하게 해야 한다는 관점에서 좋은 방법을 제시해 주셨던 것 같다.
- 발표자료: https://bit.ly/2q8S3Qo
세션 내용
Spring Boot 2.2 가 릴리즈 되면서 JUnit 5 가 추가되었다.
Jupiter (junit 5 프로젝트명) 는 하위호환이 되지 않고 vintage engine 을 추가 해야한다.
Spring-boot-starter-test 2.2.x 에는 vintage engine 이 추가 되어 있는데 신규 프로젝트의 경우 헷갈릴수 있으니 exclude 시키고 하자
Junit5 의 특징대해서 설명들이 있는데, 공유된 발표자료와 볼만한 링크를 참고 바란다.
강의의 내용은 mocking 했던 외부 자원들을 도커라이징 하면서 최대한 production 환경과 유사한 테스트 환경을 과정을 설명과 실습을 해주셨다.
TestContainers 라는 어노테이션으로 테스트 수행시 docker 컨테이너를 수행할 수 있다.
Spring 프로젝트를 docker 로 패키징 할 수 있는 모듈
Jib: 구글에서 만든 container tool
Maven: https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin
Grande: https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin
외부 Rest API 서비스 들에 대해서도 실제 API 호출이 될 수 있게 테스트환경을 구성 할 수 있었다.
Docker-compose 를 통해서 api application / database 를 쉽게 연동 할 수 있다.
JUnit exteion Rule 을 이용한 docker-compose 연동: https://github.com/palantir/docker-compose-rule
그리고 카오스 몽키 라이브러리를 통한 로컬환경에서 공격을 실제로 시도하는 시연을 해주셨음
더 자바 코드를 조작하는 다양한 방법 - 백기선
발표자료: https://bit.ly/2NPT7Bq
시간이 부족해서 많은걸 보여주시진 못했던 것 같다.
발표자료를 보셔도 되고 가능하면 인프런 강의 를 수강하시면 더 자세하게 배울 수 있다.
자바한정: null 서바이버 가이드 - 박성철
개인적으로는 최근에 Kotlin 을 공부 하고 있었는데, Java에 대해서 마냥 비판만 하지 않게 해준 세션이였다. Java 진영에서도 Null 안정성에 대한 논의가 꾸준히 이루어 지고 있고, 새로운 라이브러리도 많다. 그리고 Null Type 도입으로 안전하게 한다고 하지만 실제 사용해보면 Kotlin 도 null 에 대해서도 완벽하게 안전하지 않다고 한다.
그리고 checkerFramework 는 꼭 써봐야 겠다. 그리고 회사 프로젝트에 null check 에 대해서 어떻게 하는게 좋을지 논의를 해보는것도 좋을 것 같다.
세션 내용
- 코드에 책임을 지나요?
- 책임을 지는 코드에 대한 이야기
- 토니 호어
- 레코드 핸들링, c 구조체, 객체지향의 클래스의 근간이 된 논문
- 참조 타입, 레코드와 레코드간의 관계
- 2000년대 중반부터 널 안정성에 대한 중요한 화두가 됨
- Bertrand meyer 논문
- 널 안전연산자
- 널 병합 연산자
- 엘비스 연산자 ?:
- A ?: b -> 그루비 obj-c 코틀린 php
- A ?? B -> js, c#, swift, ts, php
- A or b -> python
- a // b -> perl
- null 조건 연산자 (safe navigation operator)
- Let zipcode = user?.address?.zipcode;
- method chaining 할때 사용한다 (추천하지 않음)
- 널 병합 연산자
- Type System 강화
- 컴파일 타임에 NPE 를 체크 해준다.
- Nullable type: kotlin, c#
- 그럼 java 에서는 Null 을 어떻게 할것인가?
- 기본적으로 null 을 쓰지 말자
- Intellij: @ParametersAreNonnullByDefault
- Null 문맥을 제한된 범위 안에 가두자
- Alan kay -> 객체지향 프로그래밍 말을 만든사람
- OOP to me means only messaging, local retention and protection and hiding of state-process, and extreame late-binding of all things.
- CS 대원칙, “큰 문제를 제어 가능한 작은 문제로 나누어 정복하고 다시 통합한다”
- 좋은 캡슐화
- 높은 응집성
- 모든 필드가 객체와 생애주기가 같다.
- 모드 메소드는 모든필드를 대상으로 작업한다.
- 낮음 결합
- 디미터 법칙, 묻지말고 시켜라(Tell, Don’t Ask)
- 인터페이스에 의존
- 에거리것 루트로만 객체 그룹에 의존
- 높은 응집성
- API 에 최대한 널을 쓸지 말자
- 빈컬렉션이나, null 객체를 활용
- 반환값이 없으면 Optional 로 하자
- 오류상황에서는 null 을 리턴하지 말고 예외를 던져라
- 선택적 매개변수는 메소드 오버로딩을 이용해라
- NULL 객체를 활용하자
- 리스코프 치환 원칙 주의
- 디미터의 법칙을 잘지켜야 유용하다
- NullObject 패턴 - 이종립 님 글
- Null 을 명시적으로 표현하자
- Optional
- 불필요한 박싱/언박싱을 피하자. Effective java #55
- 단점, 시리얼라이즈 안됨: (개선중) https://cr.openjdk.java.net/~briangoetz/amber/serialization.html
- Value Based Object 는 현재 직렬화를 못한다.
- 현재는 반환값으로만 쓰자.
- 기본 타입용 optional 을 잘 쓰자
- optional 을 어떻게 써야하는지에 대한 내용의 유투브
- Design By Contract
- 자바용 라이브러리는 거의 없음
- 구조체에는 펑터를 활용하자
- 객체는 추상화로 데이터를 뒤에 숨기고 대신 이 데이터를 다루는 행위를 노출한다. 데이터 구조체는 데이터를 노출하고 의미 있는 함수를 갖지 않는다.
- Mapper 를 상속해서 functor 를 이용한다.
- 개인적으로는 엄청 유용했던 기능들 실제 사용해 볼 수 있을까?
- 객체의 기본값을 유용하게 만들자.
- 테스트 코드로 null 을 안전하게 다루는것, (직접 해보진 않으셔서 그렇다고만..)
- 기본적으로 null 을 쓰지 말자
- 널이 안전하다고 점검해주는 도구
- 정적분석도구
- 스팟벅스
- 인텔리제이 제공 어노테이션
- 제 브레인 어노테이션 JSR305 참고한 애너테이션
- 롬복, 우버,, nullway ?
- 스프링 JSR-305 지원, 추가로 널 안정성 지원
- 매개변수, 반환값, 필드에 지정가능
- 필드까지 지원가능
- JSR-308 타입 어노테이션
- Chker Framework (https://checkerframework.org/manual/#installation)
- null 안정성 확인, 현재 java 8 이상 11 버젼까지 지원함
- 기존에 많이 쓰는 라이브러리들의 annotaion 을 이해하고 모두 지원한고 있다.
- 정적분석이 아니라 실제 타입시스템을 확장한 것이다.
- 정적분석도구
잘 키운 모노리스 열 마이크로서비스 안 부럽다 - 박용권
하나의 조직에서 과도하고 시스템을 분리할 이유는 없어 보인다. 그렇다면 하나의 조직에서 다양한 도메인을 다룰때는 어떻게 추상화 하고 모듈화 할것인가에 대한 답인데, 현재 조직에 처한 상황이기도 해서 관심깊게 보았다.
- 발표자료: https://www.slideshare.net/arawnkr/ss-195979955
- github: https://github.com/arawn/building-modular-monoliths-using-spring
세션 내용
MSA 를 선택하는 이유
- 기술부채
- 조직이유
- MSA 를 운영하면서 있었던 문제점,
- 데이터원본을 공유 하고 있다. (데이터 모델)
- 여러개의 서비스가 똑같은 테이블
- 지나치게 수행하는 작업이 복잡하다.
- 배포의 타이밍을 맞춰서 하게 된다
- 데이터원본을 공유 하고 있다. (데이터 모델)
- MSA 를 운영하면서 있었던 문제점,
- 응집과 결합을 다스리는게 먼저다
- 그이후에 적절한 도구를 선택하는게 맞다. 모닐리스 vs MSA
- 모듈형 모노리스
- 필요하다면, 마이크로서비스로 손쉽게 확장할 수 있다.
- 2018 사이먼 브라운 발표 영상 에시 이미 다룸
- clean 아키텍처 166page
- 좋은 아키텍처는 시스템이 모놀리틱 구조로 태어나서 단이 ㄹ파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장 할 수 있또록 만들어져야 한다.
- 그렇다면 어떤걸 잘지켜야 될까?
- 첫번째, 모듈화 가능
- 두번째, 변경가능성있는것들에 대한 (오각형) 추상화 (자료를 찾아서 다시 업데이트 예정)
- https://github.com/arawn/building-modular-monoliths-using-spring
- 반부폐 계층
- Gradle multi project
- Spring context 를 다르게 해서 접근을 못하게 해준다.
- Repository 가 멀티 모듈시 접근될수 있다.
- Why? Spring 의 빈의 전역이니깐
- 구현된 부분의 코드
- 본이 이외 실제 시도하고 있는 프레임웍들
같이 보면 좋은 내용
안정된 의존관계 원칙과 안정된 추상화 원칙에 대하여 -> 어떻게 추상화 할 것인가?
클린 아키텍쳐 -> 시스템 차원에서 추상화에 대한 내용
멀티모듈 설계 이야기 with Spring, Gradle -> 멀티모듈을 어떻게 구성 할 것인가?
스프링 부트 기반 멀티모듈 프로젝트 구성 가이드 -> 이전 조직에서 사용하던 멀티모듈 구성 가이드