[TIL] 220817

FACT

• 게시글 작성 시 음성 파일을 업로드하고, 수정 및 삭제할 수 있는 기능을 구현했다.
• 회원가입 시 이미지 업로드가 안 되는 오류를 해결했다.
• 백엔드 서버를 배포했다.

FEELING

• 와! 기능 구현은 진작 끝냈는데, 배포에 문제가 생겨 프론트 분들을 너무 기다리시게 만들었다.... 통신을 하고 난 뒤에도 수정 작업들이 많을 텐데 죄송한 마음이 들었다.
  그리고 배포.. 해결하고 나니 별거 아닌 문제였지만, 에러 잡는 과정에서는 진짜 고생했다. 제대로 제대로 공부해야겠다.....💥
  그리고 협업할 때 데드라인을 확실히 정해야겠다고 생각했다. 일정 관리를 자체를 잘못한 것 같다.

• 회의록을 작성하자.
  기능을 구현하던 중, 게시글 수정 시 이미지 파일도 같이 수정하기로 했었는지 헷갈렸다. 프로젝트 데드라인 하루 전 날 구체적인 기능에 대해 확신이 없어 고민하다니.. 내가 생각해도 어이가 없다. 그런데 팀원들에게 다시 여쭤보니 모두 대답에 확신이 없었다. 함께 논의하다 흐지부지 끝나버렸나 보다.
  "그때 이렇게 하기로 했었나..?"라며 헷갈릴 일이 없도록 회의록을 작성하여 공유하는 것이 좋을 것 같다고 생각했다.

• 유효성 검사에 대한 부분을 백과 프론트가 정해놓고 프로젝트를 시작하면 좋을 것 같다.
  어제 백에서 전부 예외 처리를 해줘야 한다고 생각해서, 가능한 경우의 수를 모두 고려해서 공통 예외 처리를 했다. 그런데 생각하면 할수록 '이것도 해야 할 것 같고, 저것도 해야 할 것 같은데 기준이 어디까지인가?'라는 고민이 들었다.
  오늘 프론트와 협업 중 알게 되었는데, 프론트에서도 유효성 검사를 하려고 경우의 수를 고민하고 있었다고 한다.
  백에서 쉽게 처리할 수 있는 부분, 프론트에서 쉽게 처리할 수 있는 부분들이 따로 있었는데, 다음 프로젝트부터는 백과 프론트가 쉽게 해결할 수 있는 유효성 부분을 정하고 시작하면 좋을 것 같다.

FINDING

• @RequestPart vs @RequestBody
  다른 팀원 분이 이미지 업로드 기능을 맡으셨는데 서버 에러가 떴었다. 코드를 살펴보니 @RequestBody를 사용하고 있었다. @RequestBody는 데이터 형식을 JSON 형태로 전달받기 때문에, MultipartFile 값을 전달받을 수 없다. 그래서 하나의 API에서 JSON과 파일을 전달받으려면 @RequestPart를 써야 하는 것!

FUTURE ACTION

• 프로젝트 제출하기