회원가입및 유저 CRUD에서의 디테일한 에러핸들링

### ISSUE
- Group: `server`
- Type: devlog
- Topic: 회원가입및 유저 CRUD에서의 디테일한 에러핸들링

- Content:
이번 4주간의 프로젝트 후 가장 기억에 남는 부분을 남기고자 한다.
먼저 포지션은 백엔드를 전담하였고 이때 주로 API 컨트롤러를 맡았었다. 저번 퍼스트 프로젝트에서는 CRUD간의 에러핸들링을 잘잡았다고 생각했으나 이번에 자체 개발된 테스트케이스를 돌려보고 유저의 CRUD를 어떻게 디테일하게 잡을지 나름 원칙을 정하고자 한다.
1. 토큰은 있을수 있고 없을 수 있을 뿐아니라 토큰이 해독이 안될수 있다.
2. 응답은 무조건 return을 붙여주어라
3. 변수명은 되도록 직관적으로 작성하여 협업간 혼동이 없도록 해라

위 3가지 원칙이다.
먼저 1번째로 나타내면 항상 토큰을 해독하고 거기에 유저정보가 있으면 status 200을 반환하였다. 하지만 이번 프로젝트를 진행하고 토큰을 해독하고 유저의 정보가 있는지가 아닌 토큰이 해독되는지부터 확인을 하면 좀 더 편리한 예외처리가 될것이다.
예를들어 로그인과정에 토큰을 해독하고 유저를 찾는것까지 총 2개의 분기를 나누었다면 토큰을 해독하는중 에러가 나서 status400번대를 나타내면 좀더 불필요한 동작을 막을수 있다는 것이다.

2번째로 return으로 응답하라 입니다. 저는 항상 return없이 응답하여 분기를 세부적으로 나누었어야 했고 혹시 밑에 분기를 안나누어준 응답이 있으면 응답을 2번 보내는 에러를 범하게 되었었다. 하지만 이제 응답에 return을 붙이므로써 에러분기 밑의 응답은 무시하도록 처리해야한다.

3번째로는 직관적인 변수명이다. 이번 프로젝트에서 리뷰작성부분에서 작성하는 사람을 write라는 변수에 정보를 할당하고 쓰여지는 대상을 target으로 처리를 했다. 그러다보니 코드의 통일성은 있어보이나 후에 이코드를 보았을때 처음부터 하나하나 다씩 해석과 리뷰를 해야하는 일이 생길거 같았다. 따라서 변수명은 그 코드 혹은 함수에서 수행하는 역할보다는 담겨지는 데이터의 특징이나 내용을 따서 변수명을 지으면 유지보수 측면이나 협업측면으로 유용할것으로 생각된다.

이상 4주간의 프로젝트를 마치고 생각한것중 한가지를 끄적여보았다.