데브코스 백엔드 3기 92일차

벌써 프로젝트 기간이 되었다니 실감이 안난다
이제 플젝 2개하고나면 데브코스도 끝이라니?!
곧 100일,,ㅋㅋㅋㅋ
지난주는 팀 프로젝트 구성하고 설정하고 아주 정신이 없었다
까먹기 전에 얼른 기록해두기


일기(회고)

  • 지난주, 쉽지 않았다 속으로 코드 짜고 싶다 100번 외침ㅋㅋ
    프로젝트 일정 짜고, Jira 세팅하고(젤 어려움), 유저스토리 작성하고,
    각종 컨벤션들 짜고, 와중에 기능 구현에 사용하는 기술 공부하고 등등
    병아리 PO + developer에게 살짝 버겁지만
    아주아주우 알찬 1주일이었다!
    • 5-6시간씩 팀원들이랑 상의하다보니까 끝나고나면 진이 빠지더라 ㅎㅎ 밥 엄청먹음
      • 혹시 지쳤니?!라고 몇번을 물어봄 그래도 아니라고 말해주는 아이덜
    • 힘들었어도, 어느정도 일정에 다 맞추어 진행되어서 뿌듯-!


  • ㅅㅍㅅ님과의 면접날에 대한 대화
    좋은말씀을 많이 해주셔서 응원이 되고 힘이났음 ㅎㅎ
    • 나를 뽑는 것에 대해 전혀 고민하지 않으셨다고..!(갬동)
    • 갑분 추억회상,
      면접 전보다 면접을 보고 데브코스가 더 너무너무 하고 싶었다
      사실 면접 전에는 독학도 고민을 하고있었다
      그런데 내 github과 자소서를 꼼꼼하게 다 보았다는게 느껴져서
      면접 보면서 속으로 여러번 놀랐고
      이 교육은 엄청 탄탄할것 같았다(실제로도)
      면접을 겪어보고 나 너무너무 되고싶다! 했었쥐

    0116


  • 프로젝트 기간동안 많이 배우고 건강하기 목표!
    배우게된것들 꼭 다 기록해두고 싶은데..!
    건강하려면 잠도 자야하고! 그치만 알고리즘도 계속 풀어야하고!
    암튼 열심히 합시다 ㅋㄷㅋㄷ



Jira

  • 정말정말 낯설고 정말정말 삐질대며 설정한 Jira..!
    아직도 친해지는 중(거리가 먼 jira ㅎㅎ)
    혼자 하다가 살짝 포기를 고민하는 중에 ㅇㅂ이의 도움을 받았다 커피사주기 잊지말것!
    지금와서 보면 별 내용 아닌거같은데(별 내용 아니지 않음), 그때는 왜 그렇게 어려웠는지?(개구리 올챙이적)
    암튼 가장 힘겹게 했고, 가장 뿌듯한 파트

  • 이슈란 무엇인가

    • 제품에 관해 회사에서 대화의 대상이 되는 거의 모든것
    • ticket이라고 하기도 함
    • 오류, 버그, 새로운 기능, 작업요쳥, 사소한 질문, 의견 등 모든것이 될 수 있음



Jira 프로젝트 생성

지라에픽

  • Epic : 여러 splint에 걸쳐 진행되는, 여러 User Story의 집합
  • User Story : (사용자)는 (무엇)을 위해 (무엇)을 하고싶다에 대한 actor의 use case
  • Sub Task : 스토리 혹은 초어들을 개발하기 위해 진행되는 실제 세부 개발사항들


  • Epic을 작성하려는데, 예시들이 개발과 관려되지 않아서 따라하려해도 멈칫했다
    그냥 큰틀이라고 생각하고 작성을 했고, 그러다보니 도메인별로 나누게 되었다
    (나도 PO가 처음이라 서툴ㅎ)
    이번에 이렇게 해보고, 더 좋은방법이 생각난다면 다음번에 좀 더 발전시켜봐야겠다



Jira 자동화 규칙 생성

  • 라이브러리에 있는 규칙을 설정하니까 매우 편했다

지라자동화실제



Jira-Github 연동해서 issue 관리 + 자동화

  • ex) 에픽 유저스토리 하위태스크 예시
    • 실제 플젝의 내용은 아니고
      팀원들에게 사용법과 플로우를 이해하기 쉽게 공유하고 싶어서 쉬운 예시를 만들어 공유했다

에픽유저스토리하위태스크


1. Jira에서 Github for Jira 앱 다운받기



2. github Organization 연동

  • repository 선택 가능



3. organization 안의 repository에서 feature/[이슈번호] branch 생성

  • husky로 git hook 관리하는 거까지 해볼까 했으나 이건 다음 플젝 때 공부해보고 적용하려 한다
  • 이슈라는 단어조차 낯설어서 이 단계까지 오는데에도 많이 헤매면서 공부했다(뿌듯하긴 하쥐)



4. 기능구현 완료 후 commit 시, commit 제목에 하위태스크 이슈번호 포함해서 작성

  • ex) Feat : 이슈번호 ~~~ 기능 구현

커밋은하위태스크이슈번호

커밋은하위태스크이슈번호2


  • commit 후 Jira : 자동화 규칙으로 인해 진행중으로 자동 변경됨

커밋후지라(진행중으로)



5. 하나의 user story 기준으로 PR : PR 제목에 user story 이슈번호 포함해서 작성

  • ex) 이슈번호 ~~~ 구현
    • 본문에 해당 user story의 하위태스크들 이슈번호 같이 적어주기 Resolved : 이슈번호, 이슈번호

PR제목에는유저스토리이슈번호


  • PR 완료 후 Jira : 자동화 규칙으로 인해 완료됨으로 자동 변경됨

완료후지라


  • 사실, commit과 pr 단위를 내 마음대로 각각 하위태스크와 유저스토리로 정하긴 했는데
    이것 또한 이번에 해보고 더 좋은 방법이 있다면 다음 플젝 때 적용해보아야지
    Jira와 좀 많이 친해진듯ㅎ



SpringBoot project 생성 + 설정(버전 등)

  • JDK는 17로 결정
    • 일단 lts버전을 사용하려고 했기에 11과 17중에 고민하다가, DTO를 사용할 일이 많은데 Record class를 사용하면 가독성도 높고 편하게 코드작성이 될거라 판단해 결정했다
    • 그 외에 사용할지 모르겠지만, 텍스트블록과 케이스문 람다식이 지원 되는것 등의 기능이 추가적으로 있어 기회가 있다면 사용하기로 했다
  • SpringBoot 버전은 2.7.x로 결정
    • 3.x 버전이 있지만 Security 강의 들을 때 3.x버전 쓴 사람들이 애먹던걸 옆에서 보았기 때문에,,
      Security 사용하는 우리는 안정적으로 가자며 나름 최신의 2.7.x로 결정
  • TestContainers : 테스트 이전에 Docker Container 다로 안띄워도, 테스트 시작 시 자동으로 띄워줌 + 끝나면 알아서 종료
    • 사용은 2가지 이유로 결정
      • 외부모듈에 대해 멱등성을 유지하며 테스트 할 수 있다
      • production에 가까운 환경에서 테스트를 할 수 있다
      • 팀원들의 로컬환경이 다 다를텐데 TestContainers를 사용하면 걱정이 없었다
      • 그러나 단점, 테스트 시 생성+실행+삭제로 시간이 오래걸림(오래걸려도 너무 오래 걸림 Docker compose 공부해보기)


  • project structure와 class를 만들고 공통으로 건드리게 될 파일들도 미리 셋팅했다
    • dependency는 우리가 사용 확정 한 security, swagger, validation, caffeine cache, test container 등을 넣었다
    • logback 설정도 하고
    • encoding도 UTF-8로 모두 통일
    • yml파일도 JPA 설정하고, DB나 Security 관련 설정들은 외부환경파일로 분리해 include 해서 올렸다
  • TMI) 한번에 깔꼼하게는 못올렸고 진짜_최최최최_최종으로 여러번 올림 ㅎㅎ


제목 없음



참고한 블로그

  • CheckStyle : Java source code가 지정한 codinig convention을 준수하는지 확인하기 위한 정적 코드 분석 도구
    • 저장된 규칙에 어긋나면 컴파일시 경고나 에러 띄움


1. Preferences - Plugins - Marketplace에서 CheckStyle-IDEA 플러그인 설치


2. naver github에서 3개 파일받기

제목 없음

  • naver-intellij-formatter.xml : IntelliJ Formatter 적용
    • IntelliJ Preferences Open - Editor - Code Style - Java- Scheme - Import Scheme - IntelliJ IDEA Code Style XML - naver-intellij-formatter.xml 파일 선택
    • Cmd + Option + L 누르면 지정한 code style에 맞게 자동으로 formatter 적용
  • naver-checkstyle-rules.xml
  • naver-checkstyle-suppressions.xml


3. Preferences - Tools - CheckStyle

  • Scan Scope : All sources(including tests)로 설정
  • Treat Checkstyle errors as warnings 체크
  • Configuration File의 + 버튼 클릭
    • Description은 Naver Checkstyle Rules
    • Use a Local Checkstyle File 선택 후 naver-checkstyle-rules.xml
  • suppressionFile 변수 설정 : value에 naver-checkstyle-suppressions.xml 입력
  • Naver Checkstyle Rules의 Active 체크


=> IntelliJ 하단에 CheckStyle 탭에서 coding convention 준수 여부 체크



Erd Cloud

  • 무료이고 여러명이서 접근 가능한 Erd Cloud를 사용해서 Erd를 만들었다
  • 이미지 파일을 여러 도메인(member, product, feed)에서 사용하기 때문에 이미지 테이블을 가장 고민했다
    • 1번) 이미지 테이블안에 컬럼으로 member_id, product_id, feed_id를 넣는다
    • 2번) 이미지 테이블은 image_id와 path만 가지고 도메인별로 중간테이블을 만든다
    • 3번) 이미지 테이블에 domain type을 Enum값으로 넣고, 그에 따른 domain의 id를 컬럼으로 넣는다

제목 없음

  • 결론은 3번으로 결정!
    • 덕분에 RDB를 사용하는데도 혼자 동떨어져있음
    • 이유는 현재 서비스의 크기가 작아 최대한 테이블의 개수를 줄이고 싶기도 했고, 하나의 테이블에서도 충분히 관리 가능할거라 판단했기 때문이다 서비스가 커진다면 그 때 마이그레이션을,,



Branch 전략

image

  • Github flow
    • Main : 안정화 버전 브랜치
    • Develop : Merge 전용 브랜치
    • Feature : 작업 시 하나의 브랜치 생성(feature/[이슈번호])



Template

PR Template

### ⛏ 작업 사항


### 📝 작업 요약


### 💡 관련 이슈
- Resolved : [이슈번호], [이슈번호]
  • PR 시 PR template이 자동설정되도록 pull_request_template.md를 생성했다
    • root directory, docs directory, .github directory 중 한 곳에 생성하면 됨
      • .github/pull_request_template.md
      • docs/pull_request_template.md
      • root directory 아래 /pull_request_template.md

제목 없음


Commit Convention

Keyword 설명
Chore 빌드 업무 수정, 패키지 매니저 수정
Feat 새로운 기능 추가
Fix 버그 수정
Docs 문서 추가, 수정, 삭제
Style 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
Refactor 코드 리펙토링 (기능의 변경은 없지만, 코드의 구조 개선)
Test 테스트 코드, 리펙토링 테스트 코드 추가 


##### 제목 - 50자 이내로 한글로 요약(도메인은 클래스명 그대로 영어)  

### <커밋 타입> 띄고 : 띄고 [이슈번호] <제목(명사)>

##### 본문 - 한 줄에 최대 30 자 이내로 한글로 입력하기

# 1. 무엇을 수정했는지
# 2. 왜 수정했는지

-
#  <커밋 타입>    <리스트>
#   Feat      : 새로운 기능 추가
#   Fix       : 버그 수정
#   Refactor  : 코드 리펙토링 (기능의 변경은 없지만, 코드의 구조 개선)
#   Style     : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
#   Docs      : 문서 추가, 수정, 삭제
#   Test      : 테스트 코드, 리펙토링 테스트 코드 추가
#   Chore     : 빌드 업무 수정, 패키지 매니저 수정
# ------------------
#   [체크리스트]
#     제목 첫 글자는 대문자로 작성했나요?
#     제목은 한글로 작성했나요?
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기(Enter 2번)
#     본문의 메시지를 작성할 때 "-"로 구분했나요?
#     컴파일이 되나요?
#     Feat 시, 기능단위로 작성했나요?
#     Fix 시, 수정 단위로 작성했나요?
# ------------------

  • 예시)

    제목은
Feat : [이슈번호] Image 등록 기능 구현

본문에
- 파일업로드 관련 공부 [이슈번호]
- 파일업로드 --- 상의 필요 [이슈번호]
  • 모두가 이슈관리는 처음이라 기준을 정하기가 어려워, 이슈를 대화의 대상이 되는 모든것으로 일단 이번엔 이해하기로 하고 이슈번호를 마구마구 생성했다^^ㅎㅎ
  • 이번주는 많은걸 알아보느라 정말정말 하얗게 불태웠다 그만큼 뿌뜻
  • Kream clone project, 신발만 다뤄서 Shoe-Kreamㅎㅎ 스타뜨!


업데이트:

참고