스프링 느낀점 - 2023.03.07. 작성

옛날에 메모했던 걸 보며 내용을 바로잡기 위해 블로그에 기록해둡니다. (23년 3월 메모)

날짜표시가 따로 없는 건 과거의 메모니까, 틀린 내용이 다수 포함될 수 있음.

 

성공/실패 메세지

>> 성공, 실패 여부에 대한 메세지를 항상 같이 넘겨주는 것이 무조건 좋다고 생각이 된다. 그래야 postman으로 검사할 때도 편하고 어디서 뭐때문에 실패했는지 내가 직접 넘겨줄 수 있기 때문에 훨씬 편하다.

→ print로 찍을 수도 있는데, log.info로 로그를 남겨주는 것이 더 좋은듯하다.

 

API 명세서

>> api 명세서는 거의 무조건 postman으로 관리하는 게 맞다. notion에 관리를 같이 해도 되는데, 노션은 사용해도 되고 안해도 된다면 postman은 무조건 해야하는 것 같다 그래야 기능확인하기도 편하고.

→ 노션말고 postman이라는 소리지, postman 말고도 스웨거 등의 tool을 이용하는 것이 좋아보인다. 24.05.09.

 

ResponseEntity<>로 return

>> controller는 웬만하면 ResponseEntity<>를 통해서 반환하는것이 상태코드도 정할 수 있고, 통일성도 있고, 보기 편하기에 좋다.
▶ Controller가 FE랑 연결돼있는 부분이고
  Service가 컨트롤러에서 원하는 기능을 구현하는 부분
  Repository가 DB랑 연결되는 부분

 

나의 생각

>> 설계하는게 진짜 중요한듯... 어떤식으로 로직을 구상할지 전체적인 틀을 먼저 생각하고 개발하자. 설계를 제대로 안하고 시작하면 코드도 엄청 꼬이고 난잡하고 좋지 않은 퀄리티가 나오는 것 같다.

오후 8:18 2023-08-06(일)
설계하는 게 진짜로 중요하다 ... 비즈니스 로직을 설계하고, ERD를 설계하는 것이 개발을 더 쉽고 편하게 만들어준다.

 

>> 백에서 기능테스트를 성공해도, 프론트에서 실패할 수 있다. 왜냐하면 프론트에서 요구하는 정보를 백에서 빠뜨린 경우도 많기 때문이다. 프론트에서 A B C를 달라고 코드를 썼는데 백에서 A B만 줬으면 C를 안줬으므로 에러가 뜬다. 이런식으로 백에서 기능을 확인했어도 에러가 나는 경우가 많아서, 백에서 코드 다썼다고 해도 마냥 다한것은 아니다.

 

>> 프론트와 협업하는 측면에서, 백엔드의 역할은 "정보를 준다" 인것 같다. 정보를 줘야하므로 부가적인 기능들이 붙는 것이다. 정보를 줘야하니까 어디 저장을 시켜놔야 하는 것이라 Repository단을 만드는 것처럼.

 

>> 프론트와 백을 연결할 때 생기는 오류중에, CORS오류나 진짜 로직실수에서 나오는 오류 말고는 보통 바로 위에서 언급한 것처럼 줘야할 정보를 안줘서 생기는 오류였던 것 같다.

 

>> 어떤 툴을, 어떤 라이브러리를 사용하는지도 중요하다. 찾아보면 쉬운 길이 나오는 경우가 많아서 그렇다.

>> domain은 엔티티고, dto는 domain에서 추출한거(데이터 전송 객체 data transfer object) domain을 직접 다루면 domain에 있는 모든 걸 가져와야해서 낭비도 좀 있고 다루면 안되는 민감한 정보도 있고 그리고 @notblank같은 거를 엔티티에 추가할 수 없으니까 domain의 내용들 중 필요한 것들만 뽑아서 dto에 모아놓은거
→ dto는 데이터를 전달하는 객체이기 때문에 별다른 로직을 갖지 않는 반면에 Domain은 핵심 비지니스 로직을 담는 영역이기 때문에 그에 맞는 비지니스 로직을 가질 수 있다.