🙂2024.08.02
일일 회고 9회차
Keep
일일 회고를 꾸준히 하면서 성장하기 위해 노력하는 것
Problem
명확한 원인을 파악하지 않고 문제를 해결하는 것
여러 개의 방법 중에 최선의 방법이 아닌 빠른 방법을 선택하는 것
Try
일일 회고를 통해 원인을 명확하게 파악하고 문제를 해결했는지 검토
일일 회고를 통해 최선의 방법을 선택했는지 검토
오늘 할 일
사이드 프로젝트
알림 기능 설계
경험 및 배움
회사 업무
백엔드 CI/CD 개선
Github 자체 Runner로 gradle build를 수행하고 생성된 jar 파일을 캐시로 저장한 후, self-hosted Runner에서 해당 캐시를 다운로드 받아서 docker build와 push를 수행하도록 개선을 진행했다.
다음 글에 따르면 캐시는 한 Repository에서 최대 10GB로 제한되지만 최대 캐시 스토리지에 도달하면 캐시 제거 정책에 따라 가장 오래된 캐시가 삭제되고 공간이 만들어진다. 또한 캐시는 아티팩트에 비해 비용이 저렴하므로 캐시를 사용하도록 수정했다.
백엔드 CI/CD를 빠른 시일내로 개선하기 위해 문제가 정확하게 무엇이며 어떻게 수정하는 것이 좋을지를 제대로 정리하지 못 하고 작업을 진행했던 것 같다. 다음에는 문제 원인을 분석하고 개선할 방향을 정하는 시간을 정하고 진행하도록 하자.
사이드 프로젝트
알림 기능 설계
요구사항을 정의하고 데이터 설계를 수행했다.
알림 식별자
notification_id
uuid
PK
O
O
알림 유형
notification_type
varchar
O
REVIEW(리뷰), INQUIRY(문의), ANNOUNCE(공지), PURCHASE(구매), SALES(판매), WITHDRAWAL(출금), COMMENT(댓글)
내용
content
jsonb
O
수신자
receiver_id
uuid
FK
O
생성 날짜
created_date
timestamp
O
확인 여부
confirmed
boolean
O
default: false
어떤 알림인지에 따라 내용이 변경될 수 도 있을 것으로 예상되어 구조를 유연하게 저장할 수 있도록 내용의 타입을 jsonb로 설정했다.
수신자는 공지 알림일 경우 모든 사용자가 확인해야 하므로 nullable로 설정하여 하나만 저장하려 했으나, 사용자의 확인 여부를 판단해야 하므로 not null로 설정했다.
확인 날짜는 사용자가 확인하지 않았을 경우에는 null로 설정하고 확인한 날짜를 저장하려 했으나, 확인한 날짜를 관리할 필요가 없을 것으로 판단되어 boolean으로 설정했다.
PostgreSQL의 타입 중에 bool과 boolean의 차이 ?
PostgreSQL에는 bool과 boolean 타입이 있으나 bool은 boolean의 별칭을 의미한다.
SELECT pg_typeof(false::bool)
과 SELECT pg_typeof(false::boolean)
을 실행할 경우 둘 다 boolean
이라는 결과가 나오는 것을 통해 증명된다.
이처럼 설계한 것이 가장 좋은 방법이 아닐 수도 있으니, 다른 사람들은 어떻게 설계했는지 좀 더 조사한 후에 클래스 다이어그램 설계를 진행하자.
앞으로 할 일
회사 업무
백엔드 Github Actions 개선
LWLock 발생 원인 및 해결 방법 분석
개인 학습
AOP의 Joinpoint 분석
@Transactional 동작원리 학습
사이드 프로젝트
알림 기능 설계
Swagger Docs 보완
Last updated