2주차 그룹 회고

자신에 대한 회고

나정

• 이번주에 개발을 해보니 협업이 점차 익숙해지고있다.
• 내 목표 달성하기도 바빠서 다른 팀원들의 코드를 세세하게 리뷰하지 못했는데 다음주에는 더 열심히 읽고 리뷰를 남겨야겠다.
• 나를 위한 시간이 하루에 한시간도 되지 않는 것 같다.. 다음주에는 뭐라도 해야겠다
• 구현을 생각하다보니 코드를 근본적으로 고민해보는 시간이 참 적다고 느꼈다. 고민하는 시간이 아깝기도 하고 고민을 해도 해결하지 못하면 아무것도 아니게 되어버리는게 두려워서 그렇다.
• 고민하는 시간을 많이 갖자!!! 그것도 개발의 일부다~
• 다음주에는 테스트를 열심히 짜야겠다. 테스트를 이번 프로젝트로 정복하겠다!

서진

• 타입스크립트를 처음 썼는데 생각보다 진짜 괜찮았고 진짜 프로그래밍 하는 느낌이 들어서 좋았다
• 이렇게 고급 인력 분들과 코드를 같이 짜는게 처음이라 영광스러웠고 감사했다
• 그렇지만 다른 팀원분들의 작업에 대해 리뷰를 더 자세하게 달지 못해서 아쉬웠고 어떤 작업들이 무슨 방식으로 완료되었는지 완벽하게 이해하고 있는 것 같지 않은 나의 모습이 아쉬웠다
• 무엇보다 항상 4% 부족하게 개발하는 것 같아서 슬프다 흑흑.. 이슈 달성도나 코드 깔끔도(?) 면에서 2%씩 모자란 것 같다
• 캡틴 판교님의 강의와 함께 더 열심히 코드를 짜보면 좋을 것 같다

찬희

• PR은 소통이다! 지금보다 더 자세하게 남기자! 그리고 다른 팀원의 PR 지금보다 더 꼼꼼하게 보겠다
• 컨디션 관리를 잘 해야하겠다고 느꼈다. 금요일 되니 너무 체력이 떨어진다아... 딴짓하지 말고 일찍자도록하고, 운동을 다시 시작하자!
• 이번주까지는 팀원들이 문서화에 힘써줘서 문서에 대해 신경을 너무 안썻던 것 같다! 문서화! 문서화! 문서화!
• 저번에도 생각했지만 근거가 확실하다면 두려워하지말고 행동해야겠다!
• 카페인, 제로콜라 줄이기...

효근

• 일주일동안 협업을 진행했다! 4명이서 하나의 프로젝트를 하는 경험이 처음이라 새롭고 재밌었다.
• test에 대한 감이 많이 죽은 것 같다! 주말에 복습해야지~
• 타입스크립트 강의를 팀원들과 같이 공부하기로 했다! 오늘부터 시작이라 천천히 들어야겠다.
• 요즘 집 밖에 잘 나가지 않아서 좀 폐인이 된 느낌이다. 산책도 좀 다니고 쉬기도 쉬어야겠다.
• 1 + 1 + 1 + 1 > 4 인 것을 느꼈다!

팀에 대한 회고

개발 관련

테스트 코드

1. 스토리북보다 유닛테스트!!
2. 기술 공유 소재

담에 할 일

1. 이미지 업로드 - 오브젝트스토리지
2. 웹팩에 경로 alias 설정
3. Page에는 MainPage와 같이 접미사 Page 붙이기
4. 퍼블릭 리액트 이미지 덕스코드 로고로 교체

담담에 할 일

1. 그룹멤버에다가 유저 프로필 사진과 닉네임 저장하기 ⇒ 프론트에 반영

   백로그 일들이 완성되면 ㄱㄱ!!!

2. 타이머 등의 추가 기능 개발

개발 밖

깃허브 브랜치 전략

스쿼시 / 리베이스 / 쌩 머지

• 서진 : 지금 방법 + 릴리즈만 스쿼시 머지

  나는 지금이 더 멋있는 것 같다

  전체 커밋 로그를 보는 일은 거의 없으며

  풀리퀘를 조회하면 그 기능과 관련한 커밋만 볼 수 있다

  그러므로 굳이 커밋 기록을 깔끔하게 정리할 필요는 막 느껴지지는 않는다는 입장이다!

  리베이스를 도입하면 할 일이 더 많아지며,

  나중에 바빠질 때 정신없으면 치명적인 실수를 할 가능성이 생긴다

• 찬희 : 스쿼시머지가 클릭하면 PR로 가져서 PR찾기 쉽고 dev 브랜치 히스토리도 깔끔해지긴 함. 그런데 우리는 PR 단위가 커서 여러 작업이 한 PR에 뭉쳐있는 경우가 많고, 그래서 롤백해야하는 경우 스쿼시로 하면 롤백 필요하지 않은 부분까지 싹 돌아갈 수 있기 때문에 나도 지금이 좋은 것 같음! 그리고 리베이스는 진짜 컨플릭트도 잦아지고 복잡해지는데다 머지 기록이 안남으니 확실히 우리한테는 안맞는거 같음!

이슈, 풀리퀘

• 서진 : 풀리퀘를 좀 더 자세히 써준다면 좋겠다

  풀리퀘는 단순히 'dev에 머지하기 위한 절차'가 아니라

  팀원들과 자신이 한 작업에 대해 소통하는 작업 중 하나라고 생각한다!

  VSC가 아닌 깃허브에서 코드를 보면

  전체적인 맥락에서 지금 맥락의 코드가 무슨 기능을 하는지 쉽게 이해하기 어렵고

  무엇보다 모든 코드를 읽고 이해하는 데에는 한계가 있다..

  올린 코드 중 가장 중요한 로직, 혹은 새로 써보는 기술인데 동료들이 모를 것 같다면!!

  부연 설명을 짤막하게라도 풀리퀘에 써준다면 좋을 것 같다!

  사실 코드 리뷰의 조건은

  1. 코드가 깔끔하고 이해 잘되며
  2. 코드를 보는 사람이 (그 코드를 슬쩍 보고도 이해하고 추가적인 생각을 할 만큼) 똑똑해야..하는데

  다들 1을 너무 잘 해주는데 내가 2번이 안돼서 ㅜㅜㅜ

  시간 조금만 내서 써준다면 정말 고마울 것 같다!!

  그리고 PR 내용들 정리하면서 방금 쓴 코드를 돌아보고 정리하는 시간을 갖게 되니 더 도움이 되리라고 믿는다..!!

  찬희 : 내가 범인인거 같다... PR 앞으로는 공들여서 자세하게 써 볼께! 협업 경험이 적어서 개발에만 집중하고 PR, 이슈 등 협업시 필요한 프로젝트 관리에 소홀했던 것 같네 반성합니다 ㅠㅠ

  서진 : 내가 좀더 똑똑했더라면 슥슥 읽을 텐데 아직 리덕스 공부단계라 미안허이....

• 서진 : 이슈 단위가 더 작았으면 좋겠다

  그것이 'CI'니까..!

  그런데 프론트엔드는 어떻게 쪼갤지 너무 애매해 ㅜㅜㅜ...

  찬희 : 인정 합니다. 이슈가 너무 큼직큼직해서 나눠하기도 힘들고 이전 작업에 뒤따라와야되는 작업이 밀리는 경우가 생기는듯? 그리고 이슈를 쪼개서 PR을 많이 만들면 리뷰도 잦아지니 코드퀄리티도 올라갈 것 같음 조금 번거롭더라도.

  서진 : 사실 이슈가 커지고 PR이 커지면 리뷰할 코드가 늘어나서 제안해 보았습니다. ..

• 나정 : 나는 pr을 이슈단위로보내서 어제만해도 api 하나에 pr 하나씩 보냈는데 이게 번거로우려나!? 합쳐서 보내고 설명을 자세히 하는게 좋을까?

• 서진 : 나는 어제 나정언니가 보낸 규모의 PR이 딱 좋다고 생각했어!! 리뷰달기도 힘들지 않고 무슨 일 했는지도 딱 보이고!!

  → 나정 : 오.. 내 예상과 반대다! 나는 너무 짧게 보내서 계속 다른사람들 작업하는데 리뷰를 부탁하는거 같았어 ㅋㅋㅋ

• 찬희 : 나도 동의 의미있는 수준이라면 규모가 작을수록 좋다고 생각함!

• 서진 : 그리고 리뷰 받는 동안 조금이라도 쉬어 .. ㅜㅜㅜ ㅜㅜㅜㅜ ㅜㅜㅜ