Sean :: Dev

21.04.15) 오늘의 기록 - 날뛰는 팬소음과 Google Chrome Helper

os94 — Thu, 15 Apr 2021 21:58:46 +0900

작업을 할때 이것저것 많이 켜두긴 하지만, 그래도 특별히 빌드 돌릴때 아니면 팬이 미쳐 날뛰지 않는데,

오늘은 유난히 계속해서 맥이 이륙하려 날뛰었다.

해결후 캡쳐한거라 보이지 않지만, 문제의 Google Chrome Helper (Renderer)가 CPU를 미친듯이 먹고있었다.

Chrome Menu → Window → Task Manager 로 진입해 확인해보니,

보통 일부 크롬 플러그인이 리소스를 잡아먹기도 한다는데,

난 크롬 탭중에 특정 Grafana 페이지가 무슨 비트코인 채굴마냥 리소스를 다 먹고있었다. (그래프가 좀 많긴 하더만은...)

종료시켜주니 이제야 맥이 좀 쉰다,, 고생시켜서 미안

비전공자를 위한 개발 입문 정보

os94 — Mon, 15 Feb 2021 21:00:55 +0900

배경

아직 내 앞가림도 제대로 못하는 병아리 신입 개발자이지만, 고등학교 3년동안 희망직업이 교사일 만큼 나는 지식 전파와 학습법 공유 등에 꽤나 재미를 느낀다
나도 출발이 비전공자라서 주변에 인맥도 없고 정보의 가뭄 속에서 오래 고생했던 경험이 있기에, 이런 부분들에 더 집착하는 경향이 있는것 같기도 하다
- 개발에 어떤 분야들이 있는지, 각각은 어떤 특징과 장단점을 갖는지, 어떤 공부를 어떻게 해야하는지 등 열심히 인터넷 서칭을 하지만 유용한 정보를 얻긴 힘들고 (주로 나오는건 학원 광고들뿐..), 인강을 단순무식하게 외우는 등 비효율적으로 학습을 삽질했던 때를 기억하면, 지금도 속 쓰리곤 한다
- 지금도 가끔가다 Collection 프레임워크 메서드 종류를 종이에 써가며 학습하시는 분을 보면, 마음 한켠이 먹먹하다 ㅜ
요즘 타 전공을 하다가 코딩쪽으로 넘어오는 경우가 많기에, 나 역시도 주변의 친구/지인들에게 내가 아는 것을 공유하고 개발자가 되려는 노력을 직간접적으로 돕곤한다. 겨우 일이년 빠른 것 밖에 없지만, 내 과거의 답답함을 생각하며 과한 오지람으로 친구들에게 이리저리 간섭한다
내가 주변 친구들에게 공유하는 내용들이 반복되다 보니, 이참에 아예 이렇게 글로 정리해보았다. ~~중복 제거는 개발자의 숙명..~~
이 글은 개발을 아예! 모르는 내 주변의 입문자 친구들을 대상으로 쓴 글이기에, 대부분의 개발자분들은 물론 git을 써봤다 하시는 분들은 뒤로가기를 눌러 소중한 시간을 절약하셔야 한다! (early return plz.)

왕초보 :: 가장 먼저 해야할 것

아마도 가장 처음에 할 고민, 내가 개발자에 맞을까 ?

여러 방법이 있지만, 보통 파이썬 기본서를 사서 문법을 익히고 알고리즘 문제를 풀어보며 코딩을 맛보기도 하는데 이런 방법보단, 생활코딩(이외에도 기초수준의 컨텐츠를 제공하는 많은 부트캠프, 사이트, 인강들이 있다) 같은 사이트를 이용해 기초적인 수준의 HTML+JS 홈페이지를 만들어보며 내가 개발에 흥미를 갖고있는지 확인해보는 것을 추천한다
아주 rough하게 요약해본 개발자의 이미지
- 장점
  - 기술직이라서 어디가도 굶어죽진 않겠다는 안심(?)
  - 워라밸은 사실 회사/팀마다 편차가 큰 것 같다. 그치만 전반적인 회사 자체의 분위기는 IT 서비스 기업 기준, 대부분 수평적이고 자유로운 문화라서 스트레스가 덜하다
  - 내가 만든 결과물이 서비스/동작되는 것을 보며 느끼는 성취감
- 단점
  - 평생 공부할 자신이 있는가 (퇴근후, 주말에도 스스로 공부하는 삶)
  - ~~나도 모르게 개발/코딩 관련 밈에 중독되며, 친구들에게 너드 취급을 받을 수 있다...~~
- 사견
  - 난 우연히 접한 코딩이 너무 재밌어서 넘어온 케이스지만, 요즘 타 전공에서 많이 넘어오며 기대했을 일자리/채용공고 자체는 확실히 많은 편이다. 하지만 개발은 무엇보다도 흥미를 많이 타는 직종이라 한번 경험해보고 자신에게 맞는지 확인해보는게 좋을 것 같다

Github 계정부터 만들기
- TIL 추천 (초반 공부습관 형성 & 문서지만 눈에 보이는 결과물의 성취감)
notion, 블로그 등 공부한 것을 정리할 수 있는 공간 만들기
- 티스토리, 깃헙 블로그, velog 등 (굳이 네이버 블로그로만 시작하지 않으면 될 것 같다)
개발자 내에서도 진로 정하기
- 주의 - 인터넷 서핑과 머리속 고민만으론 1년을 고민해도 절대 결정 못한다
  - 다양한 분야를 공부하는걸 언어도/지식도/프레임워크도 모두 다르기 때문에 시간이 아깝다고 느껴서, 실제로 손은 안 대보고 "뭐하지" 고민만 하는 경우가 있는데 이래선 절대 고민이 해결 안된다
  - → 결국 분야별로 한번씩 직접 경험해보면서 자신의 흥미를 찾아야한다. 따라서 결정하는데 최소 6개월은 걸린다고 본다
- 주요 분야
  - 백엔드
  - 프론트엔드
  - 모바일&앱
  - 그 외 (AI, 데이터 쪽은 일반 서비스개발과는 별개의 분야로 보자)
- 개인적인 의견
  - 분야별로 한번씩 경험해보는 것을 추천했는데, 프론트의 경우 어짜피 JS를 공부해야하고, ios에 관심이 있다면 스위프트를 해볼 것이다.
  - 백엔드는 상대적으로 선택지가 다양한데 JS로 Node.js를 해볼수도 or Java로 Spring을 해볼수도 or Python으로 Django를 해볼수도 있다.
  - 이때 만약 자바로 백엔드를 경험해본다면, 자바에 익숙하므로 안드로이드도 경험해볼수있다(물론 제대로 하겠다면 코틀린을 공부해야겠지만) (백엔드 프레임워크 점유율이 자바X스프링이 가장 많은건 덤!)
  - 물론 JS로 프론트/서버/앱 전부 체험해볼 순 있지만, JS와 Java는 언어체계가 다르므로 둘 다 경험해보는걸 추천한다. ~~내가 자바개발자라 자바를 추천하는건 아님~~
  - 결론
    - 프론트 개발을 체험해보고싶다면, TODO 리스트 만들기 를 해보자. 이 부분과 관련된 컨텐츠는 넘쳐날것
    - 백엔드 개발을 체험해보고싶다면, 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 책을 참고해보자
분야를 정했으면, 이제 그쪽에 관련된 공부만 올인하면 된다
- 개발자 취준은 다른 분야 - 대표적으로 고시류 시험(몇년이 걸려도 된다는 보장이 없다)과 달리,
  신입 개발자로 취직하기 위한 어느정도의 "지식의 총량"이 정해져 있어서, 사람마다 소요 시간은 다르겠지만 어쨌든 바른 방향으로 공부를 계속 하다보면 언젠가는 도달할 수 있다고 생각한다
- 무작정 양치기로 공부하지말고 유명한 로드맵을 찾아보자
- 프레임워크 학습도 물론 어느정도 필요하지만 매몰되지 말자. CS나 이론적인 내용들에도 갈증을 느끼자

TIP

notion 활용
- 문서&필기 등 공부한 내용을 정리하는 용도로 사용. 에버노트의 업그레이드 버전이라고 보면 된다
- 원래 유료였으나 무료로 바뀌어 강추. 모바일 앱도 있음
- 더이상 로컬 파일 지옥에서 벗어나자
Github 꾸미기
- 깃헙은 신입개발자의 이력서
- 깃헙을 꾸미고 포장하다보면 포장할 꺼리를 채우기 위해, 학습을 더 열심히 하게 된다
- 예시 : TIL, Github Profile, Github Blog, 알고리즘 문제풀이같은 각종 공부 내용 정리 Repo 등
채용 공고 수시로 확인
- 네이버&카카오 상시 채용 공고가 항상 올라와있으니, 자주 눈팅하면서 어느 직군을 많이 뽑고 어느 기술셋을 필요로 하는지 동향을 파악하자 → 무엇을 공부해야하는지로 연결
목표 기업 선정
- 의외로 처음엔 회사들의 categorizing도 힘들어하는 경우도 있어 일단 나열해보았다
- 서비스 기업 : 네이버, 카카오, 라인, 쿠팡, 배민, 토스, 당근마켓, 야놀자 등
- 대기업
- SI (삼성 SDS, LG CNS, SK C&C ...)
- 통신사
- 게임사
- 등등 ..

교육과정/부트캠프

검색하다보면 정말 많은 사설학원, 교육기관들이 존재한다. 본인의 소중한 시간과 돈을 투자하는 선택인데, 부디 충분하고 신중한 고민을 거쳤으면 좋겠다. 언급할 순 없지만, 주변에 안타까운 케이스도 봤어서..

아래는 어느정도 신뢰성이 보장된 과정들이며, 경쟁이 세지만 도전해보자. 물론 각 과정들마다 배울수있는 부분들이 다르므로 알아보고 충분히 이해하자.

아래의 유료과정들은 비용부담이 있겠지만 자신있게 추천할 수 있다.

추가로 국비과정에 대한 의견은 짧게 요약하기 어려워 생략하며, 영향력있는 두 분의 글을 첨부해본다.
jojoldu님 체대생개발자님

우아한테크코스/캠프 (우아한형제들)
부스트캠프 (NAVER)
이노베이션 아카데미_42 Seoul (정부)
SAFFY (Samsung)
SW사관학교 정글 (KAIST) [유료]
nextstep [유료]
코드스쿼드 [유료]

인터넷 강의

학부때 듣고 졸업하길 추천하는 CS 과목

네트워크, OS, DB
알고리즘, 자료구조
컴퓨터구조

개발 동아리

대학생때 해보려고 리스팅 해둔 목록인데, 관심있는 사람에겐 인터넷 서칭 시간이라도 아낄수있겠지하며 적어보았다.

~~경험해본적은 없으므로 내부사정은 잘 모른다. 유지가 잘 안되는 곳도 있는 듯..?~~

멋쟁이사자처럼
Nexters
SOPT
YAPP
CADI
REAL
프로그라피
디프만
Mash Up

다 쓰고 나니 드는 생각은 역시.. 내 앞가림이나 잘 해야겠다...

JPA의 사실과 오해 (사실은 JPQL과 Fetch Join의 오해)

os94 — Mon, 25 May 2020 23:12:08 +0900

JPA의 사실과 오해 (사실은 JPQL과 Fetch Join의 오해)

20.05.25 JPA 스터디 하며 깨닫게 된 오해

JPA를 꽤나 오래 써왔는데(그래봤자 1년이긴 하지만), 이번에 스터디를 하며 크게 잘못 알고 있던 개념 몇가지를 정정하고, 스스로 부끄럽기도 하고 나름의 컬쳐쇼크를 받았다.

1. N+1은 연관 엔티티가 Collection인지가 중요한게 아니다.

( 주의 - JPQL 기준, SQL X )

사실 왜 (당시 스터디하던) 우리 모두가 N+1 문제를 연관 엔티티의 컬렉션 여부와 관련지어 생각해왔던 건지 모르겠다. 대부분의 교재나 링크들에서 Member -* Orders 와 같은 일대다의 관계를 예시로 들며 설명하기 때문일까.

나는 이제까지 N+1 이 member.getOrders() 의 컬렉션 프록시의 초기화와 관련해, member.getOrders() 혹은 member.getOrders().get(0) 을 호출할 때, orders 컬렉션의 size 만큼 쿼리가 더 나가는, 그래서 그걸 방지하기 위해 Fetch Join을 걸어야하는 그런 걸로 생각하고 있었다.

(이부분은 좀더 내 개인적인 부분인데, 개인적으로 N+1 이라는 용어를 초반에 패치 조인을 안걸어서 비즈니스 로직 중간에 의도치 않은 쿼리가 나가는 현상 전체를 가리키는, 좀더 넓은 범위의 용어로 써오기도 했었다. 내 머리속에선)

결론은 틀렸다.

Member -* Orders 의 관계 예시에서, Member의 Order 필드가 컬렉션인지는 중요한게 아니다. 즉, order 인지 orders 인지가 중요한게 아니다.

초점은 오히려 Order 엔티티가 아닌 Member 엔티티다.

혼란을 방지하기 위해, Member - Order 의 일대일 관계로 예시를 수정해보자.

member1 인스턴스를 가져오는 상황이라고 가정하자.

추가로 N+1 은 Eager인지 Lazy인지도 중요하지 않다는 사실도 안다고 가정. (지연 로딩이어도, 나중에 해당 데이터가 사용되는 시점에 프록시가 초기화되며 쿼리가 나간다)

member1 을 가져오는데, 패치 조인을 걸지 않으면 member1.order 값도 가져오기 위해 추가로 쿼리를 날려야 한다. 이 경우, 날리는 쿼리의 횟수는 1+1 = 2회다.

이 때, 애초에 member1을 가져올 때 패치 조인을 걸면 member1.order 값도 함께 (한 쿼리로) 가져올 수 있다. 그렇게 되면, 날리는 쿼리의 횟수는 1+1 = 2회에서 1회로 줄어든다.

이게 그렇게 유명한 패치 조인 의 효과다.

겨우 2→1 회 줄어들었는데, 무슨 차이일까?

만약, 애초에 상황이 member1 인스턴스만 가져오는게 아니라, member1, member2, member3 ... member5000 까지, 5000명의 멤버를 가져오는 상황이였다면 달라진다.

이 경우, 1+5000 → 1 로 크게 줄어드는 것이다.

1+5000 → 1 을 부연 설명하면,

1 (member1~member5000 가져오기) + 5000 (member1.order 가져오기, ... , member5000.order 가져오기) → 1 (앞의 데이터 모두 한번에 가져오기. 물론 리턴값은 List<Member> 즉 member1~member5000 그대로, 대신 member1.order~member5000.order의 데이터는 영속성 컨텍스트 안에 존재)

이게 패치 조인의 효과다. 괜히 여기저기서 패치조인, 패치조인하며 자주 사용되던게 아니었다.

그렇다면, 이걸 다 이해했다고 치고 평소에 편하게 개발할 땐, 무엇을 생각하고 기준으로 삼으며 판단하면 될까 ?

[ 결론 ]

가져오려는 엔티티의 연관 엔티티가 컬렉션인지 or 단일 객체인지에 상관없이,

(물론 연관 엔티티 데이터를 쓴다는 전제하에) 리턴 타입이 List<?>면 패치 조인을 거의 무조건 걸어야 한다고 생각하자.

왜냐면 리턴 타입이 단일 객체라면 패치 조인을 써봤자 겨우 2→1로 1회 줄어들 뿐이다. 반면 리턴 타입이 리스트라면, 리턴된 리스트의 개수가 적으면 어쩔 수 없지만 얼마나 많을지도 모르는 것이기 때문에, 아까 1+5000 처럼 성능 저하의 위험성을 방지하기 위해 패치 조인을 걸어주는 것이 맞다.

물론 리턴 타입이 단일 객체라고 굳이 패치 조인을 안 쓸 이유는 없는 것 같다.

더 바깥 비즈니스 로직에서, 반복문을 돌면서 member1 부터 member5000 을 차례로 가져온다면,

(1+1)*5000 회의 쿼리를 1*5000 회로 줄일수는 있는거니까.

2. JPQL) OneToMany 패치 조인 에서 distinct를 걸지 않으면, 값이 중복되어 가져와진다.

믿고 싶지도 않고 믿기지도 않지만 사실이다. 이 사실을 믿는데 어느정도의 시간이 걸린 이유는,

우리가 JPQL이 당연히 해줄것이라고 생각했던 것, 다시 말하면 JPQL이 생각처럼 좋진 않고 원시적이라는 것이다.

(현재 논점과 다른 이야기긴 하지만, 사실 JPQL이 SQL을 만들때 연관 관계를 고려하지 않고 막 만든다는 사실도, 우리의 JPQL에 대한 환상?을 깨뜨리기도 했다)

이 중복 문제의 근본적인 원인을 먼저 말하면, SQL과 JPQL이라는 근본적 차이 때문이기도 하다.

이슈를 먼저 이야기 해보자.

member1 은 order1 과 order2 를 가진 객체이다.

이때 member1을 조회하는 JPQL 쿼리에서 패치 조인으로 member.orders 까지 같이 가져온다고 상황을 가정해보자.

그저 member.orders를 패치조인으로 함께 가져왔을 뿐인데, 놀랍게도 결과는 똑같은! member1 이 2개 들어있다. 믿기지 않다면 직접 테스트 해보자.

이유는 JPQL이 그리 똑똑하진 않아서, 자동으로 중복 제거를 해주지 않기 때문이다.

사실 SQL이라면 위의 결과는 당연한거다 !

SQL 에선 SELECT 절에 단일 객체, 즉 엔티티를 넣을 수 없다. select m.id, m.name ... from Member m where ~ 와 같이 써야한다.

member1.id - member1.name - order1.id - order1.name
member1.id - member1.name - order2.id - order2.name

와 같은 테이블을 결과로 가져오는 것이 당연한거다. (마크다운 테이블 만들기 귀찮음)

JPQL은 위 테이블에서 좌측 멤버 부분을 객체로 SELECT 하기 때문에,

JPQL이 내부적으로 중복 제거를 하는게 아니라면(그렇다), 첫번째 row의 member1 인스턴스와 두번째 row의 member1 인스턴스가 (똑같은 놈임에도 불구하고) 중복되어 반환된다.

어찌보면 중복되는게 당연한거다.

무튼, 따라서 애플리케이션 레이어의 우리 개발자 입장에선 distinct를 매번 걸어줘야 하는 수 밖에 없다. 인정하자

다행히도 JPQL의 distinct는 (저 테이블, 즉 DB단의 distinct로 해결되지 않는) 애플리케이션단의 distinct 효과를 내준다고 한다.

[ 결론 ] 이 부분도 평소에 개발할 땐, 어떤 기준을 가지고 있으면 될까 ?

JPQL을 쓰면서 패치 조인을 하는데, (일대일도 다대일도 아닌) 일대다를 패치 조인한다면,

꼭 distinct 를 써야 한다 !

(어짜피 안쓰면 비즈니스 로직상 에러날 것.)

[ 오해 주의 ]

distinct 는 SELECT 대상(Member)에 대해서 중복제거를 하는 것이다.

패치 조인하는 대상(Order)에 대해 하는 게 아니다.

-> member1 한개지만, size 2로 나온다. distinct 붙이면 해결.

3. JPQL) OneToMany 패치 조인을 한번에 2개이상 할 수 없다

아까 2번에서 꼭 distinct를 써줘야 했다던, JPQL에서 일대다 패치 조인 - 한번에 2개 걸어서 가져올 수 없다.

(책에선 JPQ 구현체에 따라 되는 놈도 있다는데, Hibernate는 안되는 걸로.)

이유는

컬렉션 * 컬렉션이라는 Cartesian 곱이 만들어지기 때문.

org.hibernate.loader.MultipleBagFetchException을 만나게 될 것이다.

인수테스트 디렉토리 분리 (with gradle)

os94 — Sun, 12 Jan 2020 17:55:34 +0900

우테코 레벨4 프로젝트 과정에서 정리한 Wiki 문서

배경

Pobi 강의 - 개발 방법 중에 단위 테스트는 기존의 main/test 구조로 test 디렉토리에서 돌리고, 오래 걸리는 인수테스트는 별도의 디렉토리로 분리해 CI 환경에서만 돌리는 방법도 존재한다.

참고자료

과정

기존의 src - main/test 구조에서 src - main/test/acceptanceTest 구조로 바꿔본다. (acceptanceTest는 우리가 임의로 지정한 디렉토리 이름)
build.gradle 설정 추가

build.gradle의 task 설정하는 부분 코드 수정

생성한 디렉토리에 필요한 의존성이 있으면 다음과 같이 의존성을 추가한다
- testImplementation의 test가 test directory를 가리킨다는 것은 개인적으로 컬쳐쇼크였다. 우리의 경우, acceptanceTest라는 디렉토리를 만들었으므로 configurations { .. } 에 선언하고 acceptanceTestImplementation을 이용해 의존성 추가

이슈

인텔리제이 문제인지 생성한 acceptanceTest 디렉토리가 테스트 디렉토리로 인식되지 않았다.
- 해당 폴더 우클릭후 mark as - test로 명시적 변경
프로젝트 진행과정에서 본 '테스트 디렉토리 생성 및 분리' 작업과 'Spring Rest Docs' 작업을 동시에 진행해서, 각 필요한 의존성을 추가하는데 헷깔렸다..
main에 추가된 의존성들을 자동으로 분리한 디렉토리에도 추가하는 방법이 있을 것 같은데 아직은 모르겠다..!
이젠 gradle 문법도 알아야하는구나 =.=

Spring Rest Docs로 API 문서화하기

os94 — Sun, 12 Jan 2020 17:41:59 +0900

우테코 레벨4 프로젝트 과정에서 정리한 Wiki 문서

본 문서는 Spring Rest Docs + @SpringBootTest + WebTestClient 버전의 예제로 설명

참고자료

Rest Docs 도입 배경

https://boorownie.github.io/2019-11-27/atdd_spring_boot
https://boorownie.github.io/2019-11-27/agail_and_atdd
세부 기능 구현에 앞서, Rest Docs를 이용해 전체적인 API를 먼저 만듬으로써 큰 흐름을 이해하고, 프론트와 병행 개발도 가능하게 해보자.

과정

`build.gradle`에 Configuration 추가

Spring Boot라면 버전 생략 가능
testCompile 'org.springframework.restdocs:spring-restdocs-mockmvc:{project-version}' 부분 사용하는 테스트 객체에 맞게 변경 (MockMvc, WebTestClient, REST Assured)
아래는 필요한 의존성. (test 디렉토리가 아닌, 별도로 생성한 acceptanceTest라는 디렉토리에서 구현중이라서 acceptanceTestImplementation으로 되어있음)

`build.gradle`에 bootJar 추가

JUnit 5 기준

API에 맞게 테스트 작성 (ArticeController 예제)

docs처럼 bindToApplicationContext()가 아닌 bindToServer()를 이용해 webtestclient를 초기화해야 spring mvc의 bean 인식 가능
responseFields안에 필드 명시하는 방법들
- fieldWithPath : 기본적으로 필드 명시
- subsectionWithPath : 깊이 들어가지않고 high-level로 표현가능. 보통 dto같은 직접만든 객체 표현할때 유용
- fieldWithPath("exampleField").description("Text").optional() : 값이 null이거나 없을수도있으면 optional() 등..
- 다양한 방법이 있다. docs 해당 부분 참고

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ExtendWith({RestDocumentationExtension.class, SpringExtension.class})
@AutoConfigureRestDocs(uriScheme = "https", uriHost = "docs.api.com")
public class ArticleControllerTest {

    private WebTestClient webTestClient;

//    @BeforeEach
//    public void setUp(ApplicationContext applicationContext, RestDocumentationContextProvider restDocumentation) {
//        this.webTestClient = WebTestClient.bindToApplicationContext(applicationContext)
//                .configureClient()
//                .filter(documentationConfiguration(restDocumentation))
//                .build();
//    }

    @BeforeEach
    public void setUp(RestDocumentationContextProvider restDocumentation) {
        webTestClient = WebTestClient.bindToServer()
                .baseUrl("http://localhost:8080")
                .filter(documentationConfiguration(restDocumentation))
                .build();
    }

    @Test
    void example() {
        this.webTestClient.get().uri("/").accept(MediaType.APPLICATION_JSON)
                .exchange().expectStatus().isOk().expectBody()
                .consumeWith(document("index",
                        responseFields(
                                fieldWithPath("title").description("this is title."),
                                fieldWithPath("contents").description("this is contents."))));
    }
}

@RestController
public class ArticleController {
    @GetMapping("/")
    public ArticleDto test() {
        ArticleDto articleDto = new ArticleDto("ex-title", "ex-contents");
        return articleDto;
    }
}

public class ArticleDto {
    private String title;
    private String contents;

    public ArticleDto() {
    }

    public ArticleDto(String title, String contents) {
        this.title = title;
        this.contents = contents;
    }

    // 생략
}

`src/docs/asciidoc/api-docs.adoc` 위치로 문서 작성

테스트를 돌리면 `build/generated-snippets`에서 생성된 스니펫 확인 가능

`build.gradle`의 bootJar을 실행시키면 `build/asciidoc/html5` (build.gradle에서 우리가 설정한 경로) 에서 생성된 HTML파일 확인가능

우아한 테크코스) Lv4 [팀 프로젝트] 정리, 후기

os94 — Thu, 9 Jan 2020 21:22:00 +0900

Lv4 : 팀 프로젝트

-> https://github.com/eattogether/hey-together
-> 팀 위키

요구사항

지속적 통합 (모든 테스트 통과할때만 배포, 테스트 커버리지 80%, 품질 기준 통과(정적 분석 도구 이용))을 적용해 일정 기준이 넘는 환경으로 배포
Spring Rest Docs를 이용해 API 문서화
프론트는 프레임워크를 사용하기보다 바닐라 JS 기반으로 개발하는게 어떨까?
인증은 OAuth2를 기반으로 하면 어떨까? 단 Spring Security 사용X
인증을 제외하고 최소 하나 이상의 외부 API와 연동
성능을 높이기 위해 자주 사용하지(변하지) 않는 데이터에 대해 (백엔드 부분에) Cache를 적용
REST 원칙을 지키며 개발 (참고링크)
Docker 경험
기능 구현보다 전체적인 프로세스를 경험해보자. 팀끼리 규칙을 정하고. CI 경험 등

팀 문화

이전 레벨2 프로젝트 때와 다른건, 모닝 데일리 미팅 뿐만 아니라 이브닝 데일리도 진행해봤다. 안그래도 기능구현만으로 부족한 시간이라 걱정이 되긴했지만, 지나고보니 꽤 괜찮았다. 모닝 데일리는 가볍게 오늘 뭐할지 계획 정도, 이브닝은 각종 코드와 설계 관련 논의 등 실질적인 기능을 했다.

개발 문화

이슈번호를 커밋 메시지 앞에 작성해, 이슈 추적을 좀더 쉽게 할 수 있었다.
레벨2때 못써봐서 아쉬웠던 ZenHub을 이번엔 써봤고, 이슈들을 에픽 단위로 묶으니 관리하기 더 좋았다 :)
세부 개발 컨벤션 : 다들 레벨2때 나와 비슷한 점을 느꼈는지, 최대한 컨벤션을 세부적으로 정하려 다들 노력했다.

팀 목표

다들 계속 해왔던 스프링 서버 기능 구현 외에, 부가적으로 경험해보고 싶은 목표들로 위와 같이 리스팅했다.
하지만 프로젝트 진척이 더뎌지며 이들 중 실제로 사용해본 것은 절반정도, 그것도 제대로 써봤다고 하려면 목표의 20%도 안되는 것 같아 아쉬움이 있다.

프로젝트에서 개인적인 목표

인프라 기술 경험해보기 (실패)
- 프로젝트를 맨 처음 시작할 때, 내 욕심은 그저 도커와 젠킨스를 경험해보는 것이었다. 코스동안 이제까진 인프라보다 거의 코드쪽을 만져왔기 때문에.
- 결과적으로 이번에도 인프라 기술을 경험해보진 못했다. 표면적인 이유는 당시 개인 역할 분배할 때, 내가 페어와 함께 도메인쪽을 한창 하고있어서 다른 팀원이 인프라 역할을 가져갔다.
- 좀더 원론적으론, 프로젝트 전반적으로 계획 수립과 진행을 제대로 하지 못했고, 때문에 필수 기능을 구현하는 것만으로 시간이 지연되어 인프라 등의 부가 기술을 적용할 시간이 부족했다. 이와 관련해선 뒤에서 다시 기술.
기술 문서 공유 활발히 하기 (성공)
- 이 부분은 레벨2 프로젝트때에 비해 좀더 만족스럽다. 초반부터 적극적으로 기술 문서를 작성하자고 어필했고, 먼저 작성해서 위키에 공유하니 다들 감사하게도 따라주시더라.
- 결국 기술 문서를 공유하는 이유는, 남이 긴 시간을 들여 학습한 내용을 다른 사람은 좀더 빠른 시간에 흡수하기 위함이다. 프로젝트 기간이 좀더 충분했다면, 기술 문서 공유 뿐 아니라 '매일 코드리뷰 or Merge'하며 서로 구두로 이야기하는 시간이 더 많았으면 하는 아쉬움이 있긴하다.

그래서 경험한건?

구현하며 인상깊었던 부분들 + 삽질

인수테스트 디렉토리 분리 위키

foo (커스텀 테스트 디렉토리)를 생성했다면 gradle.build에서 fooImplementation으로 dependency 추가 가능하다. <- 처음알았을때 컬쳐쇼크였다, testImplementation의 test가 그 test였다니..
의존성 주입을 깔끔하게 못했다. gradle 문법도 알아야하는듯..

Spring Rest Docs 위키 블로그

인수테스트 디렉토리 분리와 함께, 첫 주차에 다른 조들 사이에서 가장 먼저 적용하고 이를 기술문서로 공유해, 다른 팀들에게 도움을 줄 수 있어 좋았다.
Spring MVC + WebTestClient 조합에서 bindToApplicationContext() or bindToServer()의 이슈가 발생했다.
- 여전히 의문. bindToApplicationContext()가 안되야하는데 왜 됬던 걸까 ?_?

ATDD와 섣부른 관계 매핑 & 복잡한 도메인 블로그

문제점 1. 가장 크고 복잡한 도메인 Article을 가장 먼저 구현하려 했던 점
문제점 2. Article과 관련한 엔티티들을 너무 빨리 관계매핑하려했던 점

@OneToMany List<?> 상황에서 LazyInitializationException 예외와 해결방안 블로그

OSIV 설정을 꺼놔서 터진것이었다. 다시 스프링부트 기본값인 true로 바꿔 해결할수있었고, 추가로 OSIV를 꺼도 문제가 발생하지않도록 DTO를 사용해 노출하기로 결정했다.

JPA 양방향 순환참조 문제 블로그

당시엔 Json관련 어노테이션을 붙여 순환참조를 끊어 문제를 해결했다가, 이후 DTO를 사용하는 방식으로 변경해 애초의 원인 해결.

OneToMany와 양방향 남용 블로그

도메인 관계매핑의 복잡성과 함께 프로젝트를 지연시켰던 주된 이슈들 중 다수는 일대다 관계와 양방향에서 비롯된 경우가 많았다. 프로젝트 중반을 넘긴 시점에 이들을 모두 해제하고 구조를 변경했더니, 이후로 이슈가 줄어들었고 코드도 깔끔해질 수 있었다.
쓰지말라는건 왜 쓰지말아야하는지, best practice가 왜 존재하는지 몸으로 느낄 수 있었다.;;

정리 : 그래서 우리는 왜 실패했는가?

팀원들의 개인사정으로 인한 초반 부재
- 초반에 각자 개인사로 너무 많이 (돌아가며) 빠졌다. (사실상 5주중에서 2주가 날아가버렸다) 아쉽지만 어쩔수없었던 것 같다.
특정 기능에 대해 한 사람이 담당했던 것
- 프론트를 한사람에게 맡겼더니, 그 사람에게 일이 생겨 작업이 지연될 때 다른사람이 대체하기 어려웠다.
- 다음엔 한 부분에 최소한 2명이상 분배해, 백업 멤버를 두자.
핵심 도메인 모델 구축의 지연
- ATDD와 익숙하지 않은 점 + JPA 관계매핑의 복잡도로, 가장 핵심이 되는 도메인 모델들이 삽질과 변경을 계속하다 뒤늦게 정착됬다.
- 핵심이 되는 부분인 만큼, 다들 각자 역할이 있어도 이를 우선순위로 올리고 초반에 다함께 해결했어야 했다.
불분명한 요구사항 확립 + 마일스톤을 적절히 세우지 못했다
- 처음에 개발주제와 세부 요구사항에 대한 이야기를 충분히 하지 못했다. 이를 문서화하지도 못했다. -> 레벨2 프로젝트때와 비교해, 애초에 주제가 불분명해 충분한 이야기를 나눠야 했었음
- 초반에 팀원들이 모이지 못한것과 관련
- 그리고 애초에 짧은 기간에 과한 목표를 잡았다. 기본 서비스 기능 구현 외에, 팀원들의 목표였던 비기능 기술들까지 다루려면, 처음써보는 뷰는 포기해야했음. 차라리 슬랙봇 프로젝트처럼.
의욕 불충분
- 취업과 프로젝트 지속성X으로 팀원들의 사기 저하
- 개인에게 있어서 프로젝트의 우선순위가 밀렸다 -> 규율 위의 자율이 필요했음, 리더의 부재로 각자의 책임이 불분명

기타 : 사소한 것들

인텔리제이 문제로 커스텀 테스트 디렉토리를 인식하지못해, mark as로 명시적으로 테스트 폴더로 바꿔줘야 했다.
공식 Docs가 시키는대로 하자. 다른 경로가 아닌 src/docs/asciidoc/example.adoc의 경로에 adoc 파일을 생성해야한다.
블로그 : TIL - JPA 'GenerationType.AUTO'와 Mockito 등
회고의 중요성 : 프로젝트가 끝날 즈음, 최종 회고를 했다. 서로 마음을 털어놓고 감정을 공유하며, 서로를 좀더 이해할 수 있었다. 속도 시원했다.

팀 차원에서 새롭게 도입해본 기술들

인수테스트 디렉토리 분리
Spring Rest Docs
JWT 인증
Vue.js

우리도 도입해볼만했던 다른 팀의 기술 및 정책

AOP 로깅
프로젝트 모듈화
SonarQube
로젠트리, https://docs.sentry.io/
DbUnit

2020) 2019년 회고 + 2020년 계획

os94 — Wed, 8 Jan 2020 22:49:09 +0900

2019년 회고

~3월
학교 막학기를 앞두고 방향을 무척 고민했던 시기. 방학이라 시간은 많고 "무엇을 어떻게 공부해야할지"는 몰라서, 무식한 방법으로 책이나 인강을 들어대며 시간을 보냈다. (물론 나중에보니 다 도움됬지만) 원인은 개발로 전향한지 얼마 안된 시기였고, 제대로 경험해본건 그나마 안드로이드, 프론트는 취향아닌것같고, 백엔드는 경험해보지못한 분야에 대한 막연한 두려움. 어느길로 나아가야할지 방향을 못 잡고 있었다.
개발 프로그램/동아리나 인턴도 몇군데 넣었다. 모두 면접에서 탈락. 최탈의 아픔에 대해 알게됬다. 쉽게보고 경험삼아 지원했던 회사들에 광탈하니 자존감이 무척 하락했다.
4~11월
지원한 몇군데에 탈락하고 조용히 막학기 수업이나 들으며 공부를 병행하기로 했다. 그러던중 우테코 공고가 떴고 열심히 선발과정에 임했다. 더이상 갈곳이 없어서였던지, 그렇게 절박한 마음과 노력은 편입때이후 오랜만이었다.
감격스럽게도 선발되어서 8개월간 과정을 진행했다. 삶의 전환점인 우테코를 기점으로 180도 달라졌다. 객관적으로 얻은 개발관련 지식과 정보들 외에도, 이상적인 개발자의 자세나 가치관, 또 "무엇을 어떻게 학습해야할지"에 대한 시야를 얻어, 우테코에 대한 큰 감사와 만족을 했다.
8개월간 빡센 일정에 쉽지 않았지만, 주변의 모두가 열심히 해서 함께 동반 성장할 수 있었다. 중간에 지칠즈음, 학교에서 운좋게 미국 컨퍼런스에 보내줘서 refresh할 수 있었다. 그렇게 좋은 흐름을 타서 지금까지 이르렀다.
11~12월
레벨3와 회사 선발일정이 겹쳤다. 육체적으론 괜찮았는데 정신적으로 가장 지쳤던 시기이고, 어찌저찌 잘 통과해서 다행히 첫 회사를 들어가게 되었다.
회고
개인적으로 내 인생에 있어서 그냥 '2019년=우테코'였다. 그만큼 이부분을 삶의 메인 중심으로 가져가며 생활했다. 이 과정에서 주변을 잘 돌아보지 못했는데, 정신없는 나를 잘 챙겨준 주변사람들에게 감사하다.
20년엔 주구장창 개발만 하고 싶진 않다. 물론 첫 회사 생활과 새로운 환경, 적응에 바쁘고 정신없을 것이다. 하지만 무조건 시간을 투자하고 달려든다고 일의 능률이 오르진 않음을 작년에 경험했고, 이에 따라 올해엔 회사와 내 개인적인 삶의 균형을 맞춰서 나만의 라이프사이클을 만들어 지켜가고 싶다. 레벨3 글쓰기했던 것처럼, 무엇보다 내가 즐겼으면 좋겠다.

2020년 계획

예전에 CU코치와 면담했던 기억을 떠올려, 만다라트를 처음으로 만들어봤다.

Hobby
- 서울살이 처음으로 학교근처를 벗어나 잠실로 이사한다. 석촌호수와 올림픽공원, 한강공원의 세 입지를 가진 최고의 조건이다. 20년엔 자연과 함께 운동도 많이 하기로..!
- 18년에 비해 19년은 사진을 너무 못찍었다. 20년엔 가끔 기분전환이 필요할때 카메라 챙겨서 출사나갈것이다.
Backend
- 세부 기술이나 학습 목표를 나열하긴 애매해서, 학습할때 중점으로 둘 큼지막한 주제들을 적어봤다.
- 작년에 비해 새로운건, (잠깐이지만 회사 1주일 다녀보니) "성능"에 대한 고민이 많은 것 같아 중점적으로 가져가야 할 것 같았다. 클린 아키텍쳐도 이젠 슬슬 뭔지 고민해보고 싶다.
Category
- 학습 주제들.
- 우리 부서에선 작년에 공부한 기술들과 비슷한 기술셋을 사용해서 좋았다. 다만 이런 메인이 되는 부분들외에 연한색인 리눅스나 CS에 대한 공부도 소홀히 하지 않았으면 좋겠다. 무엇보다 테스트에 대한 고민은 꼭 진지하게 해볼거다.
Study
- 내가 지식을 얻는 채널들
Activity
- 여러가지 활동을 하고싶지만, 올해는 첫 1년인만큼 공부하고싶은게 많아서 그 부분들에 먼저 집중해야겠다. (1년뒤에 나도 지금의 내 사수들처럼 될수있을까?! 이렇게 보니 코치들과 리뷰어분들과의 거리는 참 멀게 느껴진다)
Business
- 첫 회사생활이라 얼떨떨하다. 빠르게 적응해서 퍼포먼스를 내야겠다.
- 다만 회사일에 끌려다니진 않고, Backend에서 언급한 주제들에 대해 고민할수있는 일년에 되었으면 하는 바람.
Health
- 공부는 더 하고싶은데 체력의 한계를 느낀적이 많았다. 이제 운동은 선택이 아닌 필수인듯하다. 규칙적인 수면과 스트레스 관리도 삶의 질에 큰 영향을 미치는 것 같다.

2019년(우테코) 학습 부채

레벨2

~~JPA 관련~~
- ~~cascade, orphanRemoval, onDeleteCascade~~
- ~~paging, sorting~~
- ~~JPQL~~
~~Spring Rest Docs vs Swagger~~
~~다양한 테스트 방식들 : notion/개념정리 참고~~
~~Jenkins, Docker~~

레벨3

링크 참고

레벨4

~~sonarqube~~
~~OAuth2, JWT~~
~~Caching~~

2020년 공부 계획

세부 학습 계획은 notion에 작성.

1순위
- 회사 업무 관련
- Spring, Spring Boot
- JPA
- 개발서적s
- 작년에 남긴 학습거리와 아카이빙한 북마크 자료들
2순위
- CS : DB / Network / OS
- Jenkins, Docker
- Etc
  - Test 관련
  - Nginx
  - Redis
  - sonarqube + logging관련 툴들
  - OAuth2 + JWT
3순위
- Algorithm

분기별 목표

1년만에 될진 모르겠지만, 전체적인 학습 방향을 다음과 같은 크게 3단계로 계획해봤다.

Spring, JPA
입사 초반 기간에 최대한 빠르게 끝낸다.
업무 관련 세부 기술 및 DB
업무에서 사용하는, 보다 세부적이고 깊이있는 기술들에 집중.
아키텍쳐, 설계
입사 1년째 정도의 시기를 목표로, 아키텍쳐 관련 학습을 시작할 수 있었으면 좋겠다. (아키텍쳐, 클린코드, ddd 등 ~..)

보안을 보내며

정신없는 2019년이 지나갔다. 인생의 큰 변화가 있었다.
이젠 오히려 어색한 보안/해킹쪽은 뒤로 하고, 익숙한 개발의 삶을 신입 개발자로서 시작한다.
노트북도 드뎌 그램에서 맥북으로 바꾼다. ㅎㅎ
설치되있던 많은 툴들아 안녕

JPA 양방향 연관관계 Entity 값 저장

os94 — Thu, 19 Dec 2019 00:46:42 +0900

오늘 프로젝트에서 주요 도메인 모델들의 구조를 잡고 연관관계를 매핑하는 과정에서 삽질로 많은 시간을 소모해,
"당연하지만" 다시한번 깨달은 사실을 정리하고 기록해보기로 했다.

배경

상황은 비슷한 예시로 들어보면, 가장 이해하기 쉬운 게시글(Article) - 댓글(Comment)의 관계를 설정해보자.
Article(일) - Comment(다)의 일대다/다대일 양방향 연관관계 상태이다.
(물론 일대다는 가급적 자제하고 다대일만 매핑하는게 best practice이지만, 양방향이 꼭 필요한 상황이라고 가정해보자)

상황에 따른, 양방향 연관관계 Entity 값 저장 방식

양방향 연관관계 Entity를 save하면서, 당연한건데 큰 그림와 방향을 놓치고 있었다.
정리해보면 다음과 같다.
Article은 둘째치고, Comment의 저장에 초점을 맞춰보자.
이때, 물론 구현방법은 다양하지만, 가장 기본적이고 심플해보이는 방법으로 작성해봤다.

코드 : Github

1. Article과 Comment를 한번에(동시에) 생성하고 저장하는 경우

(CommentService가 아닌) ArticleService를 통해 Comment를 저장한다.
주의사항
- (당연한것들인데, JPA가 처음이라면 삽질을 유발할 수 있다)
- Article 생성자에 List 필드에 대한건 제외해야한다.
  - 평소처럼 인텔리제이 단축키를 이용해 constructor를 생성하면 모든 필드에 대해 생성되니 주의.
  - 따라서 필드에선 바로 List comments = new ArrayList<>(); 처럼 초기화해줘 버리자.
- @OneToMany List에 CascadeType.ALL이 필요하다.
  - cascade 타입을 지정하지않으면 Article만 저장되고 Comment는 저장되지 않는것을 확인할 수 있을 것이다.
- 당연히 Article.addComment(#) 메소드가 필요하다.
  - 우리의 목적은 Comment를 저장하는거였는데, 이런 add 메서드를 이용해 Article을 통해서 Comment를 저장한다.
  - 이때 추가할 comment의 Article필드가 채워져있어야한다.
  - 좀 못생겨도 article.addComment(new Comment(arg1, article)); 처럼 채우거나, add 메서드엔 인자만 넘기고 안에서 this.comment = new Comment(arg1, this); 처럼 정리할 수 도 있다.

// github 첫번째 커밋 참고

2. (Article은 이미 만들어져있고) Comment만 따로 저장하는 경우

CommentService를 통해 바로 저장한다.
(예전 jwp-blog 미션에서 우리가 Comment 저장하던 일반적인 방식. 보통 @OneToMany를 통한 리스트를 들고있는건 자제하므로 보통 이렇게 많이 저장. RESTful하기도하고)
주의사항
- new Comment()로 새로 만들어 save할건데, 이때 생성자 인자로 Article을 채워야한다. Article은 이미 만들어진 상황이므로 보통 articleId로 DB에서 Article을 꺼내 넣어준다.
- 즉 CommentService에는 ArticleService가 필요해짐. 동시에 순환참조를 막기위해 ArticleService는 CommentService를 몰라야한다.

// github 두번째 커밋 참고

결론

결론은 Comment의 Article 필드가 반드시 채워져있어야한다.
그래야 안빠지고 제대로 들어간다. 왜냐면 Article(일) - Comment(다)의 관계에서 보통 키는 다쪽인 Comment가 가질테고, 당연히 Comment의 Article 필드가 채워져야한다. 그렇지않고 비운채로 Comment를 save하는 경우, article_id 필드가 비어있는것을 확인할 수 있었다.

첨언) 어쩌면 진짜 결론은, 결국 양방향을 쓰지 않는 것이다. 당시엔 프로젝트에서 위의 방식들로 값이 저장되도록 구현했지만, 나중에 결국 악의 근원인 OneToMany를 없애고 양방향을 풀어버렸더니 훨씬 코드로 깔끔해지고 머리도 안아파지더라.

19.12.12) TIL - JPA 'GenerationType.AUTO'와 Mockito 등

os94 — Thu, 12 Dec 2019 18:26:48 +0900

Spring Data JPA에서 Id의 @GeneratedValue 이슈

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

위의 코드로 익숙한 Entity에서 Id 부분, 우리는 GenerationType.AUTO가 DB 벤더에 알맞은 전략을 선택해주기 때문에 DB 종속성이 약해져 GenerationType.Identity(MySQL의 auto increment 역할)보다 적절하다고 알고있었다.
그러다 리팩토링을 진행하며, GenerationType.Identity 일땐 잘 작동하던게 GenerationType.AUTO로 바꾸니 에러가 나기 시작했다.
검색해보니 오늘도 jojoldu님에게 도움을 받을수있었다. https://jojoldu.tistory.com/295
링크에 정리 잘 되어있어 읽으면 되지만, 간략히 요약해보면 다음과 같다.
(rough한 요약) Hibernate 예전 버전은 알던대로 AUTO가 Identity였다. 하지만 Hibernate 버전이 올라가며 특정 버전부터 AUTO가 Table로 바뀌었다. (MySQL의 경우)
이에 대한 해결책은 2가지를 제시해주셨다. 단순히 Identity로 바꾸거나, application.properties 또는 yml 파일에 해당 Hibernate 옵션 설정을 끄는 방법.
우린 첫 문단에 언급한대로 Identity는 피하고싶어서 후자의 방법을 택해, 설정파일을 수정해 해당 이슈를 해결했다.
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.4-Release-Notes#generator-mappings

Mockito를 사용하기 위한 @ExtendWith 추가

서비스 테스트에 Mockito를 사용하는 과정에서, Mockito는 기본 스프링 부트 test 의존성에 들어있어서 바로 사용할 수 있었다.
testImplementation 'org.springframework.boot:spring-boot-starter-test'
테스트를 짜고 돌리니 이번에도 터지기 시작했다. 찾아보니 Spring의 빈들과 Mockito는 서로 모른다, 이들을 통합시켜주기위해 @ExtendWith(SpringExtension.class) 를 테스트 클래스에 추가해줘야했다.
@ExtendWith(SpringExtension.class) 도 되고, @ExtendWith(MockitoExtension.class) 도 된다.
이 과정에서 추가로 @RunWith 와 @ExtendWith 의 차이도 덤으로 알게되었다. JUnit 버전 차이였다.
https://stackoverflow.com/questions/55276555/when-to-use-runwith-and-when-extendwith

Mockito를 활용한 서비스 레이어 테스트

오랜만에 서비스 테스트를 짜며 Mockito를 활용했다. 기억이 하나씩 되살아났다.
우리 프로젝트에선 서비스 메소드의 로직이 여전히 너무나 간단해서, 서비스 테스트의 의미가 크진 않은것 같다. 동시에 모킹하며 테스트하는게 '짜고치는 고스톱'이라는 느낌을 여전히 벗을수없었다.
하지만 나중에 서비스 로직이 복잡해지면 이는 해결될거라 생각.
이 과정에서 하나 오해했던걸 풀수있었다. given은 BDDMockito꺼, when은 Mockito꺼다. 별개다. given-when-then이 given()-when()-verify()로 매칭되는거란건 착각이엇다. 각각 상황에 맞게 사용하자. 재밌는 메소드들도 많이 발견했다.

JPA) LazyInitializationException 이슈

os94 — Tue, 10 Dec 2019 22:09:31 +0900

상황

19.12.10 우테코 레벨4 eat-together 프로젝트의 Article/Shop/Menu 관련 구현 중 발생한 이슈

Shop은 @OneToMany로 List를 갖고있다.
Menu도 양방향으로 @ManyToOne Shop을 갖고있다.

가게 조회 기능을 구현하는 과정에서, 테스트에서 Shop을 리턴하니 List때문에 터졌다.

발생한 LazyInitializationException 예외를 검색해보니 관련 논의가 많았다.

참고자료

킹뽀대님 글 , 나중에 정독해보고 OSIV에 대해 고민해보자
feco.tistory.com - 3가지 해결방안 제시
bebong.tistory.com

문제 해결

application.properties에 #spring.jpa.open-in-view=false로 설정되있었다.
해당 설정을 지우고 true로 켜니 해결. (fetchType은 Lazy인 상태)

+ Nick's Help

이 부분을 한창 고민하던 와중에, 지나가던 Nick선생님께서 첨언해주셨다.

OSIV는 스프링부트에서 기본적으로 true로 설정되어있음.
OSIV를 켜면, Lazy가 서비스에서 나갈때 Proxy로 나가는데 컨트롤러에서도 조회가능해진다(조회만). 값에 접근할때 select문 날려 db에서 데이터 가져오고.
우리는 OSIV 설정이 꺼져있어 터졌던 것. 반대로 말하면 이제까지 우린 대부분 이 설정을 기본값으로 켜놔서, 이 예외를 만날기회가 적었던 것
원래 트랜잭션과 세션의 주기가 함께 가야 좋은데, OSIV를 켜면 (서비스를 나가며 트랜잭션이 끝나도 컨트롤러에서 접근가능하게) 세션 주기를 늘리는 역할
그래서 현업에선 OSIV를 끄고 개발시작하기도 한다고한다. 켜면 select문 나가며 예상치못한 성능저하 발생할 수 있으니. OSIV에 관해선 말이 많다고 함.

-> LazyInitializationException을 검색하니 관련한 이슈와 논의가 활발했다. 오늘은 이정도로 문제해결하고 나중에 제대로 이부분을 파보자.

12.12 추가

Controller와 Service 사이엔 Dto를 활용해서 주고받기로 팀내 컨벤션을 정했다. 이를 통해, 더이상 엔티티가 서비스밖으로 노출되지않아 OSIV 문제가 더이상 발생하지않았고 도메인 모델을 더욱 보호할수있을것으로 기대할수있었다.

Sean :: Dev

21.04.15) 오늘의 기록 - 날뛰는 팬소음과 Google Chrome Helper

비전공자를 위한 개발 입문 정보

배경

왕초보 :: 가장 먼저 해야할 것

TIP

교육과정/부트캠프

인터넷 강의

추천 자료 & 읽을거리

학부때 듣고 졸업하길 추천하는 CS 과목

개발 동아리

JPA의 사실과 오해 (사실은 JPQL과 Fetch Join의 오해)

JPA의 사실과 오해 (사실은 JPQL과 Fetch Join의 오해)

1. N+1은 연관 엔티티가 Collection인지가 중요한게 아니다.

2. JPQL) OneToMany 패치 조인 에서 distinct를 걸지 않으면, 값이 중복되어 가져와진다.

3. JPQL) OneToMany 패치 조인을 한번에 2개이상 할 수 없다

인수테스트 디렉토리 분리 (with gradle)

배경

참고자료

과정

이슈

Spring Rest Docs로 API 문서화하기

본 문서는 Spring Rest Docs + @SpringBootTest + WebTestClient 버전의 예제로 설명

참고자료

Rest Docs 도입 배경

과정

build.gradle에 Configuration 추가

build.gradle에 bootJar 추가

JUnit 5 기준

API에 맞게 테스트 작성 (ArticeController 예제)

src/docs/asciidoc/api-docs.adoc 위치로 문서 작성

테스트를 돌리면 build/generated-snippets에서 생성된 스니펫 확인 가능

build.gradle의 bootJar을 실행시키면 build/asciidoc/html5 (build.gradle에서 우리가 설정한 경로) 에서 생성된 HTML파일 확인가능

우아한 테크코스) Lv4 [팀 프로젝트] 정리, 후기

Lv4 : 팀 프로젝트

요구사항

팀 문화

개발 문화

팀 목표

프로젝트에서 개인적인 목표

구현하며 인상깊었던 부분들 + 삽질

인수테스트 디렉토리 분리 위키

Spring Rest Docs 위키 블로그

ATDD와 섣부른 관계 매핑 & 복잡한 도메인 블로그

@OneToMany List<?> 상황에서 LazyInitializationException 예외와 해결방안 블로그

JPA 양방향 순환참조 문제 블로그

OneToMany와 양방향 남용 블로그

정리 : 그래서 우리는 왜 실패했는가?

기타 : 사소한 것들

팀 차원에서 새롭게 도입해본 기술들

우리도 도입해볼만했던 다른 팀의 기술 및 정책

2020) 2019년 회고 + 2020년 계획

2019년 회고

2020년 계획

2019년(우테코) 학습 부채

레벨2

레벨3

레벨4

2020년 공부 계획

분기별 목표

보안을 보내며

JPA 양방향 연관관계 Entity 값 저장

배경

상황에 따른, 양방향 연관관계 Entity 값 저장 방식

1. Article과 Comment를 한번에(동시에) 생성하고 저장하는 경우

2. (Article은 이미 만들어져있고) Comment만 따로 저장하는 경우

결론

19.12.12) TIL - JPA 'GenerationType.AUTO'와 Mockito 등

Spring Data JPA에서 Id의 @GeneratedValue 이슈

Mockito를 사용하기 위한 @ExtendWith 추가

Mockito를 활용한 서비스 레이어 테스트

JPA) LazyInitializationException 이슈

상황

참고자료

문제 해결

+ Nick's Help

12.12 추가

`build.gradle`에 Configuration 추가

`build.gradle`에 bootJar 추가

`src/docs/asciidoc/api-docs.adoc` 위치로 문서 작성

테스트를 돌리면 `build/generated-snippets`에서 생성된 스니펫 확인 가능

`build.gradle`의 bootJar을 실행시키면 `build/asciidoc/html5` (build.gradle에서 우리가 설정한 경로) 에서 생성된 HTML파일 확인가능