컨퍼런스

2022 유스컨(유쾌한 스프링방 컨퍼런스)

성장에 몰입중인 개발자 2023. 1. 8. 14:59

 

  • Introduce to Clean Architecture
    • 강의 내용
    • 3년차 이상 내용
    • 기술도 중요하지만 가장 중요하지는 않음
    • 가장 중요한 것은 핵심 비즈니스 로직과 유스케이스
      • 1.핵심 비즈니스 로직
        • 시스템이 없어도 고유한 개념
        • 은행 같은 경우에는 기술 이전에도
      • 2.유스케이스
        • 시스템이 있어야 유효한 비즈니스 로직
    • 아키텍처에서 중요한 것
      • 도메인은 세부사항에 의존하면 안 됨
      • 잘못된 아키텍처
        • 데이터 접근 기술을 바꾸다가 서비스 계층의 코드도 변경
      • 계층형 아키텍처의 단점
        • 의존성의 방향은 항상 다음 계층을 향함
        • 가장 중요한 비즈니스 계층은 영속성 계층에 의존하게 됨
        • 현실에서 핵심은 비즈니스
        • 현실 개발은 자연스럽게 데이터베이스 설계를 하게 됨
        • 넓은 서비스로 인해 유스케이스 파악이 어렵다
        • 실제 현업은 유스케이스로 기획자에게 요구사항이 들어옴
        • 테스트 작성 및 관리가 어려워진다
        • 빈약한 엔티티 → 풍부한 엔티티
        • SRP를 위반하기 쉽다
          • 변경의 이유가 하나여야 한다
          • 서로 다른 이유로 다른 사용자가 코드를 고치면 안 된다
        • 서로 다른 수준으로 변경되는 코드들이 결합되기 쉽다
          • 고수준: 입출력과 멀다
          • 저수준: 입출력과 가깝다
          • DIP를 적용해 해결
    • 클린 아키텍처란
      • 테스트하기 쉬운 아키텍처
      • 소리치는 아키텍처
        • 프레임워크, 데이터베이스 등 드러나지 않아도 되는 기술이 아니라 어떤 도메인, 어떤 유스케이스를 손쉽게 파악할 수 있게 구성
      • 플러그인 아키텍처
        • 핵심을 세부사항으로 분리하고 코어 중심으로 플러그인을 붙여나가는 형태
      • 도메인 중심 아키텍처
        • 영속성 엔티티와 도메인 에티티의 분리
        • 비용이 굉장히 커서 필요할 때만 적용. 그러나 영속성 에티티와 도메인 엔티티가 섞여있음을 인지할 것
    • 좋은 아키텍처 만들기
      • 서비스 계층을 유스케이스 단위로 분리
      • 추상화(PSA)되지 않은 세부 사항에 의존한다면 DIP 적용
      • 객체의 데이터만 필요로 하는 로직들은 객체의 내부로 이동
      • pacage-private 가시성을 적극 활용하라
        • 인텔리제이에서 private를 default로하고 필요할때만 public으로 설정
    • 세부 결정 사항들은 결정을 최대한 미루자
      • 테이블 설계 → 확신이 들 때까지 설계를 미룸
      • 추상화 → 비용이 더 저렵해지는 시점까지 미룸
      • 서비스 분리 → 생존을 위해 분리하지 않으면 안되는 시점까지 미룸
        • 서버가 못 버틸때까지
        • MSA를 하는 입장에서 너무 관리 포인트가 많음
      • 캐시 적용 → Slow 요청들에 의해 필요해지는 시점까지 미룸
        • 불필요하게 적용하다가 제대로 적용되지 않아서
    • 마무리
    • 느낀점
    • 기술 같은 경우는 전부를 그 자리에서 다 이해할 수는 없음
    • 키워드 중심으로 정리하고 공부해야할 내용과 방향을 알아가는 것에 의미가 있음
    • 매일 알고리즘 풀기 전에 클린코드 아키텍처 계속 다시 읽으면서 정리하고 포스팅하기
    • 클린코드와 클린 아키텍처는 꾸준히 읽으면서 계속 프로젝트에 적용하려는 연습이 필요한 듯

 

  • Java 17 vs. Kotlin 1.7
    • 강의 내용
    • Spring Boot 3.0의 기본 스페으로 지정된 Java17
    • 코틀린과 비슷한 기능이 많이 반영 됨
    • 자바 record 클래스 vs 코틀린 data class
    • 자바 sealed class vs 코틀린 sealed class
    • 자바 instanceof vs 코틀린 is, !is
      • 자바 패턴 매칭
      • 코틀린 스마트 매칭
    • 자바 switch vs 코틀린 when
    • 자바 Stream.toList vs 코틀린 Sequence
      • 코틀린 Collections, 즉시 연산 수행
    • 자바 text block vs 코틀린 text block
    • 자바 null 처리 vs 코틀린 null 처리
      • 자바 Optional
      • 코틀린 ?: 등
    • 코틀린 확장함수
    • 코틀린 operator overloading
    • 코틀린 coroutione
      • 스레드보다 좋은 비동기 처리
      • 컨텍스트 스위칭이 없는 동시성 프로그래밍 지원
    • 자바 17 이후 주요 업데이트
      • 표준 자바 API에 대한 기본 문자셋이 UTF-8로 설정
      • 지속적인 Pattern matching 업데이트
      • Project Loom
        • 동시성 처리 개선
        • 비용이 많이 드는 커널 스레드 대신 저련함 가성 스레드를 통해 동시성 처리
    • 코틀린은 다양한 기능을 추가하여 코드 안정성, 간결성을 증대한 언어
    • 자바도 꾸준한 업데이트를 통해 생산성을 높이기 위한 방향으로 발전 중
    • 느낀점
    • SSAFY에서 자바 공부할 때 동시성 공부 추가로 해서 포스팅하면 좋을 듯
    • 배민 신입도 비동기를 프로젝트에 제대로 적용해본 경험이 없다 함
    • 프로젝트에서 적용하기보다 내용만이라도 제대로 공부하면 좋을 듯
    • 아니면 포트폴리오로 작은 기능이라도 제대로 한 번 적용해보면 좋을 듯
    • 동시성 보다 먼저 해야할 것도 많으니 우선순위를 미리 정해보자

 

  • Unit Test Puzzler: 퀴즈로 알아보는 단위 테스트
    • 강의 내용
    • 한 함수에서 한 가지 케이스를 검증
    • 테스트 케이스 함수들의 중복 발생
      • /@ParameterizedTest
      • /@CsvSource({””, … , “”})
    • if문 제거. 케이스 분리
    • 단일 작업을 하는데 두 개의 메서드 호출이 필요 → 설계가 잘못된 API
      • ex) 구매시 재고도 감소하는 로직을 캡슐화
    • 테스트에서 리플렉션으로 private에 접근
      • 캡슐화x
      • 오류 잡기 어려움 ex) 메서드 이름 변경 컴파일러가 감지 못함. 런타임에만 잡힘
      • private 말고 입출력에 대한 public 함수를 설계하고 테스트
      • 꼭 private 부분을 테스트해야한다면 새로운 객체로 분리
    • 테스트 함수에서 랜덤 함수 사용 → 성공과 실패 보장x
      • 랜덤을 생성하는 인터페이스 사용
      • 실제 프로덕션 코드에서는 구현체 사용
      • 테스트에서는 람다식으로 데이트 데이터 세팅
      • 추상화로 프로덕션 코드와 테스트 코드 분리
    • /@BeforeEach + void setUp()
      • 테스트 코드간의 케이스 결합 문제
      • 테스트 세팅이 너무 길다면, private 함수 하나 만들어서 한줄화
      • /@BeaforeEach는 개발 데이터 세팅이아니라 개발 환경 세팅에 쓰면 좋음
    • 참고자료
    • 블라디미르 코리코프의 단위 테스트
    • 느낀점
    • 숫자 야구 게임으로 진행하던데, SSAFY에서 배운 자바 내용을 프리코스 그 강의에 적용하면서 포스팅해도 좋을 듯
    • 테스트코드도 우선순위 목록에 추가. 하지만 테스트코드와 비동기보다 설계와 구현만해도 쉽지 않을 듯

 

  • 토비의 스프링 같이 읽기
    • 다 읽지 말기. 가성비 있게 필요한 부분만.
    • 디스코드 채널에서 토비님의 스터디
      • 매주 일요일 저녁 9시
    • 왜 매번 못 읽었을까
      • 어려워서
      • JPA 추상화 부분들이 전부 JDBC로 다 구체화되어있음
      • SpringBoot안 쓰고 직접 라이브러리 세팅
      • XML로 개발 환경 세팅
      • 인텔리제이가 아니라 이클립스
    • 토비의 스프링의 역설
      • 바이블은 맞다
      • 공부하고 이해한 후에 읽어야 끝까지 읽을 수 있다
    • 읽으면 좋은 점
      • 고프의 디자인 패턴 책 보다도 다양한 디자인 패턴들을 코드를 통해 익혔음
    • 다독하면서 요약하려다 포기
      • 1~7장까지는 처음부터 이어지면서 점점 개선
      • 이미 각 장마다 쉽게 요약되어 있음
    • 스터디원들 인터뷰 후 스터디에서 인상 깊었던 핵심 내용
      • DI
        • DI할 객체라면 무조건 인터페이스 쓰기
        • 클래스를 보기 좋게 정리할 때도 좋음
        •  
      • TDD
        • 테스트를 언제 만드는 것이 좋은가
        • TDD는 내 코드에 대한 피드백을 받는 사이클을 컨트롤하는 기법
      • 예외처리
        • 이력서에 적어둔 코드를 볼 때 예외처리를 대충 한 코드가 있으면 점수를 확 깎는다.
        • 인터페이스 함수마다 모두 throw 나열된 코드
      • 코프링으로 넘어가야할까요
        • 30~50%정도 코드량 자체는 절감 됨. 가독성 향상
        • 근데 JPA랑 진자 안 맞는다
        • 자바 자체를 잘 해야한다
        • 자프링은 망하지 않고 계속 이어질 것이다.
    • 내년 1월쯤 토비님의 인프런 강의 나올 예정
    • 느낀점
    • 토비 스프링 책은 목차보고 참고만. 필요하면 찾아보자.
    • SSAFY 사물함 있다면 이팩티브 자바랑 토비, JPA 책 가져다 놓고 찾아보자
    • 토비님, 백기선님 스터디 같은거 찾아보고 참가하면 크게 성장할 수 있을 듯
    • 디스코드에 좋은 스터디나 채널이 많네. 디스코드 가입하자.
    • 예외 처리에 대해서 높은 우선순위를 두고 2023년 공부 계획 짜보자
    • 모든 개발 도서들도 우선순위 목록에 추가하자

 

  • SM 5년차가 IT서비스 회사로 연봉 30% 인상한 이직기
    • 강의 내용
    • 경력
      • 보험회사 IT시스템 유지보수
        • 영업, 회계
      • 금융권에서 오라클, C언어 주로 사용함
      • 주위 서비스 회사 보면서 뒤쳐지는 느낌 받음
      • 스터디, OKKY, 인프런 멘토링 활용
      • 유쾌한 스프링 오픈카톡에서 게더타운 모각코 참여
      • 우아한 유스방 3기
      • NEXTSTEP
    • 이직과정
      • NEXTSTEP
        • Clean Code with Java 14기
        • 적극적인 자세로 물어보고 피드백 받으면서 좋은 코드에 대해 배움
        • Clean Code with Java 15기 리뷰어
        • 쉬울 줄 알았는데 다른 사람
        • Spring 과정도 참여함
    • 이력서
      • 우아한 유스방 3기
      • 1.자기소개서
      • 2.회사 조사하고 우선순위 매기기
        • 저우선순위부터 지원해서 고우선순위 면접 준비
      • 3.페어 프로그래밍
        • Ping-Pong 방식
        • 1.작은 단위에 기능에 대해 테스트 코드 작성
        • 2.테스트 코드가 성공하도록
        • 1&2 리팩토링
      • 4.과제 REST API
        • 모르는건 기술블로그, 테코톡
    • 지원과정
      • 시리즈 B 이상 회사 전부 지원
        • 시리즈 A는 고생한다해서
        • 시리즈 C는 좀 어려워 보였음
      • 원티드, 링크드인
      • 80개 이상 지원함
      • 60 서류 탈락
      • 10 코테 탈락
      • 1+2차 20번 면접
      • 3개 합격
    • 면접준비
      • 질문
        • 자바, 객체지향, 자료구조, JPA, Spring, CI/CD
        • 데이터베이스
        • 개선 내용 기술 질문
        • 경험하지 않은 도메인과 언어
        • 기입한 Github Repository
      • 바로 바로 노션에 복기하면서 모르는거 공부하면서 높은 우선순위 회사 지원
      • 번아웃
        • 눈에 보이는 성과가 없어서 → 학습한 내용을 기록하기 시작
        • 강의, 스터디, 모각코에 대한 강제성과 스스로에 대한 동기부여
      • 스트레스
        • 러닝
        • 오프라인 스터디 그룹
        • 그냥 꾸준히 계속 성장에 집중해나가야 함
    • 마지막 메시지
      • 100명
      • 열심히 30명
      • 끝까지는 결국 1명
    • 느낀점
    • NEXTSTEP 강의들 많이 찾아볼 것
    • SSAFY 1~2월에 알고리즘 강의 마무리 될 때까지 NEXTSTEP 강의 들으면서 기본기 쌓자
    • 주말에는 오프라인 SSAFY 모각코 모임 만들어 스프링, JPA 공부 들자
    • 아니면 주말 오프라인 스터디에서 NEXTSTEP 강의 스터디 만들자
    • 5년동안 SM근무하면서도 꾸준히 공부해서 서비스 기업 간다. 나도 꾸준히 성장에 집중하면서 커리어 업해나가자

 

  • SI 개발자의 서비스 회사 적응기
    • 강의내용
    • 소개
      • 비전공자, SI 5년, 서비스회사
    • 회사생활
      • 실무 안 어려움, 패턴화 된 전형적 구조 개발
      • 근데 월화수목금금금
        • 프로젝트 - 집 무한 반복
        • 매일 새벽 퇴근 아침 출발
      • 꾸준히 공부
        • TDD, 클린코드 with Java 11기, 14기 계속 시도, 다른
        • 프로젝트 마감으로 계속 실패
    • 이직 활동
      • 유스방 활동
      • 잦바카페 활동
      • 사이드 프로젝트
      • 많은 세미나 활동
    • 누구를 위해 일하는가
      • SI - 고객
        • 마감이 절대적
        • 기존 소스 돌려막지만 쉽지는 않음. 그대로 복붙
        • 오픈만 있음 뒤는 없음
        • 유지보수는 SM에게
      • 서비스
        • 프로젝트 기한 협의 가능
        • 운영을 염두에 둔 개발
        • 다양한 팀들의 협업
        • 잘 만들기 위한 개인, 팀 고민
          • 테스트코드
          • 리팩터링
          • 코드리뷰
          • 문서화
          • 레거시 아키텍처 개선
    • 서비스 장점
      • 동료가 최고의 복지
        • 서로 배움
        • 끊임없이 성장하려는 사람들
        • 사내 스터디, 테크톡
        • 주도적으로 일하는 사람
      • ~4,5년차 기술적 학습은 혼자도 가능
      • 4,5~년차부터 추상화, 코드, 아키텍처 등 답이 없는 부분에 대해서는 서비스 기업과 격차가 클 듯
    • 이직에 도움 된 활동
      • 유스방 모의면접
    • 후회되는 점
      • 엄청 다양한 활동은 했지만 남지 않음 지금은 좀 정리함
      • 공부한 것들 잘 정리할 것
    • 느낀점
    • NEXTSTEP 강의 꼭 듣자. 먼저 강의 스터디하고나서 라이브 강의 피드백도 듣는거 고려하자
    • 스프링, JPA 강의 시간 산출해서 계획 짜보자