growing pear

이번 주 피드백은 멘토님들이 실제 면접에서 나올만한 질문을 하시면 답변하는 시간을 가졌다 그 중 백엔드는 아래와 같은 피드백을 받았다 쿼리DSL을 써볼 것 레시피와 게시판에서 인기순으로 목록을 조회하는 API가 있다. 레시피 테이블, 레시피 좋아요 테이블, 게시판 테이블, 게시판 좋아요 테이블 따로 분리되어있기 때문에 게시판/레시피 데이터 & 각 게시물마다 좋아요 개수 데이터를 동시에 가져와야 했다. 우리는 JPQL로 JOIN을 이용해 조회해 왔다. 이 경우 데이터 조회하는 속도가 느려질 수도 있기 때문에 쿼리 DSL을 적용하는 것을 추천하셨다. 쿼리DSL을 적용하기 힘들다면, 데이터를 따로따로 조회해서 사용하라고 하셨다. 쿼리가 들어간다면 유지보수하기 힘들다고 하셨다. 왜냐하면 @Query를 사용했는데..

github에 push 할 때 실수를 했다 그래서 네트워크 그래프가 꼬였다 dev의 최신 코드를 test-board 브랜치에 적용을 안 시켰나보다 팀원이 로컬 브랜치를 최신화하고, push해서 PR을 날렸다 그 PR이 merge가 되었고, 나는 최신화하지 않은 브랜치를 push하고 PR을 날린것 같다 그것을 시간이 좀 지나서야 팀원이 알아챘던 것이다 그래서 푸시 기록을 지우는 등 난리가 났었다 핑계로 들리겠지만 최신화를 신경쓰고 있었기 때문에 pull한 기억이 분명히 있다 그 전에 나는 pull을 잘못 사용하고 있었다 dev브랜치가 아닌 개발하고 있는 다른 브랜치에 가장 최근 코드를 적용해야하는 상황이었다 나는 개발하고 있는 다른 브랜치(test-board)에서 'git pull origin dev'를 ..

코드를 작성하면서 test-board 브랜치에서 게시판 테스트코드를 작성하고 swagger 브랜치에서 swagger와 관련된 코드를 작성했다 test-board에서 swagger로 이동할 때 git stash 명령어로 지금까지 짰던 코드들을 임시저장해놓았다 swager브랜치에서 작업한 뒤 다시 test-board로 이동해야 하기 때문에 또 git stash 명령어를 썼다 test-board로 이동 후 이전에 임시저장해놓았던 것을 불러와야 했다 어떻게 불러오는 지 몰라서 검색해봤다 https://helloinyong.tistory.com/202 [2019.09.13] git stash 사용법 - 현재 상태를 저장해보자 최근에 A브랜치에서 작업을 완료 후 pull Request를 올렸다. 그리고 새로운 기능..

내가 만든 API를 프론트와 통신하는 과정을 겪었다 분명히 postman으로 테스트할 때는 문제 없이 response가 잘 왔는데 프론트에서 request하면 400에러나 500에러가 났었다 위의 형식으로 request를 해야했다 프론트의 코드를 수정하면서 계속 원인을 찾아보았다 우리가 알아낸 결과다 1. postman에서도 봤다 싶이 form-data로 request해야 한다 - title, content, image 모두 React의 formData 객체에 담겨 있어야 하고, key: value 형식으로 담겨 있어야 한다 const recipeFormData = new FormData(); recipeFormData.append("title", title); recipeFormData.append("..

어제 push한 커밋 내용들이 꼬여서 커밋 로그를 정리했다 아래 그림은 정상적인 그림이다 각자 브랜치를 파서 push 하면서 계속 개발 하고, 일주일에 한번 코드리뷰를 한 다음 dev 브랜치에 합쳤다 합친 뒤 또 각자 브랜치에서 개발하고, 머지 후 첫 push하면 커밋 기록이 dev에서 뻗어나가야 한다 하지만 나는 dev에서 뻗어나간게 아니고 내가 만든 브랜치에서 뻗어나가는 것이였다 그래서 커밋해온 기록들을 머지한 직후로 되돌려놨다 # 커밋 기록을 간단하게 보기 git log --oneline db7a3dd (HEAD -> board) feat: 댓글 좋아요/취소 기능 추가 6e16d7e feat: 댓글 삭제 기능 추가 be3221d feat: 댓글 조회 기능 추가 c94e256 update: Board..

현재 MultiPartFile을 이용한 게시물 수정 시 이미지 변경 로직을 짜고 있다 S3에 업로드하는 메소드에서 'MultipartFile -> File convert fail' 이라는 것이 떴다 이 부분에서 에러가 난다 요청은 아래 사진처럼 했다 수정하는 이미지의 위치를 맞춰주기 위해 imageUrl과 image에서 아무것도 입력 안한 것이 있다 게시물 작성 때 사진을 2개 올리고, 두번째 위치에 있는 사진을 수정하려고 한다 그래서 두번째 위치에 있던 기존 이미지 URL은 빈칸으로 두고, image의 두번째 위치에 새로 올린 이미지파일을 첨부해줬다(춘식3.png) 첫번째 사진은 수정을 안할거기 때문에 첫번째 imageUrl에 기존 이미지 링크를 적어뒀고, 첫번째 image는 빈칸으로 두었다 디버그를 ..

나는 너무 앞만 보고 달리는 것 같다 개발을 진행하면서 현재 코드의 불편한 점을 알아채고 개선할 방법을 찾아야되는데 불편한대로 쓰고 있다 좋지 않은 방법인것 같다 프로젝트의 목적은 취업인데 면접 때 질문이 들어왔을 때 대답할 것들이 있어야 한다 내가 말할 거리를 만들어내야 한다 시야를 넓히자 이미지 파일을 포함해서 게시물을 수정하는 로직에서 값을 못 받아온다 평소 값을 받는 대로 @Getter, @NoArgsConstructor, @AllArgsConstructor를 사용했다 이것이 문제가 되는 것 같다 @Data로 바꾸고 다시 실행했더니 정상적으로 작동한다 하지만 @Data는 @Getter, @Setter, @ToString, @EqualsANdHashCode, @RequiredArgsConstruct..

* 최종 화면이 나왔으면 좋겠다 오늘 대표님의 피드백을 듣고 또 기능을 줄여야 했다 저번주 피드백때도 난잡하다는 이야기를 듣고 결국 주제를 아예 다른 것으로 바꿨다 DB설계까지 하고 테이블을 만들어둔 상태인데 주제가 아예 바뀌어버리니 조금은 힘들었지만 괜찮았다 하지만 이번엔 아니다 주제가 바뀌진 않고 기능이 줄었지만, 일단 내가 개발하고 있던 부분이 통째로 빠졌다 매일매일 화면/기능 정의 때문에 하루종일 머리 굴리고, 결정 해둔 내용을 또 고민해서 바꾸고, 디자이너분들이 새벽에 들어오시면 그때 또 바뀌고, 바뀌고...바뀌고.....바뀌고............ 이 과정을 1주 반 째 반복하고 있다 이젠 현재 우리가 정한 주제가 잘 정한 건지도 의문이 든다 팀 내부의 문제도 있었고, 화면/기능도 실시간으로 ..

오늘 들었던 생각이다 프로젝트를 진행을 할 때는 각자의 의견을 말하면서 가장 좋은 방법을 찾아나가는 것이라고 생각을 한다 팀원들이 의견을 최대한 말해주는 것이 중요하다고 생각한다 의견을 말할 때 팀원들의 기분이 상하지 않았으면 좋겠다 팀원이 의견을 말했는데 다른 더 좋은 의견이 있어 그것이 반영 되었을 때 기분 나빠하지 않았으면 한다 가장 좋은 방향을 팀원들과 다같이 선택을 해서 프로젝트의 길을 만들어나가는 것인데 자신의 의견이 반영되지 않을 수도 있는 것이다 백엔드 팀원분께서 위에 적은 내용처럼 자주 그러시는것 같아 매니저님과 상담을 하셨다 그 팀원분을 제외한 나머지 팀원들은 위의 내용처럼 그런 상황이 느껴질 때마다 이 사태를 어떻게 해야할까 하면서 얘기를 해왔다 우리 다섯명의 결론은 매니저님의 도움을..

* API 설계 때 정한 규칙을 왜 안 지키고 대충 넘어가려고 하는걸까...? * 코드 리뷰 하자 해놓고 잘 듣고 계시더니 왜 갑자기 나중에 하자고 하신걸까...? * 인프런 알고리즘 강의 중 1단원 시험 - https://github.com/NayoungBae/oneday-onesolve/blob/nayoung/java-algorithm/10-29%20Test.md GitHub - NayoungBae/oneday-onesolve: JAVA로 푸는 알고리즘 1일 1문제 JAVA로 푸는 알고리즘 1일 1문제. Contribute to NayoungBae/oneday-onesolve development by creating an account on GitHub. github.com 오늘은 큰 어려움은 없었..