🙂2024.08.07

일일 회고 13회차

Keep

1. 일일 회고를 꾸준히 하면서 성장하기 위해 노력하는 것

Problem

1. 명확한 원인을 파악하지 않고 문제를 해결하는 것

2. 여러 개의 방법 중에 최선의 방법이 아닌 빠른 방법을 선택하는 것

Try

1. 일일 회고를 통해 원인을 명확하게 파악하고 문제를 해결했는지 검토

2. 일일 회고를 통해 최선의 방법을 선택했는지 검토

오늘 할 일

• 회사 업무

  • 신기능 기술 검토

• 사이드 프로젝트

  • 알림 기능 구현

경험 및 배움

회사 업무

신기능 기술 검토

신기능에 대한 디자인이 완료되어 디자인 리뷰 회의가 진행됐다. 디자인 리뷰 회의 전에 디자인을 검토하여 궁금한 것과 수정이 필요한 부분을 기록하여 회의에 참석했다.

회의가 시작되고 요구사항과 사용자 관점의 순서도, 디자인을 설명하던 중에 프론트 시니어분께서 순서도와 디자인에 대한 여러 문제점을 제기했다. 첫 번째로 그려진 순서도가 모호하여 보는 사람에 따라 생각이 다를 수 있다는 점을 제기했다. 두 번째로 디자인은 성능적으로 불가능한 기능과 마감 기한까지의 공수가 부족하여 개발 불가한 기능들에 대해 제기했다. 그 이후 나는 처리 시간 때문에 불가능한 UX에 대해 제기하고 다른 방법을 제안했다. 이처럼 문제점에 대해 한 두개씩 제기하다 보니 회의 시간이 부족하여 내일 이어서 회의를 하기로 했다.

이번 회의를 통해 기존에는 대략적인 구현 방안을 생각하면서 디자인을 검토했으나, 상세한 구현 방안을 생각하면서 구현 가능한 디자인이 맞는지를 판단하면서 검토하는 것이 필요하다고 느꼈다. 프론트 시니어분이 데이터가 많아졌을 경우와 사용자가 브라우저를 껐을 경우 등에 상황을 예시로 들면서 문제를 제기한 것을 보아 상세한 구현 방안을 생각하신 것으로 받아들여졌다.

앞으로 디자인 리뷰를 진행할 때는 상세한 구현 방안과 여러 상황을 고려하여 검토를 진행하도록 하자.

사이드 프로젝트

알림 기능 구현

이벤트를 수신하여 처리하는 리스너 클래스를 어떻게 구현할 지 많이 고민이 되었다. 고민이 된 부분은 다음과 같다.

1. 이벤트 리스너에서 도메인 생성 이벤트별로 처리하는 메서드를 구현하는 것

2. 도메인 생성 이벤트 인터페이스를 두고 이벤트 리스너에서 하나의 메서드를 구현하는 것

도메인 생성 이벤트별로 메서드를 만들게 되면, 유사한 코드로 구성된 메서드가 여러 개가 생기게 될 것으로 판단되어 하나의 인터페이스를 두고 구현하는 방식을 채택했다. 이 방식으로 구현한 뒤에 어떠한 장단점이 있는지 살펴볼 예정이다.

앞으로 할 일

• 회사 업무

  • LWLock 발생 원인 및 해결 방법 분석

  • Github Actions 추가 개선 (ref. 백엔드 Github Actions 개선)

• 개인 학습

  • AOP의 Joinpoint 분석

  • @Transactional 동작원리 학습

  • Webflux와 R2DBC에서의 페이징 활용법 조사

• 사이드 프로젝트

  • Swagger Docs 보완

  • @Profile 적용

  • 알림 기능 구현