여름 방학에 시작했던 프로젝트가 드디어 끝났다. 하다보니 점점 욕심이 생겨 생각보다 규모가 커져서 예상 시간보다 더 길게 작업했다. 프로젝트가 끝난 기념으로 이 프로젝트의 기능과 문제점 그리고 깨달은점에 대해 얘기하겠다.
기능 설계도
(위의 UML을 참고해주세요.)로그인, 프로필 편집, 카테고리 검색 기능 등등 많은 서브 기능들이 있지만 큰 범주로 나누고 싶었다. 우리 프로젝트의 흐름에 대해 간단히 소개하겠다.
- 프로젝트 소개글 작성 및 게시
- 내가 생각한 프로젝트에 대한 소개글(홍보글)을 작성하고 게시한다.
- 게시한 사람의 프로젝트의 리더가 된다.
- 프로젝트 신청
- 개발자는 참여하고 싶은 프로젝트를 검색하고 신청한다.
- 신청자와 소통
- 프로젝트에 신청이 들어오면 리더는 신청자와 채팅으로 대화를 한다.
- 대화를 통해 신청을 수락 혹은 거절한다.
이런 흐름으로 설계했다.
문제점
프로젝트가 끝나갈수록 문제점들이 굉장히 많이 보였다. 중간 결산때 언급했던 문제점을 포함해서 나열하겠다.- thymeleaf의 한계 + 프론트엔드의 역할
- 처음 시작을 thymeleaf로 했는데 학교에서나 강의에서나 thymeleaf를 사용해서 thymeleaf로 개발하는게 당연한줄 알았다. 프론트를 맡은 친구도 프론트에 대해 잘 몰라서 거의 디자인만 맡게 됐고, 자연스럽게 thymeleaf + 프론트의 부재로 내가 풀스텍 개발을 했다.
- 이런 작업이 당연한줄 알았지만 api 테스트에 대해 알아가고 프론트의 역할에 대해 알아가다 보니 뒤늦게 잘못된 걸 깨달았다.
- 프론트와 백의 정확힌 역할 구분과 개발 방법에 대해 빨리 알았더라면 더 편하게 개발했을거라는 아쉬움이 남는다.
- 혹시나 이 글을 보는 백엔드 입문자는 thymeleaf는 어디까지나 백엔드의 간단한 테스트 용이라는 것을 명심하고 볼륨이 커진다면 리엑트로 따로 빼는 것을 추천한다.
- api 명세의 부제
"그래서 로그인에는 뭘 보내줘야 됐더라?"
- 중간 결산에서도 이 문제를 언급했었는데, api에 대한 정확한 명세를 하지 않아서 자꾸만 수정사항이 생겼다.
- 예를 들면 회원 객체는 아이디, 이름, 나이로 구성되어 있는데 다른 게 추가되는 등...
- 디자인의 한계
- 프론트를 맡은 친구가 디자인을 모두 html + css로만 하다 보니 자유로운 디자인에 한계가 있었고 다소 깔끔하지 않은 느낌이 강했다.
- 벽돌집이 아니라 초가집이 된 느낌이랄까..?
- 개발 하면서 디자인 분야가 정말 귀하고 재능의 영역인 것 같다.
- DTO 활용
"당신의 집 주소만 필요하지 이름, 나이는 필요없어요"
- 강의에서 dto를 배웠었는데 개발 초반에는 정확히 왜 쓰는지 이해가 잘 가지 않아 쓰지 않았다. 개발을 하다 보니 객체를 api에 맞게 최적화 해야 좋다는 것을 느끼게 됐지만 이미 dto를 제대로 쓰지 않은 api가 너무 많아 쓰지 않은 채로 개발을 진행했다.
- dto를 쓰지 않으니 api에서 받지 않은 객체의 요소가 뭔지 명확해지지 않아 null 문제가 자주 발생했다.
ex) 로그인은 회원의 아이디, 비밀번호만 받기 때문에 나머지 속성은 다 null인데 여기서 받은 member 객체가 다른 api 혹은 서비스에서 활용이 되는 위험
- 에러 처리
- try catch를 많이 활용해서 에러 처리를 확실히 했으면 좋았겠다는 아쉬움이 남는다.
- 네이밍
"member_Login_Security_accessToken_Repository........"
- 객체, api, 서비스 모든 것에 해당되는 문제였다.
- member의 이름은 name이라고 할 지 username이라고 할 지...
- 로그인 회원가입을 하나로 묶어야 할 지, 하나로 묶자 하니 이름이 애매해지고 관련이 적은 기능이 묶여있는 느낌이 들었다.
- 분리하자 하니 너무 class가 많아지고 복잡해는 것 같았다.
- 이 부분은 정답이 없는 것 같아 전문적인 프로젝트의 설계를 참고하고 싶다.
깨달은점
- 협업 하고 싶으면 일단 서버를 열어
- 프론트와 협업하려면 api를 테스트 해야 하는데 프론트가 절대 혼자 할 수 없다. 그렇다고 할 때 마다 나한테 테스트 해달라고 할 수도 없다.
- api는 명세는 swagger로
- swagger라고 depedency에 추가해서 쓸 수 있는 아주 좋은 명세기능이 있다. 서버를 열고 프론트에게 주소를 알려주면 프론트가 url/swagger-ui/index.html 로 접속하면 api명세 및 테스트를 쉽게 할 수 있다.
- 몰랐으면 당장 써봐라 신세계다.
- postman으로 api 테스트
- swagger로 테스트해도 되지만 한 api에 대해서만 테스트 할거면 postman이 편했다.
- 특히 jwt를 테스트 할 때 token 때문에 아주 편하다.
- query문 공부
- sql문에 대한 기초를 이해하는 것을 넘어서 복잡한 query문을 작성할 일이 생긴하면 객체의 연관관계 매핑을 잘 이해하고 그것의 table이 어떻게 연결되어 있는지 이해하는 과정이 필요하다.
- 이것을 잘 알지 못하면 query문을 작성할 때 고생한다.
- thymeleaf는 간단한 작업에만...
- thymeleaf만 쓰다 보니 테스트를 제대로 하지 못했다.
- api의 리턴이 죄다 html이다 보니 테스트 코드를 따로 만들어도 복잡한 api이면 굉장히 애매해진다.
백엔드 개발자