위코드 기업협업이 끝나고 곧바로 시작된 Pre-onboarding.
쉽지 않을거라 생각은 했지만 뚜껑을 열어보니 하루하루가 챌린지였다.
그러나 이 또한 지나가는 법. 어느샌가 2주가 훌쩍 지나가 버렸다.
어느샌가 진행 된 프로젝트는 3개, 팀원들과도 꽤나 친해지게 되었다고 생각한다.
내가 더 나은 개발자가 되었는지, 나의 역량은 확실히 올랐는지는 모르겠지만 적어도 2주 전에 비해서 10줄 칠 코드를 8줄로 줄이는것 정도로 성장하지 않았을까 하는 생각이 든다.
그리고 훌륭한 개발자, 남들보다 나은 개발자는 못되더라도, 어제보다 나은 개발자가 되기 위해 지난 2주의 회고를 작성하고자 한다.
위코드 기업협업이 절반가량 진행 되었을때, 슬랙에서 프론트를 위한 원티드의 Pre-onboarding이라는 코스가 개설 된다는 소식을 들었다.
당장의 프로젝트도 정신없이 바쁘긴 했지만, 당장의 내 역량에 의문점이 들기도 하였고, 아무래도 3개월이라는 시간은 너무 짧지 않은가 하는 생각에 일단 신청 하고 보기로 했다.
우여곡절 많았던 기업협업을 끝내고 시작된 새로운 코스 Pre-onboarding.
첫번째 과제였던 무한스크롤은 같이 짝이 되었던 우빈님과의 콤비로 꽤 무난히 해결 할 수 있었다.
100점짜리는 아니었지만, 두번째 만드는거라 여유가 있었고, 이것저것 자료를 찾다가 이거 한번 잡숴봐
하는 식으로 찾아 적용 시켰던 Intersection Observer를 조금 더 이해하면서 만들 수 있는 기회가 되었다 생각한다.
이때까지는 나름 잘 해낼 수 있을것이라는 왠지 모를 자신감도 있었고, 다음 과제를 기다릴 정도의 여유가 있었다.
첫번째 과제를 끝내고 새롭게 받은 과제의 테마는 고객이 보고 싶은 상품.
요점은
이었다.
이번에도 호기롭게 시작 된 프로젝트.
시작이 반이다 라는 생각으로 호기롭게 시작했더랬다.
내가 구현 했던 기능은 들어온 데이터의 브랜드를 모아 하나의 배열로 만든 다음, 각각의 브랜드를 눌렀을때 필터링 되게 하는 로직과 라우터 부분이었다.
우선 각각의 브랜드를 눌렀을때 필터링 되게 하는 로직은 엄청나게 많이 시간을 잡아 먹지는 않았으나 문제는 라우터였다.
처음 주어진 데이터를 기반으로 사용해야 하는 터라 필요한 데이터를 처음 받아오면서 1차적으로 데이터를 가공했어야 했는데, 이때 path parameter로 사용 할 id를 넣는데서 문제가 생겼다.
또한, 프로젝트를 진행하던중 예상치 못했지만 필요한 기능들이 나오기 시작해서 시간은 점점 잡아먹히고, 마음도 조급해지기 시작했다.
어찌저찌 기능 구현이 마무리 되고 제출을 하려던 순간.
상술한 path parameter의 id에서 문제가 생겼다.
바로 id는 바뀌지 않는 고유의 값이어야 하는데, 이걸 index로 지정해 버려 문제가 생긴것이었다.
그래서 id값이 배열 안에서 아이템이 나가거나 들어올때, id값이 바뀌어 버리는 상황이 되었다.
결국 시간 문제상 이 부분은 바꾸지 못하고 제출 하여서 상당한 아쉬움으로 남았다.
이런 문제 해결 과정에서, index값을 id로 사용하는것이 얼마나 위험한지를 알게 되었고,
다음 프로젝트에선 index가 아닌 다른 방법으로 id를 부여하는 방법으로 노선을 바꾸게 되었다.
우여곡절이 많았지만, 데드라인 안에 기능 가동은 확인 된 결과물을 제출 했다.
라우터 말고는 큰 문제가 없었기 때문에, 다른 팀원들에게 정말 고맙고도 미안한 마음이 들었다.
그렇게 두번째 과제도 마무리 되고 다음은 8명이 진행하는 세번째 과제.
이전 프로젝트와 인원 말고 또 다른점이라면, Git에 관련한 차이점이 존재했다.
바로 Git flow에 따라 진행하기로 한것이다.
여기 나온것 처럼, mater는 배포 브랜치, 개발을 위한 develop 브랜치를 두고, develop을 기반으로 각 페이지별 브랜치, 거기에서 페이지의 기능별 브랜치를 만들어서 만든 순서의 역순으로 Merge를 시키는 방식으로 진행 하였다.
기능은 2~3명이 나누어져 프로젝트를 진행하기로 했다.
우빈님과 다시한번 콤비가 되어 구현을 진행했는데,
우리가 맡은 기능은 권한관리와 그에 대한 라우팅, 관리자의 임의계정 생성, Util 함수 작성이었다.
권한 관리에 사용한 방법은 HOC를 사용해서, 해당 컴포넌트가 랜더링 되기 전에 권한을 판단하고 권한이 맞지 않다면 다른 페이지로 리다이렉트를 시키는 방법을 사용하기로 하였다.
아무래도 각 case에 맞춰서 조건을 줘야 하다보니 처음엔 if가 6번이나(!) 들어가는 일도 생겼지만, 우빈님과 시간을 들여 고민하며 최대한 줄이는것에 성공 하였다.
로컬스토리지를 사용하는 로직이 담겼던 util쪽에서는 이번에도 새롭게 생성 되는 계정에 id를 추가하는 기능이 필요했는데, 이때는 전 프로젝트에서 생겼던 문제점을 개선하고자, 로컬스토리지에 있는 유저 리스트의 마지막 id를 불러와서 그 id에 +1을 하는 방식으로 진행 되었다.
더미 데이터에 원래부터 id가 들어있는걸 이용한 방법이었다.
또한 상수를 적극적으로 활용해 보았고, 상수의 사용으로 코드가 얼마나 깔끔해 지는지 알 수 있었다.
가장 놀랐던 점은 8명이서 3팀으로 나누어져 개발을 해서, 굉장히 많은 파일과 기능들이 추가 되었는데, 생각보다 merge시 conflict가 많이 발생 하지 않았던 점이다.
서로의 분업이 잘 되었다는 증거인것 같아 뿌듯했다.
그리고 아침에 회의와 함께 시작해서 해산이 새벽 2~3시, 혹은 5시 넘을때도 있을 정도로 고생은 많았지만, 열정 있는 사람들과 함께라 좋다고 느꼈다.
물론 그렇게 나온 결과물도 만족스러웠다.
한가지 아쉬운 점은, 중간 제출이 끝나고 이어진 세션에서 함수형 컴포넌트는 HOC보다는 Route를 개조해서 사용하는 방식, hooks를 사용하는 방법등을 사용한다고 하셨는데, 우리가 이미 구현한 방법은 HOC 방식이라, 이 부분은 나중에라도 다른 방법으로 구현 해 보고 싶다고 생각하였다.
분명히 내 관점에선 쉬운 과제들은 아니었다.
같은 팀이 되신 분들도 모두 잘하시는 분들이라 조급해지기도 하지만, 나는 내 페이스대로, 하나의 과제가 있으면 무조건 하나 이상은 배우고 성장해 가려 한다.
물론 가능하다면, 그때마다 블로그등에 정리해 가려 한다.
쓰는 만큼 글쓰기도 늘것이니 말이다.
8명이 의사소통을 하면서 공통된 과제를 완수하는것이 쉬운 일은 아니지만, 난 그래도 팀은 정말 잘 만난것 같아 다행이라고 느꼈다.
물론 이 팀이 영원하지는 않겠지만, 그래도 남은 기간 화이팅 해서 서로 잘 이겨 나갔으면 좋겠다.
7ill-resource 화이팅!
이 팀이 영원하지 않다뇨.. 저는 우리 민기님과 칠리소스팀 영원히 함께 할 거예요~! 민기님 좋은 코드 짜주셔서 감사합니다! 민기님과의 협업은 항상 유쾌상쾌통쾌라구욧~! 앞으로도 킵 고잉!✌️