중간 회고

🐳 백엔드

정현서(Emily)

• 중간 프로젝트에서는 많은 기능을 구현하려다보니 각자 맡은 일이 바빠서 코드리뷰를 제대로 진행하지 못했다. 이번에는 MUST로 구현할 기능을 줄이고 코드리뷰를 좀더 열심히 하기로 정했다. 꼼꼼하게 리뷰를 남기지 못하는 경우도 있지만, 다른 팀원들의 코드를 보면서 배우는 점도 많고 자신이 맡지 않은 도메인까지 더 잘 이해할 수 있게 되었다.

• CI할 때 JaCoCo를 도입해서 진행중인데 최소한의 테스트 코드는 짤 수 있게 되어 테스트 코드를 습관화하는 것에 도움이 됐다. Mockito가 어려웠는데 이번에 많이 사용해보면서 익숙해지고 있다.

• 한 기능을 구현할 때 여러 시나리오를 구려본 후에 구현을 했어야 했는데 그러지 못했다. 여러 상황을 생각해보지 못한 채구현을 시작해서 구현 중간에 계속 로직을 수정해서 시간이 더 오래 걸렸다.

• 지금까지는 생각했던 것보다 코드 리뷰를 열심히 진행하지 못했다. 남은 기간동안에는 코드리뷰를 더 열심히 진행해 보고싶다.

빈푸(Binfoo)

• submodule을 도입하여 외부에 노출되면 안되는 정보들을 버전 관리할 수 있도록 하고, CI/CD 에 사용될 수 있도록 했다. 개인마다 submodule update하는 명령어가 달랐는데, 어떤 것은 되고 어떤 것은 안되었던 이유를 더 찾아보면 좋을 것 같다. 그 외에 배포 yml의 정보가 바뀔 경우 지금처럼 submodule을 통해 정보를 관리하면 좋을 것 같다. gradle의 resources copy 옵션도 처음 알게 되었다.

• Service Test를 진행하면서 행위 테스트의 의미를 점점 깨닫고 있다. ‘어떤 값이 반환되었는지'보다 service의 ‘로직이 실행되었는지'에 초점을 맞추면서 작성하니 속도도 붙는 것 같다. jacoco의 report를 보며 테스트 커버리지를 보는 재미가 쏠쏠하다.

• Security의 WebSecurityConfigurerAdapter가 deprecated되면서 bean 주입으로 방식을 바꾸고, JwtAuthenticationFilter의 위치를 바꿨는데 이전과 살짝식 다르게 동작하는 부분이 있다. antMatcher는 동작하지 않고 @PreAuthorize는 동작하는 문제가 있다.

• 팀원분들이 편하게 코드리뷰하실 수 있도록 PR 크기를 줄이도록 노력해야겠다.

• QueryDSL 적용

• User Role 확대

• 채팅 기능

샤크(Shark)

• Service Layer에서 Mocking을 이용한 행위 검증을 처음으로 진행해 보았는데, 의존성을 최소화 하며 함수 내부의 동작을 검증한다는 측면에서 제법 유용한 테스트인 것 같다. 앞으로도 상태 검증과 행위 검증을 적절히 섞어 사용하면 좋을 것 같다.

• Github action, Github submodule, Docker Hub, Elastic Beanstalk을 이용한 컨테이너 기반 무중단 CI/CD 파이프라인을 개발 초기에 구축해 개발의 편리성을 높이는 데에 일조했다. 또한 이번에 팀에서 중요시 여기게 된 Test를 merge 뿐만이 아니라 PR때에도 자동으로 돌아가게 구축함으로써 팀의 개발 문화를 양질의 방향으로 발달시키는 데에 도움을 준 것 같다. CI CD 구축의 중요성을 알고 추후 다른 프로젝트를 진행하더라도 빠르게 구축할 수 있을 만한 실력을 기른다면 좋을 것이다.

• 초기 대댓글 정책의 구현 난이도로 인해 중간에 기획이 일부 변경되었었다. 다행히 Front End 측이 해당 부분에 대해 본격적인 구현을 시작하기 직전에 안건을 공유해 합의를 보았으나, 더 일찍 이야기할 수 있었음에도 안일함으로 인해 바로 이야기 하지 않아 자칫 시간을 더 잡아먹을 수 있었기에 이에 대해 경각심을 가지고 다음부터는 안건이 생길 시 바로 공유하는 자세를 보이면 좋을 것 같다.

• 슬프게도 AWS Key를 Github에 노출했었다. 처음엔 그저 복사 붙여넣기 실수인 줄 알았으나 추후 찾아보니 Github submodule의 동작 원리를 제대로 숙지하지 않고 사용하는 데에만 급급했기에 생긴 불상사였다. 이유가 뭐라고 해도 나의 실책인 것은 맞으니 변명의 여지는 없다. 짧은 시간 뿐이었지만 그 사이에 얼마나 많은 일들이 일어나는지 직접 보았기 때문에 경각심이 높아진 만큼 다시는 이런일이 발생하지 않도록 주의해야 할 것이다.

• 필요한 로직이 생기면 QueryDsl을 이용해 볼 생각이 있었으나, 아직 까지는 JPQL 만으로 불편한 점이 없었기에 따로 QueryDsl을 사용하지는 않았다. 다만 이번 프로젝트는 단순 구현 뿐만이 아니라 경험을 위한 측면도 있으므로 QueryDsl을 사용해 볼 기회가 있다면 최대한 사용해 보는 것도 좋을 것 같다는 생각이다.

제리(Jerry)

• 이번 프로젝트에서는 중간 프로젝트의 아쉬웠던 점들을 반영하여 코드 리뷰를 필수로 하도록 규칙을 정하고 코드 동작의 무결성을 보장하기 위해 jacoco로 커버리지를 설정한 뒤 테스트 코드를 작성하고 있습니다. 또한 프로젝트에 적용해본 기술 또는 겪었던 이슈를 해결하는 과정을 문서로 남기고 있는데 이러한 것들을 프로젝트 종료시점까지 잘 유지시키고 싶습니다.

• 이번 프로젝트에서 맡게된 기능 중 조회하는 부분이 많은데 이를 성능 향상을 위해 최대한 한방 쿼리로 해결하려고 하고 있습니다. 이 과정 중 쿼리에 대해 많이 고민하고 공부할 수 있었는데 남은 기능을 구현할 때도 최대한 성능을 좋게 할 수 있는 쿼리를 고민하고 사용하고 싶습니다.

• 이번 프로젝트에서 조급할 필요가 없는 상황에서 많이 조급 했던거 같습니다.

• 이전 프로젝트보다는 괜찮았지만 내가 맡지 않은 도메인에 대한 이해가 조금 부족했던거 같습니다.

• 지금은 시도해보고 싶은게 있기 보다는 현재 목표로 하고 있는 기능들을 충실히 구현하고 싶습니다. 그리고 여유가된다면 지금 보다 더 꼼꼼히 다른 분들 코드 리뷰하고 다른 도메인에 대한 이해를 높이고 싶습니다.

🐙 프론트엔드

공공(Gonggong)

• 문서화를 잘하고 있어서 만족스럽습니다. 회의록을 매일 꼼꼼하게 기록하고, 깃허브의 discussion을 잘 사용하고 있다고 생각합니다.

• 프로젝트를 체계적으로 관리하고 있습니다. 스프린트 방식의 작업 관리, 이슈 기반으로 브랜치 만들기, 꼼꼼한 피어 리뷰 등이 좋습니다.

• 팀원 분들이 책임감 있게 자신의 역할을 잘 해주고 계십니다. 덕분에 프로젝트가 원할하게 진행되고 있습니다.
자신의 작업 뿐만 아니라 팀 공동의 문제에 적극적으로 관심을 가져 주십니다. 이 분위기를 잘 유지하고 싶습니다.

• 기획 및 디자인이 구체적이지 않았던 점이 아쉽습니다. 이미 개발한 작업을 수정해야 하는 일이 자주 발생했습니다.

• 백엔드 팀원들과 소통 시, 배경지식의 차이로 인해 다소의 어려움이 있었습니다. (전역 상태 관리, DB)

• 기획, 디자인을 더 튼튼하게 하고 개발에 임해야 할 것 같습니다.

• 프론트엔드 외에도 백엔드, CS 등 지식을 넓혀야겠다는 생각이 들었습니다.

케이(K)

• github의 기능을 잘 사용하고 있습니다. 프로젝트에 대한 논의나 스크럼 등의 일 들을 굳이 다른 툴을 이용하지 않고 github 만으로 처리할 수 있는 점이 좋습니다.

• 팀원 분들이 항상 열정적이기 때문에, 어떤 시간에 접속해도 팀원 분이 항상 계셔서, 빠르게 소통하면서 작업할 수 있습니다.

• MSW를 도입한 것 까지는 좋았으나, 도입이 늦게 되어서 팀원 분들이 잘 활용하지 못하는 것 같아서 아쉽습니다.

• 초기 설정을 제대로 잡아 놓지 못한 점이 아쉽습니다. 개발에 급급하여 API 명세의 타입 정의를 늦게 하게 되어서, 나중에 컴포넌트의 props와 API 명세의 타입이 맞지 않아, 타입 들을 재사용하기위해, 컴포넌트의 props를 재정의 하는 등의 추가적인 작업이 필요하였습니다.

• 기획이나 기능 역시 자주 바뀌게 되어 아쉽습니다. 초반에는 디자인은 간단하게만 해두고, 개발을 하면서 디자인을 하자 라는 생각으로 개발에 들어갔는데, 개발에 들어간 컴포넌트를 다른 팀원에게 설득하고, 추가적인 논의를 하느라 시간을 많이 쏟게 된 것 같습니다. 초기 기획을 조금 더 탄탄하게 잡고 갈 필요가 있습니다.

• API 진행 속도에 대해서 여쭤보고, 도입 할 수 있는 부분에는 MSW 를 도입하는게 좋겠습니다. 타입 스크립트를 사용하고 있기 때문에, 실제로 API에서 내려오는 데이터를 미리 활용하는 것이 중요하다고 느껴집니다.

혜삐(Hyevvy)

• 팀원분들과의 원활한 협업이 너무 좋았습니다! discussion 을 이용해서 안건을 정리하여 팀원이 전부 다 있지 않은 상황에서 논의된 부분을 공유한 점이 특히 좋았습니다.

• 열정적인 팀원분들덕에 지치지않고 잘 달려올 수 있었던 것 같습니다 :) 앞으로도 화이팅 !

• 초기 설정이 조금 아쉬웠습니다. theme 이나 alias, husky 등등 초기에 좀 더 튼튼히 했다면 개발 시간을 단축하지 않았을까 싶습니다.

• 초기에 분명 figma를 통해 공통 컴포넌트를 뽑아냈는데, 이 당시에는 header, footer, map 뿐이었는데 개발을 하면서 공통 컴포넌트가 자꾸 불어났던 점이 아쉽습니다!

• 초기 기획이 계속 바뀌는 점이 아쉬웠습니다. 4주가 안 되는 기간 중 1주 넘게 기획에 투자한 것 같은데 개발에 들어가면서 논의가 끝난 부분이 계속 바뀌는 것이 아쉬웠습니다 🥲 

• 백엔드분들과의 협업을 하다보니 DB 에 대한 이해가 부족하다는 생각이 들었습니다. 그래서 협업을 잘 하기 위해서는 배경지식을 좀 더 쌓아야겠다는 배움을 얻었습니다🙃

• 초기 기획단계를 좀 더 튼튼히 하고, 개발 초기 세팅을 꼼꼼히 설정해야겠습니다!  

그린(Green)

• 최소 2명의 approve를 받아야 merge를 할 수 있게 gitHub내에서 설정 했던것 좋았습니다! 없을때보다 코드리뷰 주고받는 속도가 훨씬 빨라지고 필수적으로 리뷰를 받아 팀원들의 의견을 반영했기 때문에 코드의 퀄리티에도 도움을 줬습니다.

• Discussion 기능 사용한 것 좋았습니다. 꼭 노션으로 가지 않고 개발중에 발생한 문제나 안건에 대해서 같이 보면서 의논할 수 있어서 좋았고, 기록이 된다는 관점에서도 유용했습니다.

• msw 사용을 도입 한것은 좋았으나 시간이 부족해 모든 부분에서 도입하지 못한 점이 아쉬웠습니다.

• 백엔드에 대해 잘 알지 못해서 소통하는데 어려움이 있었습니다.

• 컴포넌트를 좀 더 잘게 나누지 못해 PR단위가 너무 커졌던 것 같습니다.

• 처음부터 msw 사용해 API mocking 진행하면 아주 좋을것 같습니다.

• 코드리뷰를 좀 더 꼼꼼하게 해드리고 싶습니다.