[문제 발생 + 문제 유추]
CartService를 만들다가 에러가 나옴, 처음에는 인식의 문제인줄 알아서 엔티티를 수정하려했다.
[원인 규명]
| 'setTotalPrice(java. lang. Integer)'이(가) 'com. threemeals. delivery. domain. cart. entity. Cart'에서 public이 아닙니다. 외부 패키지에서 액세스할 수 없습니다. |
setTotalPrice 메서드의 접근 제한자가 public이 아니어서 발생한 것, @Setter를 적용했을 때, 접근 제한자는 기본적으로 필드의 접근 제한자를 따르게 된다. 따라서 @Setter가 적용된 필드가 private이거나 protected라면, setter 메서드도 private 또는 protected로 생성된다.
[해결]
storeRepository에 접근하여 직접 데이터를 불러오는 방식을 채택
[해결법 채택 이유]
보안상의 이유로, 아무나 접근할 수 있는 public으로 바꿀 수는 없으니
레디스 데이터 베이스 오류
[문제 발생 + 문제 유추]
코드 실행중에 db 관련 오류가 발생하였다. 확인하기 전에는 아마 간단한 설정 문제라고 생각을 하여 의존성을 확인했는데
[원인 규명]
그냥 데이터 베이스 설정을 못찾아서라는 간단한 오류였다. 다만 여기서 좀 헤메었던게, 마리아 db와 redis는 서로 같이 있어도 설정이 다르기 때문에 yml 파일에서 따로 설정해야했다.
datasource:
url: jdbc:mariadb://localhost:3306/3meals?serverTimezone=UTC
username: root
password: 123!
sql:
init:
mode: always
jpa:
show-sql: true
properties:
hibernate:
format_sql: true
dialect: org.hibernate.dialect.MariaDBDialect
# default_batch_fetch_size: 100
hibernate:
ddl-auto: create
defer-datasource-initialization: true
# open-in-view: false
redis:
host: localhost
port: 6379
[해결]
처음에는 redis 오류인줄 알았으나, 그냥 단순히 마리아 db의 설정을 하지 않아서 생긴 문제였다... 해결 이유는 따로 없고 그냥 설정을 안한거라 별 기술할 내용은 없지만, redis와 다른 DB는 완전히 따로 돌아가고 의존성 Config 같은 설정도 완전이 따로 해줘야한다.
[문제 발생 + 문제 유추]
JPA로 자동으로 테이블을 생성하게 해 두었는데, order 테이블이 생성이 안됨, JPA 자동 테이블 생성에서 등록을 안했는지 의심
[원인 규명]
의심과 다르게 자동 테이블에 정상적으로 등록이 되어있어서, 구글링해본 결과 mysql에서 order를 이번 약관부터 사용하다보니 order 테이블을 생성하지 못했던 거였음
[해결]
단순히 테이블 명을 orders로 수정하였음, 덕뿐에 일관성을 위해 다른 테이블도 다 s를 붙이는 형태로 수정함
[문제 발생 + 문제 유추]
코드 실행시 데이터 베이스에 id 값이 없다는 에러가 발생, @id로 자동으로 id개 배분되고 있었다보니 영문을 모르고 있었다. 그래서 어노테이션 쪽을 수정하고 있었는데.
[원인 규명]
의심과는 다르게, 레디스를 활용한 레포지토리 파일은 jpa의 영역 밖에 있다보니 @id를 사용한다고 id가 자동으로 배분이 될리가 없었다. 거기에 RDB와 다르게 레디스는 KEY-VALUE라 어노테이션이 필요없는 일반 자바 객체로 관리하는 방식어었다...
[해결]
카트 ID를 USERID로 생성하도록 했다. 카트는 한명당 1개씩 간헐적으로 배분되게 설정했기 때문에 이렇게 진행해도 문제가 없었고 잠깐 DB에 저장될 장바구니 데이터였던 만큼 mysql보다는 빠른 레디스를 사용하였다. 안정성이 떨어지는 만큼 중요한 데이터를 오래 보관하기 힘든 레디스지만 이렇게 잠깐 저장할 데이터는 빠른 처리가되어 확실히 처리가 용이했다.
회고
확실히 팀 프로젝트는 난이도가 높다라는 생각이 든다. 사실 처음 사용하는 레디스와 노드가 많은 데이터들을 외래키로 불러오는 작업이 어려웠지만 이 부분은 사실 비교적 쉬웠다.
오히려 git을 쓰면서 생기는 문제나 사람들이랑 계속 소통하는 방식이 새로운 관점을 제시해 준다는 점에서 좋았지만 확실히 여러므로 데이터를 덮어씌워서 만들던게 날아간다거나, 프로젝트가 꼬여서 과거에 복사해둔 프로젝트를 사용했는데 깃 히스토리가 없어서 git pull 을 못하게 되었다든지, 참 여러므로 문제가 많았다.
새로운 기술보다도 사람들과 잘 소통할 수 있는 기술의 이해와 개념을 가지고 있어야한다는 것을 절실히 느낄 수 있었다.
회고는 아래의 KPT에 추가되는 내용과 일치한다. 하지만 가장 큰 요점은 새로운 기술의 도전과 결합력, 응집력에 대한 고찰이 정말 중요하다.
Keep (유지할 점)
- 강성욱
- 빨리빨리 만들기(?)
- 팀원들을 존중하는 마음
- 이경훈
- 프로젝트에 책임감을 갖는 것
- 새로운 시도를 해보는 것
- 이하영
- QueryDsl, 팀장이라는 새로운 시도를 해본 점. 앞으로도 새로운 것을 배우는 자세를 유지하고 싶다.
- 일정을 일부러 타이트하게 짠 것.
- 이진영
- 역할분담과 계획을 같이 세우고 프로젝트를 시작하는 부분이 좋았다
- 김창현
- 클린 코드를 지향하는 자세
- 포기하지 않고 끝까지 책임을 다하는 자세
Problem (개선이 필요한 점)
- 강성욱
- 시간을 최대한 확보해 팀원들과 코드 리뷰!!
- 간결한 프로젝트 구조에 대해 생각해보자!!
- 테스트 코드 이외에도 테스트 데이터를 깔끔하게 만들어, 테스트를 빠른 시간 안에 할 수 있도록 생각해보자.
- 이경훈
- ERD, API를 제대로 만들지 않아서 생긴 문제가 많았다. 추후 수정하는 과정에서 시간을 너무 많이 잡아 먹었다.
- 새로운 시도의 경우 시도 하는 도중에 기록을 같이 하는 것이 좋다. 추후 다시 볼 때 뭔지 잊는 경우가 많았다.
- 맨 처음에 공용으로 설정한 부분에 대해서는 정확히 이해하고 함부로 수정하지 말아야한다.
- 깃의 경우 사용에 문제가 있을 때가 많으니 조그만한 부분이라도 PR을 올리는게 좋다. 중간 저장 안해서 한번에 올릴 때 충돌이 많이나면 수정하기 힘들다.
- 새로운 기술을 추가하고 싶으면 미리 공부하고 적용하는게 좋다. 갑자기 추가하니 일정 맞추기 힘들다
- 폴더에 경우 DOMAIN을 기준으로 하기보단 기능을 기준으로 나누는게 더 좋을 것 같다.
- 다른 파트의 내용을 흡수할 시간이 부족했다.
- 이하영
- 5분 기록 보드 등 프로젝트를 하면서 기록을 거의 안 했다ㄷ
- 타당한 이유가 부족한 점
- 코드 리뷰 할 시간이 많지 않았던 점
- 프로젝트 관리 등에서 꼼꼼하지 못한 점 (요구사항 확인 등)
- 깃, 기술 등에서 아직 알아야 할 것이 많다.
- 프로젝트가 커질 수록 패키지 구조를 어떻게 나누는게 좋을지 고민해봐야 될 듯
- 이진영
- API명세서에 오타가 있었고, 프로젝트 진행중에 API에 변경점이 있었는데 바로바로 고치도록 노력해야겠다
- 김창현
- 구조에 대한 생각을 더 해보는 것이 필요할 듯 하다.
- 성능 개선을 더 고려해야 할 것 같다.
Try (해결책, 시도할 점)
- 강성욱
- 서버에 배포하기!
- 깃허브로 푸시한 이후, 테스트가 정상적으로 완료되면, 자동으로 배포되는 과정까지 경험!!
- API 문서화 조금 더 신경쓰기!!
- 이경훈
- ERD, API 명세서는 고민을 제대로 해볼 것
- 새로운 시도를 할 경우 소통을 더 중시할 것
- 시도하기 전에 뭔지 알고, 얼마나 걸릴지 파악해 둘 것
- 폴더는 기능을 기준으로 나눌 것
- 모든 기능의 Entity, Reository의 경우 처음에 미리 만들어서 공유하는게 좋다.
- 복사 붙여넣기 하지마라, 히스토리 날라간다
- 기능끼리 연관관계가 깊어질수록, 코드를 구성하기 힘들다. 우선은 새로운 기술 사용에 힘을 써보는 것을 목표로 하는 것이 좋을 것 같다.
- 이번 프로젝트에서 가장 힘들었던 점은, 새로운 기술의 적용으로 생긴 에러, 여러 기능과 연동으로 CRUD 제작에 어려움이 생긴 점이였다. 이 2개의 사용법과 팁을 반드시 기록해 둘 것
- 5분 기록보드를 쓰는 것이 학습에도 유리할 것 같다. 앞으로는 자주 사용하도록 하자
- 이하영
- TIL을 쓰진 못하더라도 조금이라도 시간 내서 5분 기록보드를 써보자
- 코드 리뷰 하는 시간을 억지로라도 만들어서 하면 좋을 것 같다.
- 짬날 때 놀지 말고 튜터님이 추천한 유튜브를 보며 지식을 쌓아보도록 노력해야겠다.
- 이진영
- 프로젝트 요구사항을 자주보자.
- 프로젝트 관련 문서들을 자주 보고 잘못되었거나 수정해야할 부분이 있으면 꼭 팀원과 공유 할 것
- 김창현
- 프로젝트의 문서화(시각화)를 더 신경써야 할 것 같다.
- 프로젝트의 기반을 다지는 것에 더 힘써봐야겠다.
- 테스트 코드를 중요한 기능에는 바로바로 적용할 수 있도록 해봐야겠다.