2024.07.11 백엔드 논의 좀 할게요

논의한 내용

default method를 사용해서 findById() 예외 처리까지 해주자

서비스에서 예외 처리 하자

• default 메서드의 쓰임이 잘못됬다.
• 예외처리해주는 것도 로직이라 생각해서 레파지토리보다 서비스가 맞다고 생각했다.
  • 하지만 getById(), getReferenceById() 도 레퍼지토리에 메서드인데 예외처리를 해준다.

레파지토리에서 예외 처리 하자 ❤️

• 레파지토리가 하나의 서비스하고만 연결되는 것은 아니니, 코드 중복 제거 차원에서 레파지토리에서 예외처리 하자

finder 클래스를 만든다

• 단점: 서비스가 finder와 레파지토리에 다 의존한다.
• 예외처리를 default method 사용하지 않고 간단하게 쓸 수 있다.

getById() 이름을 그대로 쓸까?

1. getById()

• 단점 : deprecated된 메서드 네이밍이다

2. fetchById() ❤️

• 예외를 터트린다 까지 이야기하는 네이밍이라고 생각한다

representative_snippet 네이밍 변경

• thumbnail_snippet ❤️
• head_snippet

global 패키지 내 패키지 분리

global 패키지에서 쓰임에 따라 분리 ❤️

• 파일의 “쓰임”을 이름을 읽지 않아도 빠르게 판단할 수 있다

global 패키지에서 계층에 따라 분리

---

With FE

확장자를 입력 안 했을 경우, 확장자 처리 방법

파일 명을 ‘ddd’ 로 했을 경우

1. 확장자 - ‘.text’ (로 text로 처리할 것인가?)
2. 확장자 - ‘ ‘

1. .text로 설정

2. 빈 문자열을 확장자로

3. 걍 없앨까? ❤️

확장자랑 언어를 DB에 저장할 것인가?

확장자랑 언어를 지금부터 저장하는 게 맞다

• .js .jsx 를 javascript로 연결하는 것을 프론트 단으로 두면 후에 단순 데이터 추가 시에도 코드 변경이 생긴다
  • 확장자와 언어를 연결해주는 것도 데이터라고 생각한다
  • 단점: 비용 문제, 네트워크 문제 발생 가능
• 코드의 기본 데이터라고 생각
• 프론트에서 생성 시 언어를 파싱하는데, 굳이 한번 더 중복과정을 가져야 하는가

확장자랑 언어는 지금 저장하지 말자. 굳이?

• 너무 멀리 있는 데이터를 미리 생각하는 것 같다
• 확장자랑 언어를 데이터라고 생각하지도 않는다 → 그러니 굳이 DB에 저장하지 않아도 되는 것을 왜 DB를 이용하는 것인가? (비용 측면)
  • 사용자 100명이 각자 하는 것이 더 좋다고 생각한다

결정 해보자 → 스니펫에 언어, 확장자 다 넣지 말자 ❤️

1. 스니펫에 언어, 확장자 다 넣지 말자 ❤️

   • member → no
   • language → no
   • extension → no
   • snnipet
     • order → yes

2. 스니펫에 언어만 String으로 넣자 (확장자는 없다)

3. 스니펫에 언어를 테이블로 분리하자 (확장자는 언어에 넣는다)

API 명세를 카멜 케이스로. (땅땅땅)

변경 후 프론트에게 전달