항해99 3기

[TIL] 2021.11.13 최종 프로젝트 진행중 - 피드백 받기

na_o 2021. 11. 13. 23:56
728x90

이번 주 피드백은 멘토님들이 실제 면접에서 나올만한 질문을 하시면 답변하는 시간을 가졌다

그 중 백엔드는 아래와 같은 피드백을 받았다

 

  • 쿼리DSL을 써볼 것
    • 레시피와 게시판에서 인기순으로 목록을 조회하는 API가 있다. 레시피 테이블, 레시피 좋아요 테이블, 게시판 테이블, 게시판 좋아요 테이블 따로 분리되어있기 때문에 게시판/레시피 데이터 & 각 게시물마다 좋아요 개수 데이터를 동시에 가져와야 했다. 우리는 JPQL로 JOIN을 이용해 조회해 왔다.
    • 이 경우 데이터 조회하는 속도가 느려질 수도 있기 때문에 쿼리 DSL을 적용하는 것을 추천하셨다.
    • 쿼리DSL을 적용하기 힘들다면, 데이터를 따로따로 조회해서 사용하라고 하셨다.
    • 쿼리가 들어간다면 유지보수하기 힘들다고 하셨다. 왜냐하면 @Query를 사용했는데, 거기에 문자열로 JPQL이 쓰인다. 문자열로 들어가기 때문에 이 쿼리가 정확한 쿼리인지 문법 테스트하기 어렵기 때문이다

 

  • 무중단배포 할것
    • 아키텍쳐를 개선할 예정인지 물어보셨는데, 물어보신 이유가 취업할 때 플러스 요인으로 작용할 거라고 하셨다. 백엔드 개발자도 아키텍쳐를 많이 짠다고 하셨다. 조금 더 특징 있는 아키텍쳐로 만들 필요가 있다고 하신다. 면접 때 어필할만한 요소가 되기 때문이다.
      • 너무 devOps쪽으로 집중이 되는게 아닐런지?
        • 요즘 백엔드 개발자들은 devOps도 한다. 인프라도 알아야 개발 코드도 짤 수 있는 거다. AWS를 해봐라(이 부분이 이해가 안 간다. 이미 AWS 쓴 게 아닌가...)
      • 인프라가 뭐쓰냐에 따라 코드가 달라진다. (서버리스를 쓴다면 코드가 달라지듯이)

 

  • 이미지만 업로드 할 수 있는 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