• 코드 컨벤션

    • 도메인 별로 패키지구조
    • 메소드는 책임원칙을 지켜서 하자
    • 클래스명은 대문자로 시작 eg) StayService
    • CamelCase 사용 eg) StayService
    • 패키지명은 무조건 소문자 eg) stay
    • ENUM이나 상수는 대문자 eg)STAYTYPE
    • 메소드명은 소문자로 시작, 목적 드러나게 직관적으로 eg) getAllStay
    • 컬렉션이면 컬렉션임을 명시해줌 eg) List<Sprint> sprintList = new ArrayList<>();
    • Response는 Body에 필요한 데이터를 담아서 적절한 상태코드와 함께 반환, 반환할 데이터가 없으면 Mesage 클래스 사용 eg) return ResponseEntity<>(new Message(”응답메시지), HttpStatus.CREATED)
      • eg) return ResponseEntity<>(DTO, HttpStatus.CREATED)
    • Exception은 @RestControllerAdvice 사용해서 처리 =⇒ 일단 Illegalargument 등 기본 제공되는 Exception에 메시지만 담아서 던지고, 추후 리팩토링 시 CustomException사용
    • 코드에 대한 간략한 설명 주석으로 달기 ★그 코드가 왜 거기에 있는지 // +레퍼런스같은거 있으면 기술명세서 항목에 작성

  • 깃플로우 전략

    • 커밋 컨벤션

    1. GitHub Organization 계정 생성 https://github.com/orgs/H99-FinalProj-Moyiza/repositories

    2. FE / BE Repository 생성 FE - https://github.com/H99-FinalProj-Moyiza/Moyiza_FE BE - https://github.com/H99-FinalProj-Moyiza/Moyiza_BE

      • Repository 구성

        이름 없는 노트북 (7)-2 2.jpg

    3. Local Repository에서 각자 맡은 feature 브랜치 생성

    4. 작업 후 Origin Repository로 Push → Upstream develop 브랜치로 Pull Request

    5. Test 후 Upstream / develop → main merge

    참고자료 https://techblog.woowahan.com/2553/

  • 프로젝트에서 사용할 기술 스택을 정리해 와 주세요!

    • 라이브러리

    • FE : React / Tailwind / Recoil / S3 / GitHub Action

    • BE : Spring Boot / Spring Security / MySQL / AWS RDS, EC2, S3 / STOMP / QueryDSL / Spring data JPA / GitHub Action / Junit5

  • 이번 주 한 일

    • 팀 전체

      1. 서비스 기획 및 기능 구현
      2. MVP 구현 범위 설정

    • 팀원 개인별

      • API · 기능 명세서 / 진행상황 및 개인별 작업 확인 가능

      Front-End

      • 홍종훈 : 프로젝트 생성, 메인페이지, Event 기능, Club 기능
      • 김민정 : 회원가입, 로그인 구현
      • 정해진 : CI/CD 배포 환경 구축, Event 기능, Club 생성 기능

      Back-End

      • 강동현 : Event 생성, 조회, 삭제, 참여 기능 구현
      • 강재형 : Club 기능, Club 생성 기능 구현
      • 김덕인 : User 기능 구현
      • 이호정 : CI/CD 배포 환경 구축, Club 조회 기능 구현

  • 질문

    • 호정님 (Back-End) 이번에 CI/CD를 진행하면서 애를 먹었던 부분이 자동 배포를 하는 Code Deploy에 환경변수를 셋팅하는 일이었습니다. 저희는 계정 정보 암호화를 위해 Jasypt 라이브러리를 사용했는데, EC2의 우분투에 환경변수를 등록해주었음에도 배포 자동화 과정에서 그 변수를 읽어오지 못해 에러가 계속 났습니다. 결국에는 EC2의 .bash_profile에 환경변수를 등록하고, Code Deploy가 실행시키는 스크립트에 source 명령어로 .bash_profile을 로드 하여 문제를 해결했습니다. 문제를 해결하고나서야 일부 적용해두었던 Git Secret을 전부 적용해도 됐었겠다라는 생각이 들었는데, 현업에서는 이처럼 정보 암호화를 할 때 어떤 방식을 쓰는지 궁금합니다.

    • 민정님 (Front-End)

      imageFile을 서버로 전송할 수 없어서 코드를 수정했습니다. imageFile을 FormData에 직접 추가하려고 했으나 잘못된 방법이었고, imageFile을 Blob으로 변환한 후 FormData에 추가하여 정확히 서버로 전송할 수 있도록 수정했습니다. 텍스트 데이터는 formdata에 직접 추가할 수 있는 것으로 아는데, 위에서 data도 blob으로 감싸야하는 이유는 뭔가요? 서버에서 application/json 형식으로 처리하지 않고 다른 형식의 데이터를 요구해서 그런건가요?

      • 코드

    • 덕인님 (Back-End)

      1. 이전 프로젝트까지는 로그아웃 기능을 구현할때 AccessToken을 Redis / blackList에 저장하고 토큰 검증시 blackList을 확인하는 방식을 사용했었는데, 이번 프로젝트 진행시 문득 이 방식은 결국 세션 방식과 같지 않나? 라는 의문이 들었습니다. 현재는 AccessToken의 만료시간을 짧게(30분) 설정하고 로그아웃 진행시 RefreshToken을 DB에서 삭제, 로그인시 다시 발급하는 방식으로 구현했습니다. AccessToken 만료시 Access,Refresh Token을 헤더에 담아 요청 → Access Token 재발급, Refresh Token 만료시 다시 로그인 요청 → 새로운 Token 발급 blackList에 저장해서 관리하는 방법이 실제로 많이 사용되나요? 제가 미처 생각하지 못한 문제점이 있을까요?
      2. 우아한 형제들 기술블로그 내용을 참고하여 깃 플로우 전략을 구성했지만 올바르게 이해하고 적용했는지 잘 모르겠습니다. 혹시 보완할 점이 있을까요? 현재 작업 방식
      3. Upstream에 main, develop 브랜치 생성
      4. Fork → Local에서 각자 담당한 feature 브랜치 생성(user, club, event)
      5. 작업 후 Remote로 push → upstream develop으로 Pull Request 요청
      6. test 후 develop → main merge
      7. main 브랜치에 CI/CD 적용 (중간에 문제가 발생해서 현재는 develop 브랜치에 CI/CD 배포 환경 구축을 한 상태이고 최신 작업 사항들은 newdev 브랜치에 업데이트하고 있습니다)
      • Upstream에도 feature 브랜치를 생성해서 PR요청을 보내는게 맞는지 궁금합니다 (현재는 upstream/develop으로 PR 요청)

    • 재형

    -소켓 서버부담 줄이기 어떻게 ?

    -시니어개발자로서, 면접을 진행한다고 했을 때 우리 프로젝트를 보면 어떤 질문이 떠오르는지

    • 동현(Back-End) 1.

    • 숙제 : 멘토링 결과 다음 주까지 해올 일