우아한 테크코스) Lv2 - 5~8주차 [미니프로젝트 - 인스타그램 클론] 미션 후기, 코드리뷰

Lv2 - 5~8주차 미션 : 미니프로젝트 - 인스타그램 클론

https://github.com/woowacourse/miniprojects
https://github.com/wooteco-datastructure/miniprojects-2019
Notion 정리

미니 프로젝트란?

• 약 3.5주간(8월12~9월4일) 팀을 프로젝트를 진행
• 팀에서 주제를 선정하고 서비스의 기능을 결정하여 기능을 구현
• 기능 구현을 위해 필요한 규칙과 진행방법, 일정을 팀 내부에서 정함
• 진행과정의 결과물과 최종 결과물을 공유

기능 구현 관련

• 코드 컨벤션을 지킨다.
• 배포(miniprojects-2019 저장소의 각 팀의 브랜치로만 배포를 할 수 있다.)
• 로깅 라이브러리를 이용하여 로그를 파일로 남긴다.
• 쉘 스크립트를 통한 자동 배포가 가능해야 한다.
• 배포 시 모든 테스트는 통과해야 한다.
• Test Coverage는 70% 이상 유지해야 한다.

협업

• 필수로 진행하는 회의에 대한 회의록을 작성한다.
• 팀에서 정하는 규칙에 대해 문서로 기록한다.
• 문서는 저장소의 wiki에서 관리한다.
• 일정/이슈 관리는 github의 project에서 관리한다.

---

새롭게 알게 된 것

• 팀 프로젝트, 협업 경험
• 소프트 스킬의 중요성
• Github 활용 (Organization, 칸반보드, Wiki, Issue ...)
• 이미지, 영상 파일을 처리하는 방식과 Websocket이 기술부분에선 인상적

다른 팀원이 구현한 기술로, 좀더 제대로 학습해보고 싶은 주제들

• spring docs
• Jenkins
• OAUTH
• 다양한 테스트 방식들
• argument resolver
• builder
• JPQL
• @embeded
• xss 방어

---

느낀점

• github을 코드 저장소 용도로만 사용해왔었는데, 칸반보드, wiki 등 다양한 방식으로 활용하니 팀 프로젝트와 협업이 훨씬 수월했다.
• 그동안 페어프로그래밍 하던것과는 완전히 달랐음. 다수의 사람이 모여 협업을 하면서 다양한 문제를 맞닥뜨릴수있었다.
  • 상대의 말을 이해하는 능력이 더욱 증진됨
• 습관적으로 미션진행 당시엔 기능구현과 기술에 집중하게 됬었는데, 이번 미션의 주 목적이 협업 경험이라는 걸 강조받으며 돌이켜 생각해보니, 협업에 있어 좋았던 점과 아쉬웠던 점이 많이 생각났다.
• File 처리 방식을 단순히 AWS의 S3를 사용하기보다 raw하게 다루고 다양한 삽질도 많이 해본게 좋은 경험이라 생각. 지금 아니면 이렇게 경험할 수 있는 기회가 없을 것 같아서.
  • 관련 삽질 포스팅
  • 이미지와 동영상 파일은 어디에 저장할것인가?
  • 클라이언트에서 서버의 로컬파일에 어떻게 접근할것인가?
  • JavaScript) Fetch API와 FormData를 이용해 파일을 업로드 하기
• 팀 문화를 자체적으로 만들고, 컨벤션, git flow, 코드리뷰 등의 개발전략도 우리끼리 정하고, 짧았지만 프로젝트를 주도적으로 진행하는 과정이 재밌었다. 동시에 conflict로 고생하거나 git flow를 잘못짜서 원하는 형태로 PR 요청을 보내지 못하는 등 이런저런 문제상황을 경험할 수 도 있었다.

매주 팀 회고를 진행하며 내가 느꼈던 구체적인 점들

• Github의 다양한 기능을 좀더 활발히 사용하지못한 아쉬움 (칸반, 위키, 이슈 작성 등)
• 사람이 많아질수록 개발속도가 빨라질줄 알았는데, 오히려 3인페어가 더 오래걸리고 커뮤니케이션에서 오는 피로감 등이 2인때보다 컸다
• 테스트를 좀더 신경쓰자
• 실행가능한 그 주의 목표를 잡자
• 이슈 발생시 삽질 시간이 무한정 길어짐 -> 문제 해결 시간 Limit를 정해서 해결
• 서버쪽보다 익숙치않은 프론트/JS 코드 작성에 시간이 더 많이 들어서 개인적인 고민
• 컨벤션을 구체적으로 잡지않아, 나중에 이부분을 처리하기 위한 비용이 눈덩이처럼 늘어났다 (Production/Test code 둘다)
  • 프론트에선 js를 템플릿으로 분리해 일관된 방식으로 구현해보려 노력
• git flow 전략에 실패해 1,2주차 커밋이 꼬임
  • 원인은 cherry pick 기능을 활용해보려다 실패
  • 3주차에선 merge단위로 커밋을 분리해 다른 방식으로 적용
• 앞서 언급한 것처럼, 기능에 집착하게되어 팀 문화를 다양하게 느껴보지 못한 점이 아쉬웠다
• 하지만 팀 프로젝트를 진행하며, 상대방의 말을 이해하는 능력이 조금은 향상된 느낌
• 우리가 이른바 짬 처리라고 불렀던 각자의 역할사이의 회색지대에서 발생하는 문제들을 뒤에서 묵묵히 처리하는 역할 - 이부분을 다들 힘들어했다. 이부분이 아예 없을순없겠지만 좀더 줄일수있는 더 좋은 방법이 있진않을까?

---

내 코드, 피드백 관련

• WAS 테코톡을 듣고 : 캐싱관련 성능면에선 웹서버 와스 분리가 더나음. 반면 와스가 점점 웹서버기능을 내장하는건 개발편리성을 위해. 대용량 트래픽과 성능면에선 분리가 더 낫다. —라는 추측.

• 기본적으론 responseEntity에 상태코드만 넣어 보낼수있고, 데이터를 담는다면 기본타입(long,string,int등)을 바로넣어 보낼수도 or 객체로포장해 넣을수있었다. 이를 프론트 Ajax에서 받을땐 전자의 경우 response가 바로 기본타입 데이터이고, 후자는 res.json거쳐 then으로 받은 변수.id처럼 쉽게 쓸수 있었다. article.id처럼

• MySQL8에서는 user라는 단어는 예약어이므로 문제가 된다고한다. MySQL8Dialect에서 MySQL5Dialect로 변경하거나, user를 다른 테이블명으로 바꿔야한다. 마찬가지로 좋아요기능 구현시 like라는 단어도 문제가 됬었다.

• 그렇다고한다.

• 사소한 차이지만 의외로 소소한 시간을 먹기도 한다. Element.value vs Element.getAttribute("value")

• Lombok이 classpath에서 auto import되지않아 꽤 귀찮았다. 한참 삽질했는데 결국 코드나 설정상의 문제는 아니었고 인텔리제이를 재설치하니 해결되었다. 때론 단순무식한 방법으로.,

• 테스트에선 H2를 사용하는 방식 - 편했다

• 서비스 테스트에서 mock 조합을 통한 flow 테스트만 하는게 괜찮을 수도 있다. 단위/통합 테스트도 있으니까. 너무 강박가질필욘없음

• 파일관련 기능을 S3로 하지않고 괜히 직접 raw file로 다뤄보겠다고했다가 겪은 무수한 삽질들., - 블로그 포스팅 완료. 그치만 후회하진않고 좋은 경험이었다.

• 전부터 해보고 싶었던 websocket으로 DM 채팅 기능을 구현해봐서 좋았고, 이 과정에서 전보다는 복잡한 연관관계 매핑에 관해 고민해볼 수 있었다.

• Optional과 관련해, maybe~와 같이 네이밍하는 관습과 chain을 통해 한 라인으로 구현하는 방향에 대한 조언

• fetch api에서 formData로 파일을 업로드할때, 헤더를 지정하면 안된다. 아예 헤더필드를 빼거나 아니면 빈 { }로 지정. null/'' 둘다안됨. 또한 mulitiFile이나 url인코딩타입으로 지정해서 보내도실패. 바운더리 값 자동추가되기때문. 자세한 내용은 블로그 포스팅을 참고

• @ModelAttribute VS @RequestBody

• Column 옵션을 능동적으로 지정하고 관리한다.

• 우리가 예외처리로 고민했던 흔적

• 결국 해결하진 못했는데, 사실 앞으로 이런방식으로 파일을 다룰일이 있을까 싶기도. 다만 docBase와 톰캣에 관련한 내용은 궁금해서 나중에 찾아보긴 해야겠다.

• 우리는 비즈니스적으로 의미가 있는 예외경우들은 별도로 명시적인 로직을 만들어 처리했었는데, 이또한 좀더 멀리서 바라보면 더 뒷단에서 결국 잡히니까 의미가 없을수도 있다는 시각도 접하게 되었다. 하지만 굳이 가능한 예외처리를 더 안쪽으로 보내지않고 앞에서 처리해버리는게 낫지않을까싶기도하고. 정답이 없는부분 아닐까.

• 이번 미니프로젝트를 하며, application.properties를 이용할 기회가 많았던것 같다. 무척 유용했음.

• 아래와 같이 1차적으로 3가지 환경을 모두 준비해놓는 임시방편으로 해결했다가, 이후에 System.getProperty() 를 이용해 일관된 방법으로 처리할수있도록 해결했다. 이 역시 애초에 파일을 직접 다루기 때문에 생긴 이슈이다.

• 유용한 folding 기능

• layout으로 프론트 코드 중복제거를 하면서, 이부분에서 원하는대로 fragment 요소들이 import되지 않아서 삽질이 많았다. import되는 순서도 영향을 미쳤었다. 이후에 webpack(?!) 등 js 끼리도 자바에서처럼 서로 import하는 방법을 접하게 된다고하니 기대됨.

• 무신경했던 부분들이 많았다. 프론트도 컨벤션을 잘 맞춰주자

• 영감을 받아, 점점 발전시키며 우리에게 맞는 템플릿으로 분리시켜 이용했다.
  • 이 과정에서 arrow function과 this에 관한 이슈가 발생하기도 했다.

• Exception 처리에 관한 조언. 이후에 토비스프링의 해당챕터를 읽으며 좀더 와닿기도 함

• JS에서 전역변수 사용을 자제하자

• 권한 체크를 Service와 Domain 어디에서 하는 것이 나을까?

• 백틱이 또 !

• service 분리 -> 우리는 facade 적용. 결국 레이어를 하나더 추가해 숨겨주는것

• dataset

• closet