부스트캠프 회고 - 그룹프로젝트 3주차 day4

Today I Learned

• Array.some() 사용하기
  • 배열 안에 판별식을 하나라도 만족하는 객체가 존재하는지 확인한다
  • FE에서 상태 안의 특정 property들의 변경점 등을 확인할 때 유용하다
• React-router에서 인증 적용하기
  • 공식 홈페이지의 Auth 라우팅 가이드를 따라서 구현했다. 
  • 기본 Route를 wrapping해서 인증이 되었을 경우만 접근 가능한 PrivateRoute를 만든다. 

오늘의 느낀점

• mdn의 Array, Object, String 문서는 정말 라우터가 닳도록 매번 보게되는 것 같다. 특히 Array는 함수형 프로그래밍을 하기 위해서는 수도없이 보게 된다. 기본 자료형(+API)에 대한 숙달과 제어가 얼마나 중요한지 새삼 느낀다. 이전에 부스트캠프 전 기수 분이 지하철에서 출퇴근할때 공식 documentation을 뽑아서 보셨다고 하던데 그 심정을 점점 이해할 수 있을 것 같다.
• 카페에 다같이 모여서 팀원 분들과 하루종일 마지막 구현 날을 버닝했다.
• 어제와 오늘 프론트엔드를 팍팍 구현하고, 또 iOS 분들이 백엔드 API와 연동을 많이 하시면서 백엔드 쪽에 자잘한 수정사항이 정말 많았다.
  • 새삼 아무리 계획을 잘 세워도 수정사항은 필연적이라는 것을 느꼈다. 이런 수정사항에 번거로움이나 짜증을 느끼지 않고, 충분히 발생가능할 수 있는 사항임을 인정하는 것이 Agile한 자세가 아닐까? 아무리 계획을 잘 세워도 직접 부딫혀보기 전에는 무엇이 필요하고 잘못되었는지 (특히 초보 개발자에게는) 알기가 정말 어렵다. 
  • 지금 세보니 메이저한 변경 말고도 자잘하게 API를 클라이언트 필요사항에 따라 변경한 것이 어제와 오늘만 PR이 다섯번이 넘는다. 오늘 정신없이 작업하면서 백엔드 API 서버 배포를 자동화해놓은 것이 너무 다행이었다. 수정사항 있을때마다 서버 접속해서 고치고 있었다면 오늘 했던 작업의 1/3은 불가능하지 않았을까?
  • 몇몇 팀에서는 iOS와 API 쪽이 서로 쑥스럽고 미안하고 해서 한쪽이 API 데이터의 형태를 결정하고 그대로 쓰거나, 제대로 API 연동을 하지 못했다는 이야기를 들었다. 우리 팀은 서로 이터레이션을 하면서 커뮤니케이션이 잘 되어서 이런 프로세스가 잘 이루어졌다는 생각이 들었다. 사실 클라이언트 / 백엔드에서 잘 조율한다면 한줄 추가해서 끝날 작업을 혼자 해보려고 하다가 먼 길을 고생해서 돌아가는 경우가 종종 있다. 새삼 팀 내부 커뮤니케이션의 중요성도 느끼고, 이런 커뮤니케이션에서 아무리 원격근무 환경이 개선되어도 오프라인을 따라올 수 없는 부분이 있다고 느꼈다. 
• 팀원들과 마지막 코드프리징을 축하하면서 저녁에 고기와 맥주를 먹으면서 뒤풀이를 했다. 여러 부트캠프 등 교육과정 이야기, 취업 이야기, 개발 트렌드 관련된 이야기... 술을 마시는데도 서로 개발과 관련된 이야기를 하는 것이 정말 신기했고, 또 그런 이야기들이 술먹고 종종 하게되는 가십거리성 대화보다 훨씬 재미있는 것이 좋았다. 매주 이렇게 했었으면 좋았을텐데! 
  • 의외로 부스트캠프를 오기 전에 다른 교육과정에 참여하셨던 분들이 많았다. 이야기 해본 결과는 부스트캠프가 짱이라는 것... 요즘 개발자 양성, 코딩에 대한 교육 수요가 많다 보니 트렌드를 따라서 생긴 몇몇 부트캠프들은 사업이 확장되면서 교육 퀄리티가 떨어지거나, 관리가 안되는 케이스가 종종 있다고 한다. 

오늘의 칭찬

• 오늘은 진짜진짜 구현을 많이 했다!! 오늘 날린 PR만 8개! 힘든 프로젝트 막바지이지만 마지막까지 하나라도 더 구현하기 위해 노력한 스스로에게 칭찬을 해주고 싶다. 코드프리징이 7시인데 6시에 거의 정신력이 고갈된 상태였지만 그래도 이슈를 하나 잡아서 보이는 부분은 코드프리징 전에 완성했다.
• 오프라인에서 모여서 작업하면서 같은 팀원분들의 도움 요청과 API 변경 요청에 잘 대응했다. 팀원 분들도 나의 실수나 개선, 수정이 필요한 부분에 대해 적극적으로 말씀해주셔서 정말 감사했다.  

개선점 & Reminder

• 막바지에 구현사항이 밀리다 보니 처음에 정한 팀 그라운드룰을 100% 지키지 못한 부분이 아쉽다. 원래 PR에 대해 무조건 다른 Web 팀원에게 리뷰를 요청하고, 리뷰와 리뷰사항 반영 뒤에 Merge 하기로 했었는데 클라이언트 쪽에서 당장 API를 써야하다 보니 사소한 bug나 fix는 그냥 구두로 확인받고 Admin 권한으로 Merge 처리하게 되었다. 
  • 깨진 유리창 이론처럼 한두번 그라운드룰을 지키지 않고, 방치하게 되면 순식간에 규칙와 구조가 망가지게 되는 것 같다. 장기적으로는 협업의 효율을 저해하는 만큼 다음 그룹프로젝트에서는 현실적인 규칙을 잘 정하고 팀원 모두가 일관적으로 지킬 수 있도록 해야겠다. 
  • 그라운드룰을 사람이 매번 의식적으로 100% 챙기기에는 힘든 만큼 Issue/PR 템플릿, CI/CD, Merge 규칙, Lint 환경 등 규칙을 지키기위한 Tool을 적극적으로 사용해야겠다.