10월 2주차 주간회고 : CoStudo Project

22.10.03 월요일 🌧 😎 👍

✅ TODAY I DONE

#1 CoStudo - RadioGroup Components 찐 최종

지난 일주일 동안 Headless Component를 구현해보며 Style 과 관련된 부분보단 기능에 집중한다고 제대로 깊게 고민을 하지 않았더니 컴포넌트 사용자에게 input과 label을 가지고 있는 Option 컴포넌트에 어떻게 Custom Styling을 할 수 있게 할지에 대해 피드백의 피드백을 받았다.

 

지난 주 수, 목 동안 해당 부분에 대해서 이것 저것 props를 추가해보고 코드를 분리해보고 소스코드를 엎어라 뒤짚어라 하며 개선을 시도해봤지만 썩 마음에 들지 않고 오히려 코드만 복잡해졌다.

그러나 이미 일정은 딜레이 되었고, 금요일까지는 마무리 해야겠다 싶어서 얼추 최종본을 만들었는데 또 납득가는 피드백을 받았다. ^ -ㅠ)

 

지난 주 금요일(9/30), 피어세션에서 도니와 쨈에게 각각 "스타일 적용 방법이 하나로 통일되면 좋겠다(현 프로젝트에서는 styled-components), 어떤 방식이든 내가 구현한 컴포넌트에 맞게 사용자에게 스타일 커스텀 방식을 잘 정의하여 제공해주기만 하면 괜찮을 것 같다" 라는 리뷰를 받고 다시 초심으로 돌아가기로 마음 먹고 주말동안 그동안의 개선 작업 내역을 싹 날리고 Radio Button을 커스텀 하는 예제들을 찾아보며 어떤 식으로 기능을 지원해줘야 사용자가 편하게 사용할지를 고민해본 결과!

 

 

거의 일주일 간의 삽질이 무색하게 코드에 아무런 변화 없이 초기의 코드 그대로 가기로 결정을 내렸다.

초기 코드 상태로도 충분히 사용자가 만족 할 만한 커스텀 스타일링을 충분히 납득이 가고 익숙한 방식으로 제공 할 수 있다고 판단했기 때문이다. 또한 이후에 발생하는 추가적인 이슈는 그냥 그때가서 대응해도 괜찮겠다는 생각이 들었다.

 

도로..아미..타불...이지만...긍정적으로 생각해보면 다...스스로 납득하고 설명 가능한 코드를 짜기 위한 학습 비용이 아닌가 싶다.

그러는 한편 스스로의 코드에 자신이 없어 자꾸만 부족한 점을 찾고(특히나 리뷰를 받은 부분에 대해서), 불필요한 개선을 하려고 과하게 애를 썼다싶어 반성도 하게 됐다. 처음 해본다는 변명으로 팀 프로젝트라는걸 망각하고 학습에 너무 과하게 시간을 들인 점도 추가로 반성...ㅠㅠ!

 

결과적으로 어찌되었든 앓던 이는 빠졌고, 내 삽질이 프로젝트 일정 딜레이에 영향을 끼치기도 했으니 다음 작업은 보다 책임감을 가지고 가능한 빠르게 몰입해서 개발해보자! ^0^)9 아자!!

#2 주간회고 시작

원래 노션에 작성하던 TIL을 블로그에 주간회고 형식으로 작성하여 올리기로 했다!

노션에다 작성하니 너무 날름으로 쓰는 것 같아 예에에에전에 도니가 추천해준 방식대로 주간 회고 글을 하나 파서 업데이트 하는 식으로 회고를 작성해보려고 한다!

양식은 예전 Github 블로그에서 내가 정해 쓰던 양식을 비슷하게 가져왔다ㅎㅎ.

그런데 오랜만에 블로그에 글을 쓰려고 했더니 커스텀 스킨이...너무 눈이 아파서...@ㅂ@)ㅋㅋㅋ

임시로 기본 스킨 중에 아무거나 하나 골라서 바꿨다.

역시 깔끔한게 최고...

 

❌ BACK STEP

RadioGroup 컴포넌트의 주요 개선점에 대해 PR에 코멘트를 다는데 너무 오랜 많은 시간을 쓴 것 같다.

PR 코멘트는 적당히, 과하지 않게 요점만 딱 효율적으로 적도록 노력해보자....

아니면 개발할때 그때 그때 고민과 결과를 잘 정리해서 PR 쓸때 복붙 할 수 있게 하는 방법도 괜찮겠다...ㅠ-ㅠ)

 

💯 ONE STEP

유의미한 성과 없이 지지부진 끌어오던 RadioGroup을 떠나보냈다!!!!

 

---

22.10.04 화요일 ⛅️ 😑 🤜

✅ TODAY I DONE

#1 React Study

오늘 리액트 스터디 주제는 React.lazy, React.Suspense 였다.

코쿼를 하면서 웅성웅성하며 요즘 핫한 키워드라며 Suspense에 대해 들은게 있어서 느낌적인 느낌으로 뭔지는 알고 있었는데 한번도 안 써봐서 자세히는 잘 모르고 있었다. 그냥 로딩 처리를 쉽게 할 수 있게 도와주는 정도? 그러다 오늘 스터디를 통해 리액트 공식 문서를 읽으며 명확히 어떤 친구인지 아는 계기가 됐다.

오늘 스터디는 발표 형식으로 진행됐는데 자칭 Suspense 박사 학위를 소지하고 계시는 도트 박사님의 발표를 들을 수 있었다.

발표를 듣는데 준비를 정말 잘해오셨다고 느꼈다. 물 흐르듯이 진행되는 발표라 어렵다 느낄 내용인데도 집중이 잘 됐다.

다 듣고 도트께서 내가 생각 못해본 수준으로 깊이 파고 드시고, 그걸 잘 공유해주셔서 도트 박사님의 학위를 인정하기로 했다!

그리고 발표를 듣고 나니 아직 공식문서를 통해 Suspense를 찍먹만한 나는 앞으로 학습해야 할게 더 많구나 깨달았다.

특히나 오늘 자료 조사를 하다보니 React 18 버전에서의 주요 업데이트 중 하나가 Suspense를 이용한 SSR이라는걸 보게 됐다.

React 18 버전에 와서 단순히 로딩 처리를 선언적이고 효율적으로 해주는 것 이상의 기능을 하게 되었구나 싶었다.

Suspense를 찍먹 학습해봤더니 한번 제대로 써보고 싶은데 나중에 CoStudo 프로젝트에서도 Suspense를 활용할 수 있는 부분이 있을지 궁금하다. 기회가 되면 바로 써봐야지!!!! :P

 

#2 코드리뷰

현재 진행 중인 CoStudo 프로젝트에서는 모든 팀원의 코드 리뷰를 규칙으로 의무화하고 있다.

하나의 이슈가 끝나면 PR을 날리고 그 PR을 모든 팀원이 확인하고 리뷰를 달고 approve나 change request를 해주는 방식인데.

처음엔 모든 PR에 리뷰를 달아야 한다는게 조금 부담이 됐었다.

지금까지는 코드스쿼드를 통해 리뷰를 받는 입장이었는데, 내가 리뷰를 한다고!? (감히?!ㅋㅋㅋㅋ)

과연 팀원분들께 도움이 될만한 적절한 리뷰를 할 수 있을지 부담도 됐고, 팀원이 나 포함 FE 개발자 4명이라 3명의 코드를 전부 리뷰해야 한다는게 좀 부담이 됐는데...(반대로 3명에게 리뷰와 approve를 받아야 한다는 것도...)

막상 리뷰를 달아보니 쫌 재밌는 것 같다.

코드가 너무 완벽해서 할말이 없으면 어쩌지 싶었는데 그런 경우는 LGTM이라고 남기자고 룰로 정해서 부담도 적어졌고ㅎㅎ

리뷰를 통해서 여러 주제에 대해 의논을 하는게 꽤 재미있는 것 같다.

팀원분들이 다들 열심히 참여해주시는 덕분인 것 같기도 하고!

ㅎㅎ알찬 PR 코멘트들 ^_^)!!!

이게 다 우리 프로젝트의 자산이라 생각하니 절로 배가 부르는 느낌ㅎㅎㅎ

아무튼 결론은! 오늘 제이미의 PR에 코드 리뷰를 했다!

이미 다른 분들의 리뷰를 통해 깔끔하게 개선된 코드를 한발 늦게 리뷰를 해서 LGTM을 길게 풀어쓴 코멘트를 남긴 수준이었지만ㅎㅎ

제이미의 코드에서 인상깊었던 점은 특정 컴포넌트의 스타일링을 data-selected 라는 속성을 통해 적용할 수 있도록 구현하신 부분이었다. 딱 지난 주 금요일 제이미가 주셨던 스타일링과 관련된 피드백이 이런 느낌의 말씀이었구나 하고 제이미의 코드를 통해 온전히 이해할 수 있어서 좋았다!

 

#3 Headless Input 컴포넌트 설계

리액트 스터디를 준비하고 복습하느라 생각보다 늦은 시간에 작업을 시작했다.(AM 1시..)

지난 주에 얼추 설계를 했다 싶었는데 스크럼 때 validation 기능을 지원하려면 form 요소까지 신경써야 하니 잘 생각해야 한다는 파크의 충고를 받고 오늘 이미 너무 늦은 겸 개발은 내일하고 해당 부분의 설계를 다듬기로 했다ㅎㅎ....

 

❌ BACK STEP

어제 일찍 자려고 했는데 이거저거 하다보니 새벽 5~6시에 잠들어서...오늘 하루의 절반을 잠을 자면서 날렸다.

본격적인 하루의 시작을 오후 3시에 했다...ㅠ.

그 탓에 Input 컴포넌트의 개발 진도도 주춤....

 

💯 ONE STEP

운동을 시작했다! ^0^)9

지난 주 주말에 찬 바람 좀 쐐었다고 바아로 감기에 걸려 코맹맹이가 됐던 충격을 받아서 이젠 진짜 안되겠다 싶어서 매일 못해도 30분씩은 운동을 하기로 결심했다.

오늘은 가볍게 워킹머신을 이용해서 빠르게 걷기 30분을 했다!

일단 일주일은 이렇게 유지해보자!

 

---

22.10.05 수요일 ☁️ 😐 🤜

✅ TODAY I DONE

#1 Mob-Programming

오늘 CoStudo 프로젝트에서 2건의 몹 프로그래밍을 진행했다.

몹 프로그래밍이란 한 명의 드라이버와 여러 명의 프로그래머가 하나의 PC로 코딩 또는 문서화 작업을 진행하는 개발 방식으로 1 : 1 방식인 페어 프로그래밍을 1 : n 으로 확장시킨 형태의 프로그래밍이다.(출처)

코드스쿼드를 하며 대부분의 프로젝트에서 페어 프로그래밍을 경험해봤는데 모든 작업을 페어로 하면 시간이 너무 오래 걸리고 각자의 스케쥴도 맞추기 힘드니 이번 CoStudo 프로젝트는 각자가 이슈를 맡아 개발을 하다 도움이 필요하거나 함께 개발하고 싶은 기능이 있으면 몹 프로그래밍을 시도해보기로 했다. 언제쯤 처음 하게될까 싶었는데 오늘 쨈과 도니가 고민하고 있는 부분이 있어서 함께 고민하고 싶다 하셔서 프로젝트가 시작되고 3주만에 처음으로 진행을 하게 됐다.

 

오늘 주로 논의한 내용은 네이밍, type, 중복 로직의 리팩토링 방향이었다.

인상깊었던 부분은 제이미의 Row 컴포넌트를 보면서 children의 타입에 제한을 두기 위해 ReactElement를 사용하는 부분이었는데 나는 Radio Group을 구현 할 때 하위 컴포넌트로 어떤 타입의 컴포넌트가 들어올지 모르고 확장성을 고려하면 ReactNode로 해두는게 좋겠다 생각해서 children의 type을 ReactNode를 사용했다. 그런데 지금 개발중인 Headless 컴포넌트는 하위 컴포넌트로 어떤 컴포넌트가 들어올지 우리가 정해놓을 수 있는데, 너무 자유롭게 타입을 정해두는 것보다 딱 어떤 하위 컴포넌트만 들어올 수 있을지 제한을 걸어두는게 좀 더 안전한 컴포넌트를 만들 수 있을까란 생각이 들었다. (근데 그 이전에 ReactNode와 ReactElement의 명확한 차이점에 대해서도 좀 더 학습해야겠다 싶었고...)

 

그 다음은 도니의 중복되는 코드의 리팩토링 방향에 대한 고민이었는데 도니가 슬라이더를 구현하면서 좌우 이동 버튼을 비슷한 로직을 가지고 있지만 결과적으로 처리하는 결과는 달라 하나의 컴포넌트가 하나의 역할만 할 수 있게 별도의 컴포넌트(PrevButton, NextButton) 으로 구현했다. 하지만 이 방식은 각 컴포넌트 내부의 중복 로직으로 인해 두 버튼이 함께 사용하는 옵션이 수정될 경우 두 컴포넌트 모두 수정해야 해서 유지보수에 어려움이 예상이 됐다. 그렇다고 내부의 중복 로직을 함수로 빼거나 하나의 컴포넌트로 합치려 했더니 함수의 경우 인자도 많고, 두 방식 모두 조건에 따라 분기 처리도 해줘야 하고 그러다 보니 크기가 너무 커져서 문제였다. 어떤 방식이든 나름대로의 장단점이 있어서 결과적으로는 도니가 처음 생각하셨던 방향으로 진행하는 것으로 했다. ^_^)b

 

오늘 진행한 몹 프로그래밍은 다같이 개발을 하는 것보단 소소한 리팩토링의 방향을 함께 정하는 느낌이었지만 재미있었다ㅎㅎ!

 

#2 Headless Input 컴포넌트 개발 중

오늘 Input 컴포넌트를 개발하면서...제어 컴포넌트 비제어 컴포넌트라는 딴길로 새버렸다.

적당히 구현하면 할 수 있지만, 잘 구현하려 하다 보니 자꾸만 깊은 학습으로 빠지려는 것 같다.

그래도 일단 오늘 생각했던 부분까지는 진행을 한 것 같다.

꼭...꼭 내일 PR 보낸다...ㅠ-ㅠ)9

 

❌ BACK STEP

ㅎㅎ운동...가벼운 산책으로 떼웠다.

아침 스크럼을 끝내고 낮잠을 자버렸다.

 

💯 ONE STEP

무난히 개발했다.