깃은 2주 프로젝트 때보다는 이해를 못한 상태에서 쓰는 일이 많이 줄어들었다. 2주 프로젝트 끝나고 워크플로우가 어떻게 되는 건지, 실제 프로젝트에서는 어떻게 적용되는 건지 많이 공부해두길 정말 잘 했던 것 같다. 2주 프로젝트에서 아쉬움이 너무 컸었기 때문이었던 거 같다.
물론 커밋메세지 합친다는거나 하는 건,,, 좀 더 익숙해져야 할 부분이긴 하다.
프론트엔드를 2주 프로젝트에서 맡았을 때는 깃 빼고는 협업에 있어 크게 어려움을 느끼지는 못했다. 백엔드에서 마이그레이션 파일을 깃에 올려야 하나 말아야 하나, 아니면 둘 다 만들고 각자 로컬에만 가지고 있어야 하나 하는 고민을 많이 했고, 이부분은 어떻게 처리해야 할지 아직 공부가 더 필요한것같다
그리고 제일제일 불편했던건 백엔드 팀원은 2명인데, 내 EC2를 실제 배포에 쓰고, 이를 공유하는 방법을 모르다 보니, 매번 페어분이 나에게 EC2 로그를 공유해달라고 요청하는 일이 잦아졌고, 결국에는 팀원들과 만나 테스트를 진행할 때, 문제의 원인을 나 혼자 먼저 파악할 수 밖에 없어 어려운 점이 있었다. 이를 해결하려고 AMI 이미지 공유하는 법을 찾아보고 이미지 공유까지 했지만, 그 이후의 EC2 로그 공유하는 방법을 잘 몰라서 실패했다.,,아무래도 이 방법이 아니었던건가,, 작업 초반부에 IAM 정책에 대해 좀 더 알아볼 시간이 있었다면, 이걸 공부해보고 좀 더 편하게 협업을 할 수 있었을 것 같기도..하다
그리고 기술적인 부분에서 어려웠던 점
[데이터베이스]: 공부가 많이 필요했다..내가 생각하기엔 쿼리문으로 서버 성능이 결정되는 것도 굉장히 큰거같다.
시퀄라이즈에서 일대다 관계설정은 괜찮았는데, 여러 개의 테이블을 조인하고, 다대다 관계 설정을 하여 데이터를 추출하는 과정이 어려웠다.
특히 여러가지 정보를 담아 줄 때 테이블 조인이 필요한 상황이 있었는데, 그게 안 되는 경우도 있다보니 promise.all을 써서 처리를 많이 했었다. 그게 정말 최선인가,, 잘 찾아보면 하나의 시퀄라이즈문으로 해결할 수 있는 방법이 있을텐데 그게 좀 잘 안되서 아쉽다
그냥 mysql을 썼더라면 이런 문제는 덜 했을 거라고 생각하는데..
처음 보는 문법이 많고, 공식문서에도 (자세히 보지 않아서 하는 소리일수도 있는데) 정말 기본적인 테이블 조인 방법에 대해서만 설명하고 있어 실제 다른 사람들이 작성한 예시를 검색해가며 겨우 만든 코드를 만들어갔다,, 그걸 실행시켜가며 터미널에 찍히는 쿼리문이 내가 원하는 쿼리문이 맞는지를 하나하나 확인하는 게 쉬운일은 아니었다. 진짜 공부 제대로 해야지 해야지 했는데 바쁘단 핑계로 제대로 못했다. :
특히나 좀 힘들었던게 초기 세팅이었다. force 옵션은 어떻게 작동하는건지, 마이그레이션과 테이블 히스토리 관리는 어떻게 해야하는지, 정확하게 알지 못한 상태에서 코드를 짜고, 페어분과 깃으로 공유하다보니 자잘한 에러들이 자주 생겼고, 그걸 해결하는 과정에서 시간 낭비가 많아 아쉬웠다.
아쉬웠던 게 마이페이지에서 좋아요한 게시물을 좋아요 시간 순서대로 보여주고 싶었는데, 테이블 관계 설정에서 잘못된건지 여러 가지 방법을 다 써봐도 계속 association 에러가 나왔다. 결국에는 진짜 원하지 않던, reverse()를 써서 어거지로 구현했는데..마음에 들진 않는다. 아무래도 초기 세팅에서 무언가가 잘못된 것 같은데.. 나중에 이건 따로 파일을 만들어서라도 다시 구현해봐야겠다.
그리고 시퀄라이즈에서 like 데이터를 가지고 올때, 테이블에 차라리 totallike를 넣는게 더 나았을 수 있겠단 생각을 했다. 직접 like 개수를 합산하다 보니, 결국에는 원하지 않던 literal을 사용했다. 애초에 테이블에 칼럼을 따로 만들었다면 좀 더 쉽게 작성을 했을 텐데.
뭔가, DB 테이블 설계 원칙에 대해 알고 있는게 많이 없다보니, 테이블을 작성하면서 많이 부족함을 느꼈다. null 칼럼을 많이 둬도 되는건지. 칼럼 갯수는 적을수록 좋은건지, 어떤 상황에서는 어떻게 테이블을 짜야 좀 더 효율적인지 좀 더 알아봐야한다.
[AWS와 https 배포, 쿠키설정]
이번 프로젝트를 하면서 쿠키에 대해 오히려 더 공부를 많이 한것같다. 섹션 3때는 쿠키 옵션에 대해 아 그렇구나 하고 대강 이해하고 넘어갔었는데 프로젝트에서 옵션 설정을 하며 왜 안되는거지 하며 찾다 보니 쿠키 옵션 설정을 하나하나 공부하게 됐다. 제일 헷갈리던 부분이 도메인이랑, path 속성이었다. 클라이언트 쪽 주소로 설정해줘야 하는건지, 서버쪽 주소로 설정해줘야 하는건지를 잘 몰라서 너무 헤메고 있었는데, 다른 사람들의 질문답변, 블로그 글을 본 게 큰 도움이 됐다. 특히 로그아웃이랑 회원탈퇴 때 쿠키가 제대로 안 사라져서 애먹었는데,, 그때도 그 글을 봤던 게 기억나서 해결했었다.
S3, RDS, EC2가 어떤 경우에 쓰는 서비스인지는 알겠는데, 구체적인 옵션 설정에 관해서는 이론이 부족하다보니 초기 배포가 어려웠다.
특히 HTTPS는 블로그 게시물들을 보고 배포를 따라하려 했는데 UI가 달라졌다보니, 항목들이 다 흩어져 있어 초기에 옵션 위치를 찾는다고 시간을 많이 써버렸다. 로드 밸런서 설정에 대해서도 블로그 글을 보고 따라하고, route53 도메인도 그랬다. UI도 달라진데다 이론적으로 알고 있는게 그리 많지 않은 상태에서 배포 진행을 하다보니 이렇게 하는 게 맞는건가 하는 의구심도 많이 들었다. 그래서 배포는 더더욱이나 기록으로 많이 남겨야겠구나 생각했다.
[팀장으로서의 역할]
업무분배?,,이런 부분에서 잘 한건진 잘 모르겠다..
초반부에는 회의 전 내용을 미리 잘 정리하지 못해 공백 시간이 너무 길어지고, 어려운 문제에 대해서는 어쩔 줄 몰라 회의를 너무 길게 끌었는데, 후반부엔 어떻게 대처해야 할지 좀 감이 잡혀서 시간이 지나치게 길어지는 걸 어느 정도 막을 수 있었던 거 같다.
그리고 이번 한달동안 제일 어려웠던 건, 주어진 태스크를 해내는데 얼마나 시간이 걸릴지 예측하는 것이었다.
특히 채팅기능이나, 이미지 업로드나, 이메일 인증, 등등 이전에 배워본적이 없었던 걸 프로젝트에 적용하려고 하니, 얼마나 시간이 걸릴지를 예측하기가 힘들었다. 이를 계산해서 팀원들에게 얼마나 걸릴거같다고 예상되는 일정을 내놓아야 하는데, 그게 어려웠던 거 같다.
이런 상황에서는 대략 예상일정을 며칠 걸릴거같다고 대강의 일정을 얘기하고, 꼭 중간중간 어디까지 진행되었는지 공유하는 게 최선이지 않을까 생각한다.
체력관리도,,,잘 못한거같다.많이 피곤한 상태에서 기능구현을 하다보니 이메일 인증기능 구현에서 자꾸 수정사항이 생겼고, 멍해지는 시간이 많아지면서 몇일 만에 끝낼 수 있는걸 4일 넘게 끌었던 것 같다. ㅠㅠ 일찍 자고 차라리 일찍 일어나서 해야겠다.
그냥 자유로운 형식으로 적어볼게요..
음..전반적으로 백엔드 쪽에서는 협업과 관련해서 아쉬운 부분이 참 많았다.
그리고 기술적인 부분에서 어려웠던 점 [데이터베이스]: 공부가 많이 필요했다..내가 생각하기엔 쿼리문으로 서버 성능이 결정되는 것도 굉장히 큰거같다. 시퀄라이즈에서 일대다 관계설정은 괜찮았는데, 여러 개의 테이블을 조인하고, 다대다 관계 설정을 하여 데이터를 추출하는 과정이 어려웠다. 특히 여러가지 정보를 담아 줄 때 테이블 조인이 필요한 상황이 있었는데, 그게 안 되는 경우도 있다보니 promise.all을 써서 처리를 많이 했었다. 그게 정말 최선인가,, 잘 찾아보면 하나의 시퀄라이즈문으로 해결할 수 있는 방법이 있을텐데 그게 좀 잘 안되서 아쉽다 그냥 mysql을 썼더라면 이런 문제는 덜 했을 거라고 생각하는데.. 처음 보는 문법이 많고, 공식문서에도 (자세히 보지 않아서 하는 소리일수도 있는데) 정말 기본적인 테이블 조인 방법에 대해서만 설명하고 있어 실제 다른 사람들이 작성한 예시를 검색해가며 겨우 만든 코드를 만들어갔다,, 그걸 실행시켜가며 터미널에 찍히는 쿼리문이 내가 원하는 쿼리문이 맞는지를 하나하나 확인하는 게 쉬운일은 아니었다. 진짜 공부 제대로 해야지 해야지 했는데 바쁘단 핑계로 제대로 못했다. : 특히나 좀 힘들었던게 초기 세팅이었다. force 옵션은 어떻게 작동하는건지, 마이그레이션과 테이블 히스토리 관리는 어떻게 해야하는지, 정확하게 알지 못한 상태에서 코드를 짜고, 페어분과 깃으로 공유하다보니 자잘한 에러들이 자주 생겼고, 그걸 해결하는 과정에서 시간 낭비가 많아 아쉬웠다. 아쉬웠던 게 마이페이지에서 좋아요한 게시물을 좋아요 시간 순서대로 보여주고 싶었는데, 테이블 관계 설정에서 잘못된건지 여러 가지 방법을 다 써봐도 계속 association 에러가 나왔다. 결국에는 진짜 원하지 않던, reverse()를 써서 어거지로 구현했는데..마음에 들진 않는다. 아무래도 초기 세팅에서 무언가가 잘못된 것 같은데.. 나중에 이건 따로 파일을 만들어서라도 다시 구현해봐야겠다. 그리고 시퀄라이즈에서 like 데이터를 가지고 올때, 테이블에 차라리 totallike를 넣는게 더 나았을 수 있겠단 생각을 했다. 직접 like 개수를 합산하다 보니, 결국에는 원하지 않던 literal을 사용했다. 애초에 테이블에 칼럼을 따로 만들었다면 좀 더 쉽게 작성을 했을 텐데. 뭔가, DB 테이블 설계 원칙에 대해 알고 있는게 많이 없다보니, 테이블을 작성하면서 많이 부족함을 느꼈다. null 칼럼을 많이 둬도 되는건지. 칼럼 갯수는 적을수록 좋은건지, 어떤 상황에서는 어떻게 테이블을 짜야 좀 더 효율적인지 좀 더 알아봐야한다.
[AWS와 https 배포, 쿠키설정]
[팀장으로서의 역할] 업무분배?,,이런 부분에서 잘 한건진 잘 모르겠다.. 초반부에는 회의 전 내용을 미리 잘 정리하지 못해 공백 시간이 너무 길어지고, 어려운 문제에 대해서는 어쩔 줄 몰라 회의를 너무 길게 끌었는데, 후반부엔 어떻게 대처해야 할지 좀 감이 잡혀서 시간이 지나치게 길어지는 걸 어느 정도 막을 수 있었던 거 같다.
그리고 이번 한달동안 제일 어려웠던 건, 주어진 태스크를 해내는데 얼마나 시간이 걸릴지 예측하는 것이었다. 특히 채팅기능이나, 이미지 업로드나, 이메일 인증, 등등 이전에 배워본적이 없었던 걸 프로젝트에 적용하려고 하니, 얼마나 시간이 걸릴지를 예측하기가 힘들었다. 이를 계산해서 팀원들에게 얼마나 걸릴거같다고 예상되는 일정을 내놓아야 하는데, 그게 어려웠던 거 같다. 이런 상황에서는 대략 예상일정을 며칠 걸릴거같다고 대강의 일정을 얘기하고, 꼭 중간중간 어디까지 진행되었는지 공유하는 게 최선이지 않을까 생각한다.
체력관리도,,,잘 못한거같다.많이 피곤한 상태에서 기능구현을 하다보니 이메일 인증기능 구현에서 자꾸 수정사항이 생겼고, 멍해지는 시간이 많아지면서 몇일 만에 끝낼 수 있는걸 4일 넘게 끌었던 것 같다. ㅠㅠ 일찍 자고 차라리 일찍 일어나서 해야겠다.