2025년 2월 7일 2번째 정기 회고
지금은 부트캠프 과정 약 2달째!
지난 회고록 이후부터 오늘까지 약 1달을 회고해 보려한다.
글을 작성하고 있는 지금은 프로젝트 기간이라, 아마 회고록 대부분의 내용이 팀 프로젝트 관련 내용일 것 같다.
그래서 현재 프로젝트 기간동안 개인 스프린트 미션, 강의는 진행되지 않고, 약 2.5주정도 초급 프로젝트를 진행하였다.
팀프로젝트 1 기획과 프로젝트 초기 세팅
어떤 점이 좋고 어떤 점이 나빳나?
좋았던 점
아쉬움과 보람참
아무래도 처음으로 하는 팀프로젝트이다 보니 보람도 있고 기획단계에서 놓쳤던 점이 있어 아쉬움도 많지만 그만큼 다음 팀 프로젝트 기획과정에서는 좀더 확실히 준비할수 있지 않을까 라고 긍정적으로 생각이 든다.
우리 팀은 하루 2번의 데일리 스크럼 타임을 가지고, 스크럼 타임이 아닐때에도 우리팀 디스코드 채널에 상주해 있었다. 뭔가 상의를 거치거나 도움이 필요할때, 즉각적으로 소통할 수 있는 분위기가 잘 형성되어 있어서 좋았다.
기획의 중요성 깨달음
기획이 프로젝트의 절반이구나, 싶을 정도로 기획의 중요성을 크게 실감했다.
멘토님의 피드백
프로젝트 중간 과정에서 멘토분이 해주신 리뷰도 너무나 좋았다.
common 컴포넌트에서는 절대로 아무런 하드코딩이 일어나서는 안되고 개발자로서의 마음가짐이라고 하셨다.
심지어 그 공용 컴포넌트를 사용하는 컴포넌트 내에서도 문자열을 전달하는 것이 아니라 전역 상수를 사용하는것이 좋다고 하셨다. 생각해보니 같은 "롤링페이퍼를 찾을 수 없습니다!" 라는 toast 메시지여도, 롤링페이퍼가 rolling paper로 바뀔수도 있고 롤링-페이퍼 로 바뀔수도 있는데 내가 그러한 유연성을 사전에 차단해 버린것 같다는 새악이 들었다.
나빴던 점
팀원간 진행속도 차이
역할을 분담하고 초기에 공용컴포넌트를 각자 먼저 구현을 하였는데, 거기서부터 생각보다 속도 차이가 많이나서 당황스러웠다. 공용 컴포넌트가 없으니 이후 페이지를 구현하던 나는 공용컴포넌트를 직접 만들어서 페이지를 구현하고 기능을 테스트 할 수 밖에 없었다. (공용 컴포넌트의 의미가 없어졌다...)
packages_rock.json conflict
특정 팀원이 npm install을 할때마다 package.rock.json 파일의 모든 라이브러리에 License="MIT" 값이 추가 되었고, 올린 PR에는 renux.64와 android 패키지가 install 되어있었다.
해당 PR의 package_rock.json 에는 1400줄이 추가 되었고, 당연히 pull conflict가 났다. VS Code 병합기에서는 package_rock.json 에서 80개의 충돌이 났고,수작업으로 package_rock.json을 섣불리 건드리기가 힘들었다..
주강사님과 멘토님도 적잖이 당황스러워 하셨지만, 파일을 계속 과거로 회기하여 거의 초기 세팅 상태로 돌리고, 우리 팀원과 같은 상태로 맞추기 위해 거의 2일간 매달려 있었다.
초기 기획의 아쉬움
전역 상수와 환경 변수 설정 같은 기획단계에서 했어야 하는일을 지금 리팩토링 단계에서 깨닫고 하다보니, 모든 팀원들이 이미 작성한 코드를 부분부분 수정해야 했다. 초기에 했으면 이렇게 손이 두번가지 않았을텐데... ㅠㅠ 라는 아쉬움이 들었다.
어떻게 해결해야 할까?
이 모든것은 기획으로 부터...
위에서 말한대로 나는 다른 팀원이 맡은 공통 컴포넌트를 직접 만들어서 사용해야 했는데.. 사실 나는 그단계에 초기 설정인 다른 부분을 하고 있어야 했다! 예를 들면 전역 상수... 환경 변수 설정 등 그시기에 내가 깨닫고 했더라면 지금 이미 작성한 코드를 모든 팀원이 바꿔야 하는 일은 없었을 것인데...
위와 같은 맥락으로 이번에 기획의 중요성을 다시한번 느꼈다. 우리는 기획단계에서 분명 많은 시간을 쏟아 부었지만 (회의만 약 2일에 걸쳐서 12시간...) 중요한 부분을 빠트렸던것 같다.
무엇을 했나?
### 스터디
프로젝트 기간이지만 우리 스터디 원들은 모두 성실히 임해주었다.
오히려 우리는 아직 진행하지 않은 챕터들 중에 프로젝트에 도움이 되기 위한 챕터를 해당 주의 챕터로 채택했고, 실제로 도움이 많이 되었다.
아래는 프로젝트 기간중에 스터디를 진행한 챕터
브라우져의 렌더링 과정
에러처리
barbel
ES6의 추가기능
💥 트러블 슈팅
트러블 슈팅이라고 하긴 민망하지만, 이번 프로젝트에서 사실 가장 힘들었던 것은 다른사람의 코드를 보는것이였다. 사실은 가장 중요하다!
그러나 내가 자주 사용하는 함수 사용이 아니라던가..(이벤트 핸들러를 바로 콜백함수로 사용, 나는 리퀘스트 함수시에 try catch 문을 사용하는데 then.catch 체이닝을 사용) 등의 정말 여러가지의 이유로 컴포넌트의 전체적인 흐름이 눈에 잘 보이지 않았다. 그러나 pr시에 정말 꼼꼼히 보려고 노력했고, 내가 할수 있는 선에서는 리뷰를 남겨서 팀에 좋은 방향성을 제시하려고 노력했다 ㅠㅠ
앞으로 무엇을 할것인가?
지난 회고록에 작성한 할일
- 스터디
- 코딩테스트
- 사이드 프로젝트
를 적었으나... 팀프로젝트 기간에는 보류 하였다 첫 팀프로젝트였기에 시간 분배가 조금 힘들었다는 변명아닌 변명... 다음 프로젝트 때는 시간 분배도 신경써야 겠다.
개인미션
팀 프로젝트가 끝나고 난뒤에는 바로 typeScript 강의에 들어가기 때문에, 최대한 빠른 시일내에 개인 미션을 진행해야 할것 같다.
개인 미션또한 커리큘럼 강의를 따라서 html -> javaScript -> react -> typescript -> next 순으로 개인 미션이 제공되어있기 때문에, 커리큘럼과 개인미션사이의 진도차가 너무 크지 않도록 해야 할것 같다.
사이드 프로젝트
이번 팀프로젝트를 통해서 기획이 얼마나 중요한지를 깨달았고, 혼자 진행하던 프로젝트또한 혼자 진행하는것이지만, 그렇기에 효율적인 진행을 위하여 기획이 중요할것 같다는 생각이 들었다.
그래서 결론은 다시 원상복귀... 헤헿
