이번 주 피드백은 멘토님들이 실제 면접에서 나올만한 질문을 하시면 답변하는 시간을 가졌다
그 중 백엔드는 아래와 같은 피드백을 받았다
- 쿼리DSL을 써볼 것
- 레시피와 게시판에서 인기순으로 목록을 조회하는 API가 있다. 레시피 테이블, 레시피 좋아요 테이블, 게시판 테이블, 게시판 좋아요 테이블 따로 분리되어있기 때문에 게시판/레시피 데이터 & 각 게시물마다 좋아요 개수 데이터를 동시에 가져와야 했다. 우리는 JPQL로 JOIN을 이용해 조회해 왔다.
- 이 경우 데이터 조회하는 속도가 느려질 수도 있기 때문에 쿼리 DSL을 적용하는 것을 추천하셨다.
- 쿼리DSL을 적용하기 힘들다면, 데이터를 따로따로 조회해서 사용하라고 하셨다.
- 쿼리가 들어간다면 유지보수하기 힘들다고 하셨다. 왜냐하면 @Query를 사용했는데, 거기에 문자열로 JPQL이 쓰인다. 문자열로 들어가기 때문에 이 쿼리가 정확한 쿼리인지 문법 테스트하기 어렵기 때문이다
- 무중단배포 할것
- 아키텍쳐를 개선할 예정인지 물어보셨는데, 물어보신 이유가 취업할 때 플러스 요인으로 작용할 거라고 하셨다. 백엔드 개발자도 아키텍쳐를 많이 짠다고 하셨다. 조금 더 특징 있는 아키텍쳐로 만들 필요가 있다고 하신다. 면접 때 어필할만한 요소가 되기 때문이다.
- 너무 devOps쪽으로 집중이 되는게 아닐런지?
- 요즘 백엔드 개발자들은 devOps도 한다. 인프라도 알아야 개발 코드도 짤 수 있는 거다. AWS를 해봐라(이 부분이 이해가 안 간다. 이미 AWS 쓴 게 아닌가...)
- 인프라가 뭐쓰냐에 따라 코드가 달라진다. (서버리스를 쓴다면 코드가 달라지듯이)
- 너무 devOps쪽으로 집중이 되는게 아닐런지?
- 아키텍쳐를 개선할 예정인지 물어보셨는데, 물어보신 이유가 취업할 때 플러스 요인으로 작용할 거라고 하셨다. 백엔드 개발자도 아키텍쳐를 많이 짠다고 하셨다. 조금 더 특징 있는 아키텍쳐로 만들 필요가 있다고 하신다. 면접 때 어필할만한 요소가 되기 때문이다.
- 이미지만 업로드 할 수 있는 API를 독립적으로 만들고 서버에서 토큰값을 받아 로직을 처리한다면 좀 더 빠른 속도로 성능 개선할 수 있을 것 같다
- 게시물/레시피 목록을 보여줄 때 썸네일을 써서 네트워크 렌더링을 좀 더 빠른 속도로 개선할 수 있다
발표할 때 가장 아쉬운 점은
발표 시간을 5분으로 맞춰서 하라고 했는데, 다른 조들은 10분, 15분씩이나 했었다
우리는 너무 하라는 대로 말을 잘 들었다
그러다 보니 함축해서 발표해야 되기 때문에 주요 기능 중점으로 말하고 좀 부수적이다라는 것들은 발표 내용에서 다 빼버렸다
그 결과는 피드백이 적었다. 다른 조들은 멘토님들이 여러가지 물어보시고 피드백도 많이 받았지만, 우리는 다른 조들보다 적었다
최소 우리가 만든 화면 모두 캡쳐해서 보여줄걸 이라는 생각이 들었다
보여주기만이라도 해도 피드백이 한 마디라도 더 늘었을 텐데..
갈피를 못 잡고, 우리가 과연 잘 하고 있는걸까, 코드를 올바르게 짜고 있는걸까 라는 생각은 항상 드는데 발표 때 드러내지 못해 아쉬웠다
피드백이 많은 게 중요한데..!
게시물/레시피 수정 로직이 또 바뀌었다
가장 최초로 내가 짠 코드에서 다른 방식으로 다시 짜고, 이번에 또 다시 짜야하는 상황이 왔다
이것이 초반에 프론트와 많은 소통을 하지 못해서일까, 라는 생각이 문득 든다
초반에 프론트분들도 개발을 시작한게 아니라서 예상을 못한 것 같다
프론트에서 여러 장의 사진을 선택할 때 한꺼번에 다중 선택 후 첨부해야 했다
이것을 프로젝트를 시작 직후에는 모를만도 하다(개발을 시작한 것이 아닌 기획 단계였기 때문에)
결국 나는 게시물 수정 API를 세 가지 방식으로 짠 셈인 것이다
1. 사진의 위치를 고려하면서 개발하기
2. 사진의 위치를 고려하지 않으면서 기존의 사진을 모두 다 삭제하고 새롭게 올리는 방식으로 개발하기
3. 사진의 위치를 고려하지 않으면서 어떤 사진을 삭제해야 하는 지 알고 있는 상태에서 개발하기
[사진의 위치를 고려하지 않으면서 어떤 사진을 삭제해야 하는 지 알고 있는 상태에서 개발하기]
프론트에서 삭제해야 하는 이미지 URL을 request해줄 수 있다고 한다
삭제해야하는 이미지 URL을 배열로 받아 그 배열에 이미지 URL이 담겨있으면
DB와 S3에서 삭제하는 방식으로 바꾸기로 했다
이 방법이 우리 상황에서 가장 적합한것 같다
프론트에서 어떤 위치에 있는 사진을 삭제/수정할 것인지 알 수 없다고 한다
그럼 3번 방법이 맞다고 생각한다
사실 아주 살짝 허무하다
사실대로 말하자면, 1번 로직 완성하는데 하루 17~19시간을 투자했다
여러가지 경우의 수를 생각해야했기 때문이다
열심히 짠 로직인데 적용하지 못해서 아쉽다
1번 로직은 아래에 적혀있다
https://nazero.tistory.com/122
[TIL] 2021.11.03 최종 프로젝트 진행중
나는 너무 앞만 보고 달리는 것 같다 개발을 진행하면서 현재 코드의 불편한 점을 알아채고 개선할 방법을 찾아야되는데 불편한대로 쓰고 있다 좋지 않은 방법인것 같다 프로젝트의 목적은 취
nazero.tistory.com
잔디 안 심어진거 이젠 제대로 심자
https://wellbell.tistory.com/43
github 잔디밭 안 심어지는 현상 해결 및 이미 커밋한 내용 반영하기
1. github 잔디 안심어지는 현상 해결 흔히 잔디밭이라고 불리는 github contributions(activity) 나의 저장소 중 어디라도 commit해서 push해서 반영 시키면 잔디가 심어져야하는데 심어지지 않을때가 있다.
wellbell.tistory.com
'항해99 3기' 카테고리의 다른 글
[TIL] 2021.11.16 최종 프로젝트 진행중 - nGrinder 실행 (0) | 2021.11.16 |
---|---|
[TIL] 2021.11.15 최종 프로젝트 진행중 - 게시물 수정 로직 변경 / nGrinder 준비 (0) | 2021.11.15 |
[TIL] 2021.11.11 최종 프로젝트 진행중 - 브랜치 다루는 방법 (0) | 2021.11.13 |
[TIL] 2021.11.10 최종 프로젝트 진행중 (0) | 2021.11.10 |
[TIL] 2021.11.09 최종 프로젝트 진행중 (0) | 2021.11.09 |