목차
- 자기소개 및 팀원 소개 (20초)
- 팀 문화 (30초) - 커뮤니케이션적인 우리팀만의 강점 찾아보세요
- 매일 아침 데일리 스크럼
- 배탈나거나 다이어트하지 않는 이상 같이 점심먹기 - 아직까진 없었습니다~
- 프론트,백엔드 이슈,수정상황이 생길경우 바로바로 말하기
- 팀원의 발목을 붙잡지 않고 야근을 강요하지 않는 퇴근 문화 (정해진 코어타임에만 빡세게!! 짧고 굵게!!)
- 핵심 기능 및 간단한 기획 설명 (1분)
- 현대 내 차 만들기 서비스에서
- 내게 맞는 트림찾기, 고민해보기, 카마스터 찾기
발표에 담을 내용 (BE)
- 아키텍처 구조 설명 (draw io) + 기술 스택 (1분)
- 역할 분담 (30초)
1.
2. 김정연 - 프론트엔드 CD, HTTPS, 도메인 관리
3. 김우혁 - AWS EC2 인프라 세팅, 데이터베이스 및 AWS S3 관리
4. 손승완 - 백엔드 CI/CD, 도커 관리
- 어떤 식으로 협업했는지 (30초)
- 노션 API 명세서 공유 방법 → Swagger 같은거를 왜 안썼냐? 에 대한 질문 대처
- 버그 및 이슈, 아이디어 페이지 좀 작업을 해야될 듯??
- 기술적 도전 or 고민했던 부분 or 힘들었던 부분 (약 4분..)
- 깃허브 잘 못다룬 이슈(코드 전체 날릴 뻔, 브랜치 main에서 떨어진거, be-develop에 있는 파일이 be-main, main에 없었던거)
- 프로젝트 전반에 걸쳐 깃허브와 관련된 자잘한 이슈가 있었습니다. 우선 reset 명령어를 잘못 사용하여 구현한 코드를 통째로 날린 일이 있었습니다. → 정연님한테 여쭤보기
- 또한 브랜치 관리를 잘못하여 main에서 be-main 브랜치가
- 성능 개선(API 로직 최적화 + 부하테스트 + 캐시)
- 트림 선택 페이지, 내게 맞는 트림 찾기, 추가 옵션 선택 페이지
- 처음에 몇 초 걸렸는지 이미지 보여주기
- 부하테스트를 통해 시간이 오래 걸리는 API들을 찾아내어 캐싱과 로직 최적화를 통해서 시간을 단축할 수 있었다. 캐싱은 Spring boot 기본 캐시를 사용하였습니다.
- 판매량 더미 데이터 만들기 및 스케줄러 쿼리로 주기적으로 업데이트
- 기획 상에는 판매 데이터를 따로 가지고 있지 않고 그냥 각각의 옵션, 내장 색상 등에 구매 비율을 고정 값으로 설정한 것으로 기억
- 판매 더미 데이터를 임의로 만들었고 MySQL의 이벤트 스케줄러를 통해 매일 새벽 3시에 해당 테이블에 저장된 데이터를 계산해서 구매 비율이 갱신되도록 스케줄링하였습니다.
- 통합테스트에서 유닛테스트로 수정하면서 테스트 커버리지 97% 도달했던 일화(수정 이유)
- API개발 처음엔 테스트코드를 통합 테스트로 작성하였는데 다른 팀들과의 피어세션을 통해 단위 테스트로 진행하는게 더 좋을 것 같다는 피드백을 들었습니다. 팀원 모두 단위 테스트를 하는 방법을 잘 몰라 처음엔 어려움이 있었는데 서로 공부한걸 공유하면서 이를 해결할 수 있었습니다.
- spring data jdbc → jdbc template으로 넘어간 일화
- 내맞트 필터링 캐싱 + 부하 테스트
- 도커(nginx → HTTPS, spring)
- 깃허브 액션 + S3로 정적 웹 호스팅
- CloudFront → HTTPS 설정 후 배포 반영 안되는 문제 → 캐시 무효화
- ERD 설계에서 트림과 옵션을 연결하면서 생각하기 어려웠던 문제들을 트림과 기능을 연결하면서 해결
- DB 분리 안했다가 분리 한거
문득 궁금했던 점들 기록
- Nginx 없이도 https가 적용 가능한가??
- Nginx를 사용한 이유
- 스프링부트 기본 캐시는 어떤 방식으로 데이터를 저장하나요?
- 왜 레디스 같은 인메모리 디비 따로 안 쓰고 스프링 자체 기본 캐시 썼나요?
발표에 담을 내용 (웹)
발표에 담을 내용 (FE)
기획과의 미팅에서 기능구현이 최우선이라는 얘기를 듣고, 프로젝트의 목표를 기능완성으로 설정하였다.
개발