📒 목차

📌 포인트가 없어도 의뢰서 요청이 날라가는 문제
📌 유저의 닉네임 중복 불가로 수정하기

📌 포인트가 없어도 의뢰서 요청이 날라가는 문제

✅ 문제 상황

현재 개발중인 도움닫기[Doumdattgi] 프로젝트 서비스 중에는 게시글을 판매자가 올리고 구매자가 의뢰서를 요청하는 서비스가 존재한다.

여기서 문제 상황이 생겼는데, 의뢰서를 요청하는 과정에서 서비스에 사용할 수 있는 포인트가 의뢰서 요청시 차감되는 구조로 서비스가 진행이 되는데 포인트가 부족해도 의뢰서 요청이 진행되는 것이다.

코드를 작성하면서 보유 포인트를 확인하는 검증 로직을 추가했기 때문에 프론트엔드 화면 상에서는 에러가 출력되었지만 실제 데이터베이스에서는 저장이 되는 상황이었다.

✅ 해결방안

위 문제 상황을 인지했을 때, 다행히 어느 부분에서 문제가 있는지 직감적으로 알 수 있었다. 의뢰서 요청 API의 경우, API 요청이 발생하면 먼저 API가 진행되기에 앞서 검증 과정을 거쳐야 한다. 예를들어 보유 포인트가 의뢰 요청 금액만큼 보유하고 있는지, 같은 게시글을 동일인이 요청하는 것이지와 같은 것들이다. 여기서 문제 원인은 보유 포인트 확인 로직이 의뢰서 저장 로직 이후에 이루어진 것이다. 따라서 에러는 전송되지만 데이터베이스에는 저장이 된 것이다. 따라서 의뢰서 요청 API 검증 로직의 순서를 최상단으로 옮기고 이후의 로직을 진행하도록 수정하였다.

✅ 피드백

정말 간단하고 기초적인 오류였다. 로직의 흐름을 생각하면 당연히 이와 같이 로직을 구성해야 했다. 이러한 실수를 한 것이 스스로 너무 화가나지만 이미 발생한 일이기 때문에 앞으로 코드를 작성하며 두번 다시 이러한 실수를 하지 않도록 명심해야겠다.

📌 유저의 닉네임 중복 불가로 수정하기

✅ 수정 상황

초기에 서비스를 구상하고 설계할 때는 닉네임의 중복을 허용한다는 것을 기준으로 개발을 진행하였다. 하지만 프로젝트를 진행하던 중 팀원들과의 의견을 나누어보니 게시글을 조회해올 때, 판매자의 닉네임이 화면에 나타나고 해당 닉네임을 기준으로 구매자가 상대방을 확인하기 때문에 닉네임이 중복된다면 혼란을 일으킬 수 있을것이라 판단 했다.

따라서 기존에 닉네임 중복 허용을 멈추고 중복 검증 로직을 추가하게 되었다.

✅ 해결방안

유저가 닉네임을 수정하고 생성하는 상황은 우리 서비스에서 두가지 상황이다.
먼저, 회원가입 할 때, 닉네임 입력이 필수이기 때문에 회원가입시 닉네임 중복 검증이 이루어져야 하며, 두 번째로 설정페이지에서 닉네임을 수정할 수 있기 때문에 여기 또한 마찬가지로 검증이 이루어져야 한다.

아래의 코드는 닉네임 검증 함수이다. 해당 함수에서 닉네임 형식 및 중복 검증을 수행한다.

따라서 닉네임 검증이 이루어져야 하는 두 가지 상황에서 퍼사드 패턴을 적용하여 아래 함수를 공용으로 사용하여 검증을 진행한다.

✅ 피드백

프로젝트를 진행하면서 아직 많이 미숙하다는 것을 느낀다. 단순히 코드를 작성하는 것이 어렵다기보다 서비스를 만들 때, 어떤 것을 추가하고 어떤 것을 버려야 하는지 판단하는 것이 가장 어려운 것 같다.

처음 기획때부터 완벽하게 기획을 끝마치고 그대로 프로젝트를 만드는 것이 가장 이상적인 프로젝트 진행일 수 있겠지만 막상 프로젝트를 진행해보니 수정사항이 너무나 많이 생긴다.

아직 경험이 많이 없어 이러한 현상이 생기는 것이라 생각한다. 앞으로 이러한 부분을 잊지 않고 하나씩 나의 경험을 쌓아나가 다음에 비슷한 상황이 생겼을 때는 이와 같은 변경사항이 생겨나지 않도록 노력해야겠다.