체계가 잡히지 않은 상황에서 전략 프레임워크를 도입하신 것은 생산적인 선택이였다고 생각합니다 👍
협업이라는 상황이 시작되면 브랜치를 얼마나 잘 사용하냐, 전략에 따라 얼마나 잘 교통정리가 되냐에 따라서 생산성이 좌우됩니다. 이번 기회에 첫 경험을 해보았다. 요정도로 생각해주셔도 좋을꺼같아요! 대신 회고때 객관적으로 어느 부분이 제일 문제였는지 정리가 되면 좋을거같습니다.
동기식으로 어떻게 하셨는지 궁금하네요 🤔 ! 보통의 비동기 방식에는, 브랜치를 여러개 두고 서로 의존되지 않는 작업들을 스위칭하면서 작업하는 것등이 있는데요. 현재는 작업 순서나 서로의 작업이 어디까지 의존되는지가 정리가 덜 된상태에서 작업이 진행되서, 동기적으로 작업해야하는 상황이 비동기적인 상황보다 많아진게 아닌가 싶네요!
같은 프로젝트, 같은 스펙 구현을 진행하고 있기때문에 git 충돌 등은 빈번한 상황이긴합니다! 이런 상황에서 커뮤니케이션 어떻게 하는게 좋을지 경험해보신다고 생각해주셔도 좋을거같아요 👍
API 연결 기술
예외처리가 되어있지 않은 요청과 같은 케이스는 보통 개발하면서 발견되곤 하는데요,(엣지케이스 라고 합니다) 이번 레슨을 통해서 유사한 개발을 진행할 때 사전에 발견할 수 있는 시야가 생긴것만 해도 좋은 경험이라고 생각합니다.
API 연동에서 이슈들이 많으셨군요 😢 사실 실제 프러덕션에서는 프론트에서 발생시키는 이슈사항으로 인해서 서버가 죽는일은 없습니다! 서버에서도 벨리데이션 작업 등 guard작업을 해주시기때문에 실무에서는 발생하지 않습니다. 즉, 절대 잘못하신게 아니고! 개발하다보면 당연히 발생되는 현상입니다.
다만 환경이 연약하다보니, 이럴경우에는 msw 라는 라이브라러리를 활용하시는 것도 추천드립니다. (api를 mock으로 하이제킹)
해당 이슈가 많이 블로커가 되셨군요 ㅠ 괜찮습니다! 그럴때는 다른 정리작업들 하시면서, 이슈로 인한 pending상태를 계속 블로커에서 알려주는 방법밖에 없긴합니다 🙏
멘토님께 궁금한 점
Q1. 프로젝트를 진행하면서 conflict를 github web editor에서 수정하거나, 로컬에서 develop을 pull 한 뒤 merge해서 conflict를 해결한 뒤 올리는 방식으로 작업했는데, 어떤 방식이 더 효율적인지 알고 싶습니다!
후자가 효율적입니다! 양이 많을 때도 후자가 효율적이고, 포매팅 등의 자동화 작업들이 필요한 경우에도 후자의 방법이 좋습니다
Q2. 실제로 실무에서 다른 사람이 작업한 기능이 내 작업에 필요한 경우, 어떻게 작업을 진행하시는지 여쭤보고 싶습니다!
애초에 작업의 의존도를 파악해서 업무를 분배합니다. 하지만 그럼에도 의존도가 생기게되면,
의존되는 기능 직전의 작업만 진행하고, 다른 작업을 진행하거나
작업하고 있는 사람의 브랜치에서 새로운 브랜치를 생성하여 작업하거나
그 작업자와 커뮤니케이션하여 의존된 작업을 아예 한분에게 몰아버립니다.
보통은 1번으로 진행됩니다
Q3. API를 연동할 때, 기능을 구현할 때나, Context API 등 전체적으로 얘기할 게 있을 때 회의 일정을 어떻게 적절하게 잡을 수 있을까요?
회의라는 것이 약간 부담스러울 수 있습니다. 의견을 내는 사람도 어느정도 생각하는 시간이 필요하기때문에, 비동기로 논의하시는 것을 추천합니다. 간단하게 1pager형태처럼 안건을 슬랙에 올리고, 이에 대해서 비동기적으로 쓰레드로 논의하는 방법도 좋습니다. (저번에 말씀드렸던 슬랙 커뮤니케이션)
기본 프레임워크: 아젠다 올리기 → 논의 → action item
그리고 회의는 30분 이내로 끝낼 수 있도록 라이트하게 진행하시는 것을 추천드립니다.
개인회고에 답변
이재웅
고생많으십니다 팀장님! 💯
모든 프로젝트의 절대적 진리는 완벽한 계획과 기획은 없다는 것 입니다. 경력이 쌓이면서 시야가 넓어지며 노하우가 생기게되고, 프로젝트 진행 전에 더 많은 부분을 고려할 수 있게 되는 것 같습니다. 고로, 재웅님이 느끼셨던 “회의를 진행하는 횟수도 잦아지면서 오히려 더 시간을 잡아먹게 되는 상황이 일어나게 되다 보니, “ 이 느낌은 사실 낭비되는 비용은 아니고, 필수적으로 진행될 수 밖에 없는 커뮤니케이션이라고 생각해요. ! 자책 노노입니다 ㅎㅎ
추상화나 결합도 낮추기 등의 고민이 드셨다면 이미 훌륭한 고민을 하고 있으시다고 생각합니다. 이렇게 크러시 모드로 달리고 다면, 그 고민들을 리팩토링 기간을 통해 해소하시면 된다고 생각해요~
PR은 300줄 이하로 작업하시는 것을 추천드립니다. 300줄 이상이 되면 컨텍스트 파악이 힘들고, 리뷰어들이 읽기 부담스러운 사이즈일거에요.
장규범
카테고리로 잡아서 회고하시는 것 굳입니다 👍
회의시간: 현재 진행하셨던 회의 방식에 대한 회고를 디테일하게 팀원분들과 진행해서, 구체적인 pain point를 도출하는 시간을 갖으셔도 좋을거같아요!
“무작정 Redux로만 개발을 하려고 한 편견을 깰 수 있었습니다.” 훌륭하십니다. 프로젝트 회고때 이 부분을 꼭 강조해서 디테일하게 작성되면 좋을듯 하네요!
위에도 작성했지만 api 연동을 mock형태로 테스트할 수 있는 라이브러리도 있습니다! 요것도 활용해보셔도 좋을거같아요 ㅎㅎ https://mswjs.io/
팽건우
잘하고 있습니다 부장님! 💯
건우님의 회고를 보니 제가 자주 얘기했던 ㅎㅎ 테크스펙을 한번 작성해보시는 것도 좋은 정리가 될 것 같아 추천드립니다!
개인의 리소스 관리는 스스로가 적당이 분배하고, 헬스적인 부분도 관리해야한다고 생각하는데요. 이번 기회에 이런 “개인 리소스관리" 차원에서도 디테일하게 회고해보셔도 좋을거같네요! 예상했던 일정과 더불어서, 어디서 블로커가 되었는지 어디서 생각보다 빠르게 진행되었는지 등등이요.
스스로의 작업이 빠르게 종료가되면 다른 분들의 업무를 도와드리는 방향으로 시간을 분배하셔도 좋을 듯 합니다. 작업을 적절하게 떼어가는 것도 능력 😊
홍정기
ㅎㅎ 항상 “이 정도면 됐겠지”라는 행복회로에서 모든게 시작되는것 같아요. 경력이 쌓이고 시야가 넓어지면 좀더 초반에 보수적이게 되실겁니다!
막 개발 ㅜ 공감합니다. 시간이 촉박하니까요. 초반에 일정 산정이 조금 더 정리되었다면 아마 이런 상황이 없었을수도 있을 거같은데요. 본인이 “막" 짰다고 느껴지는 부분에는 comment로 마킹을 해두는 것이 좋습니다 ( FIXME, TODO, REFACTORING, … ) 그리고 이 마킹부분을 추후에 리팩토링하는 것이지요
작업중인 브랜치에 develop 브랜치의 새로운 변경 사항을 반영해야 할 때 지금은 develop 에서 git pull origin develop 을 실행하고 작업중인 브랜치로 돌아와 git merge --squash develop 으로 변경사항을 가져오는 중인데, 이렇게 하니까 작업중인 브랜치에 필요 없는 기능들이 다 가져와져서 파일 변경사항을 파악하기가 어렵습니다. 이때는 git cherry-pick 을 사용하면 되는건지 궁금합니다.
스쿼시 머지를 하지않고, 보통의 명령어로 해도 그럴까요? git merge develop 현재브랜치 동일하게 이슈가 발생된다면… rebase 과정이 필요해서 그런거일수도 있어서, git rebase develop 현재브랜치 로 해결되는지 궁금하네요!
