YOUTHCON'21 요약

들으면서 바로바로 작성하느라 오타 및 잘못 정리했을 수도 있습니다.

감안하고 봐주시면 감사 하겠습니다. :)

자바와 스프링에서 나의 멘토 찾기, 손현호

자기소개

• 최근 국비교육을 마친 취준생
• 인프런, nextstep등 교육 프로그램은 늘어나고 있다.
• 하지만 완벽한 환경은 존재하지 않는다.
• 열악한 환경(국비) 속에서 성장하기 위한 고민

고민

• 현장 경험도 없는 내가 다양한 요구사항을 받게 된다면, 내가 확실히 대처할 수 있을까?
• => NO

WHY?

• 왜 Scanner는 생성자에 System.in을 주입해줘야 하는 걸까?
• JDK 1.5에서는 inputStream을 생성 및 char배열을 생성해야 했었다.

문제점

• 1. 불편한 입력 방식
• 2. 통합되지 않는 입력 방법
• console입력/FILE 읽기에는 inputstream을 주입받고 Readable이라는 형태로 통합하여 제공

맥락

• 다양한 형태로 제공되는 파일, 입력 등을 하나의 통합적인 접근방식으로 접근 가능하게 한다.
• 즉 기능의 요구사항을 추상화
• 위의 예시와 같이 Scanner와 비슷한 맥락을 마주치면, 그것을 구성하는 구조는 비슷하지 않을까?
• => 비슷한 맥락적인 부분 : "스프링에서는 다양한 빈 설정 방식을 통합 제공한다." (xml, annotation)
• 다양한 형태로 제공되는 빈 설정 정보를 하나의 통합적인 접근방식으로 접근 가능하게 한다.
• Scanner = ApplicationContext
• InputStream = BeanDefinitionReader
• Readable = BeanDefinition
• 같은 맥락의 요구사항 <=> 비슷한 구조를 갖는다.
• 신뢰할 수 있는 다양한 프레임워크 & 라이브러리
• 많은 요구사항 -> 요구사항을 해결하는 구조
• 프레임워크나 라이브러리를 공부함으로써 로드 존슨, 유겐 휠러가 나의 멘토가 될 수 있다.

결론

• 모든 프레임워크는 프렉탈 구조로 되어 있다고 생각합니다.
• 그 외에도 DB의 트랜잭션과 자바의 락은 비슷한 맥락
• 스프링 컨테이너와 JPA 영속성 컨텍스트
• 맥락과 구조를 중심으로 학습하자.!

SI에서 왕이었던 나, 알고 보니 초보 개발자, 이석균

• 첫 회사, 임금체불로 인한 퇴사
• 두 번째 회사, 기술지원 업무 c, c++개발
• 세 번째 회사, 웹 에이전시 첫 자바 프로젝트
• 네 번째 회사, 게임 회사 python
• 다섯 번째 회사, 첫 테스트 코드, 코드 리뷰

IT회사들의 차이점

SI회사 

• 유지보수를 고려한 코드를 작성하지 않음
• 테스트 코드 작성하지 않음
• 고객의 수락을 해야 진행
• 고객이 제안을 받지 않으면 해당 사업은 진행하지 않음

게임 회사

• 매달 점검, 이벤트, 매달 바쁨
• 배포일이 매월 말이기 때문에 휴가 불가
• 테스트 코드 잘 되어있음, 코드 리뷰 문화 좋음
• 동기부여 인센티브

이커머스

• 거래가 완료되기까지 복잡한 로직
• 이커머스 경력이 있어야 갈 수 있는 회사가 많은(도메인 지식)
• 워라밸 좋음
• 자체 서비스

코딩 테스트 준비과정

• 동빈나님 유튜브
• 김태원 님의 자바 알고리즘 문제풀이:코딩 테스트(인프런)
• 백기선 님의 더 개발자, 인터뷰 가이드

코딩 테스트 팁

• 매일 알고리즘 2~3 문제 씩 풀기(감 유지)
• 코딩 테스트 보기 전 해당 사이트 연습문제 풀기
• 문제 풀기 전 노트에 손 코딩 진행
• IntelliJ에 미리 문제 수만큼 클래스 준비

코딩 테스트 참고자료

• 릿코드
• 코딜리티
• 백준
• 프로그래머스
• 구름

코딩 테스트 참고자료

• Hello coding 알고리즘
• Algorithms 알고리즘 개정 4판
• 코딩 인터뷰 완전분석
• 이것이 취업을 위한 코딩 테스트다 with 파이썬

공부했던 방법

• 오전 10시 ~ 오후 7시 스터디 카페
• 오후 8시 ~ 오후 11시 코딩 및 인강
• 책 읽기 : 주 2권
• 일주일에 책 한 권 정해서 읽고 책 내용 피드백 (멘토링 받음)

공부 팁

• 인터넷 강의 vs 책 (책이 좀 더 깊이가 있었다.)
• 책 읽고 인터넷 강의를 보면서 정리해도 좋음.
• 페이스 북이나 링크드인에서 좋은 개발자 팔로우
• 토이 프로젝트 : 깃허브에 Real World를 쳐보면 좋다.

추천 도서

• 모던 자바 인 액션, 이펙티브 자바, 자바 성능 튜닝 이야기
• 자바 객체 지향의 원리와 이해
• 토비의 스프링
• 테스트 주도 개발, 단위 테스트
• 클린 코드, 클린 아키텍처

도서 통계

• 100만원 이상 구매

면접 준비 및 후기

• 깃 잔디 채우는 것보다 퀄리티 있는 프로젝트가 중요
• 비슷한 실력끼리 모여서 면접 준비 비추천
• 면접 질문 내용 기록 후 공부
• 면접 보는 회사 공부 필수 (잡플래닛, 회사 블로그 등등)

면접 보면서 느낀 점

• 제일 크게 느낀 점은 난 초보다.
• 초반에 쉬운 주제로 시작하여 점점 깊게 들어 감.
• 좋은 회사는 면접 질문도 좋다.
• 스타트 업은 CTO를 보고 회사 선택
• 면접자의 질문 : 테스트 코드 작성, 코드 리뷰 문화에 대한 질문을 하면 답 나옴.
  • -> 좋은 회사인지 판별

마무리

• 책을 많이 읽었으면 좋겠다.

하고 싶은 말

• 요즘 개발자들 너무 부럽다.
• 여러 가지 얇은 지식보다 깊은 지식이 좋다.
• 책을 많이 읽는 습관을 갖자.
• 회사가 어떤 사람을 뽑는지 공고는 꼭 확인하자.
• 책을 읽거나 토이 프로젝트를 할 때는 기간과 목표를 정하자.
• 회사가 어떤 사람들을 뽑는 채용공고를 꼭 확인하자.

현실 팩트

• 연봉 높은 회사를 가고 싶지만 현실을 파악하자.
• 커리어를 생각하는 것은 생각보다 중요하다.
• 이력서의 정답은 아무도 모른다. 지원부터 해보자.
• 아무리 좋은 회사라도 팀마다 다르고, 본인이 만족할 수 없다.

자존감 주도 성장, 김태욱

1. 발표자 소개

• 회사 : 스테이션 3(다방)

2. 어떻게 개발자가 되었나?

• 대학교 중도 포기 후, 백수 생활
• 가구 디자인 관련 국비지원을 알아보다 정보보안 쪽으로..
• 당시 학습방법 : 메모장에 적혀있는 코드를 그대로 옮겨 적는다. -> 실행한다.
• copy & paste / control + space를 이용하기 시작
• 세미, 파이널 조장으로 나름 성공적으로 프로젝트를 마무리
• 빨리 취업하고 싶은 마음으로, SI 취직

3. 자존심 와장창!!

• 자존감 : 자신이 사랑받을 만한 가치가 있는 소중한 존재....
• 자존심 : 남에게 굽히지 않고 스스로 품위를 지키려는 마음
• 더닝-크루거 효과

1년 차 

• 동작만 하면 되는 거 아니야?

2년 차

• PM님이 좋게 봐주셔서 면접 제의를 받음

3년 차

• 방통대 편입, 정처기 취득, cs기초 공부

4년 차

• 다른 회사 R&D 부서로 이직
• 같이 일하던 개발자가 "웹 개발이라는 것은 뭐에요?"

4,5년 차

• 토비의 스프링(무조건 읽어야 함), 이펙티브 자바, 디자인 패턴, 클린 코드를 공부
• 객체지향적으로 개발하는 것에 관심
• 오길환 님과 같이 스터디

5년 차

• 서비스 회사로 이직 성공, 코딩 컨벤션에 맞춰 개발하고 코드 리뷰를 받는 과정을 반복
• 일관성 있게 코드를 작성하는 것이 쉬운 일이 아님

현재

• 모드는 부분이 생기면 디컴파일을 해서 분석, 레퍼런스를 통해 확인하는 식으로 변화
• 구체적으로 어떻게 사용하면 되는지, 어떻게 만들어졌고 어떤 장점과 단점이 있는지
• 비슷한 것은 어떤 것들이 있는지 조사하고 학습한 다음에 어떻게 활용할 것인지 깊이 고민

4. 자존감 회복 방법

• 열등감 -> 나는 쓰레기 -> 개발 학습 -> 자존감 상승-> 열등감 (사이클)

5. 부록, 보조 면접관

첫 번째 기본 지식인 지식에 대한 질문의 경우

• 달달 외운것을 이야기하는 것은 마이너스, 자기 나름의 생각을 정리해서 이야기를 합시다.

두 번째 이직 이유로 전 직장의 좋지 못한 개발 문화 혹인 환경에 대해서 말하는 경우

• 개선을 위해서 했던 구체적인 사례를 바탕으로 이야기를 하면 good 아니면 not good

세 번째 남들 하니까 따라 하는 블로그, 깃 잔디 심기 그만

• 하다가 말다가 한 블로그나 잔디 심기는 오히려 독이에요

네 번째 대부분의 질문에 대해서

• 답변을 할 때에는 되도록 근거를 기반으로 대답하는 것이 좋다.
• 하고 있다 할 거다 하는 중이다 라는 말은 포장하기 위한 거짓말

다섯째 장황한 자기소개 보고 싶지 않다.

• 근거를 기반으로 3~5줄 남짓의 자기소개가 좋다.
• 하루에 적게는 1명 많게는 4~5명 서류 검토를 해야 하기 때문에 장황한 이야기 지쳐요.

여섯째 자신 있는 쪽으로 질문을 유도하는 것도 좋은 방법

• 질문하고 싶어지게 하는 포인트 들을 많이 만들자.
• 질문을 통제할 수 있으면 계획한 답변대로 어필할 수 있는 기회

마지막, 자존감

• 열심히 학습하고 나름대로 생각을 많이 해본 사람은 답변에 자신감이 넘치는 경우가 많다.

객체지향 설계와 JPA 연관관계 구현, 손민성

1. JPA를 왜 사용할까요

• 패러다임 불일치를 해결
• 우리가 해결해야 하는 패러다임 문제는?
• OOP-RDB 간의 패러다임 불일치 문제를 해결

OOP : 객체지향

• 객체지향은 객체 간의 참조를 이용하여 데이터를 가공하고 가져옴
• 직렬화를 통해 데이터를 저장, 수정할 수 있음
• 직렬화 트랜잭션, 동시성, 대용량 데이터 취급하기에 힘들다.

RDB : 릴레이션의 패러다임

• RDB는 외래 키를 명시하고 DML을 통해 데이터를 가공하고 가져옴
• DML을 통해 데이터를 저장, 수정
• 릴레이션 패러다임에 트랜잭션, 동시성, 대용량 데이터 취급하기 좋다.
• 반대로 다형성은 사용하기 힘들기도 한다.
• 이러한 중간다리가 JPA이다.
• OOP의 장점을 가져오면서, RDB장점을 가져올 수 있다.

2. 객체지향 설계

• 객체지향 설계의 핵심은 "메시지를 보낸다" 이다.
• 메시지를 보낸다.? 객체에서 다른 객체를 호출
• 메세지를 보내기 위해서는? 객체 간의 참조가 필요

3. 우리는 연관관계 매핑을 어떻게 사용하고 있는가?

@ManyToOne 단방향 매핑

• 일반적으로 ManyToOne 단방향 매핑을 사용

ManyToOne의 문제점 

• 비즈니스 로직상 충돌이 생긴다.
• 불변식을 지킬 수 없다.
• 단방향 매핑의 문제점을 해결하기 위해 양방향 매핑을 사용

양방향 매핑의 문제점은??

• 순환 참조 발생
• 하나의 객체가 변경되면, 다른 객체 또한 변경된다.
• 서로 다른 패키지로 존재하면 패키지 참조

연관관계 주인?

• 외래키를 갖는 Entitiy가 연관관계의 주인

@OneToMany 단방향 매핑을 사용하자

• 의존성이 한 방향으로 변경된다.
• @JoinColumn을 통해 Member 쪽에 FK를 만들어 줄 수 있다.

단방향 매핑으로 발생하는 성능 문제는 어떻게 해결할 것인가.?

• 부가 쿼리와 설계의 트레이드 오프는 조율해 나가야 한다.
• 변경에 유연한 설계를 우선시할 것인가, 성능을 더 우선시 할 것인가.

그렇다면 양방향 매핑은 언제나 안 좋은 것인가.?

• 트레이드 오프를 잘 따지자.

OneToMany 단방향 매핑은 사용하지 말라고 하던데요?

• 트레이드오프를 잘 따지자.

결론

• 모든 설계는 트레이드 오프의 산물, 정답은 없다.
• 공부할 때는 공식에 따라 공부하는 것도 좋다.
• 하지만 의미 없이 공식처럼 사용하는 기술의 사용은 기술 부채로 이어진다.
• 작성하는 코드의 의미를 생각하고 어느 것이 적절한지 선택하면서 사용하자.

N+1을 해결하기에 가장 좋은 경우

• 1. fetchJoin
• 2. LazyLoading상태에서 배치 사이즈
• 3. entity그래프