mystery

25년의 이도현

Creative_Lee — Wed, 31 Dec 2025 16:41:53 +0900

1년만에 쓰는 글이라 어색하면서도 설렌다.

말 나온김에 최근 2년동안 단 하나의 개발 관련 글을 작성하지 않은 나 자신에 대한 반성으로 회고를 시작해보자.

2년간 조용했던 블로그

취업을 하고 나서부터는 갖은 핑계를 다 갖다 붙였다.

'요즘 세상에 AI가 다 찾아주는데, 내가 가진 지식을 글로 작성하는게 어떤 의미가 있겠냐'는 핑계

'회사 일하기도 바쁜데 언제 글을 쓰냐'는 핑계

'사실은 그냥 귀찮다'는 진심

다 납득 가능하다.

가진 지식을 전하는 역할로는 의미가 없을 수 있겠다.

회사일 만으로도 충분히 바쁠수 있다.

정말 귀찮을 수 있다.

하지만, 처음 개발 블로그를 개설했던 목적은 '학습과 성장' 이었다.

학습한 내용을 스스로 정리하고 다른 누군가에게 설명하는 행위를 블로그 포스팅으로 대신했다.

애초에 지식을 전하기보다는 내가 아는 것을 단단히 굳히는 역할로 활용했다.

한창 개발 공부에 전념하던 시기에도 지금처럼 충분히 바빴다.

그때도 정말 귀찮았지만 글을 작성했었다.

이제와서 아쉽다.

실무에서 겪었던 다양한 사건 사고들이 희미한 기억으로만 남아있다.

그때의 경험이 하나의 포스트로 남아있었다면... 하는 마음이 든다.

아쉬웠다면, 다음에는 아쉽지 않게 행동하면 된다.

내년에는 사건 사고들 중 일부라도 블로그에 남겨보자!

우테코 7기 FE 리뷰어 활동

우테코 7기 FE분들의 리뷰어로 지원 및 선정되어 4개월간 활동했다.

학습 과정에서 리뷰어에게 받는 코멘트 하나하나가 얼마나 소중하고 간절한 지 5기 수료생으로서 잘 알고 있기에 이 부분을 녹여 지원서를 작성했고, 이런 진심이 통했는지 리뷰어로 선정되었다.

진심을 다하기

우테코의 교육과정은 총 5개의 레벨로 구성되어있으며, 리뷰어는 레벨 1과 2에서 리뷰이들의 미션(과제)를 리뷰하는 역할을 담당한다.

미션은 총 8개이고 1개의 미션마다 리뷰어에게 3~4명의 리뷰이가 배정되므로 거진 20명 이상의 교육생과 코드를 사이에 두고 마주하게 된다.

솔직히 교육생들은 첫 리뷰에 달린 코멘트만 봐도 이것이 정성이 들어간 리뷰인지, 아닌지 다 알 수 있다.

반대로 리뷰어들도 자신이 남긴 리뷰가 리뷰이에게 어떻게 느껴지고 전달될 지 알 수 있다.

때문에 스스로에게 부끄럽지 않은 리뷰를 남기고 싶었다.

이렇듯, 리뷰이 미션 코드의 A~Z 까지 모든 부분을 다 이해하고 리뷰하려고 하다보니 1인당 3시간은 기본으로 투자해야 했다.

(훗날, 리뷰어 회고 모임에서 이야기해보니 1인 리뷰 완료 시간은 평균 30분~60분 남짓이었다.)

평일/주말 할것없이 거진 매일 새벽까지 코드를 읽고 코멘트를 달았다.

늦은 새벽, 몰려오는 피곤에 '하루만 늦어진다고 하고 잘까...' 싶다가도 꼭 시간을 맞춰 리뷰를 드렸다.

내가 교육생이었을 때 리뷰를 보고 아쉬웠던 마음, 다른 교육생들은 다 받았는데 나만 못받아서 기다렸던 기억들을 생각하면 양심이 찔렸다.

더욱 더 진심을 다 할 수 밖에 없었다.

함께 성장하기

몇몇 교육생 분들은 그시절 나처럼, 내가 작성하는 코드가 정답이 맞는지를 확인하고 싶은 마음이 있는것 같았다.

이에 대해서는 정답인지 아닌지를 결정해주기 보다, 옳은 방향성이라고 생각한다면 왜 그러한지 이유를 묻고 함께 확인하는 방식의 리뷰를 주고 받으려고 했다. PR을 벗어나 개인 DM이나, 구글밋등으로도 최대한 대화를 나누려고 노력했다.

이 과정으로 나 또한 관습처럼 작성하던 코드들이 왜 더 나은 방향인지, 왜 더 좋은 코드라고 불리는지 생각할 수 있었다.

리뷰어 활동 마무리 및 느낀점

리뷰어 활동에서 가장 뿌듯했던 순간이라면 단연 교육생들이 남긴 평가를 전달 받아 읽었던 순간이다!

레벨1

레벨2

교육생들은 리뷰어의 어떤 부분이 좋았고 나빴는지 정말 솔직하게 피드백한다.(나 또한 그랬었고...)
'팀원으로 함께 일할 수 있는 기회가 된다면, 같이 일하고 싶은 리뷰어인가?(10점)' 문항에 대해서는 최하 4점까지 남긴것을 본것 같다.

노력했던 부분들이 '팀원으로 함께 일하고 싶은 사람'이라는 칭찬과 함께 피드백 내용에 고스란히 담겨 있어서 행복했던 순간이었다.

리뷰어중 점수 합산 1등도 너무 뿌듯했다.

이렇게 리뷰어 활동을 하면서 느낀점을 정리해보자면,

'함께 배우고 성장할 수 있는 사람이 되는 것이 중요하다는 것' 과 이를 위해 '진심으로 동료를 대해야 한다는 것' 이다.

리뷰어 활동에 도움주신 코치분들과 만났던 리뷰이 분들께 정말 감사하다.

결혼

23살부터 7년 넘게 만난 친구와 혼인신고를 했다.

행복하기도 하고 이름 모를 책임감에 무겁기도 하다.

이러나 저러나 우린 행복하게 잘 살거다.

지금처럼.

회사와 커리어

어느덧 근속한지 2년이 되었다.

우여곡절이 있었지만, 지금의 팀이 일하는 방식이 맘에 들고 재밌다.

동료들과 다양한 의견을 주고 받으며 서비스를 성장시키는 과정이 즐겁다.

앞으로도 지금처럼 서로가 서로를 믿으며 나아가면 좋겠다.

여러 부분에서 성장했지만, 특히 인격적으로 많이 성장한 25년이 아니었나 싶다.

원래도 사람과의 관계에서 장난치는 법이 없지만, 진심의 중요성을 다시 알게되었다.

26년에는

가식없이 진심으로 대하자

온전히 나아가자

행복하자!

24년의 이도현

Creative_Lee — Wed, 1 Jan 2025 17:38:09 +0900

연말 회고를 작성할 때면 참 많은 생각을 하게 된다. (절대로 하루 뒤면 30대가 되어서 그런 건 아니다. 아무튼 아니다)

오랜만에 글을 쓰려니 생각이 많아져 아무것도 못 적고 있길래 아무거나 끄적이며 시작해본다.

일의 본질

신입 개발자로 보낸 첫해기에 가장 먼저 일에 대한 생각을 정리해 본다.

문제를 가장 단순하고 효율적인 방법으로 해결한다.

이를 위해 문제를 올바르게 정의한다.

1년차 뉴비 개발자가 생각하는 개발업의 본질이자 진리이다.

실무에서 다양한 문제를 마주하며 이를 올바르게 정의하고 해결하는 것이 얼마나 어려운 일인지 알게 되었다.

간단한 문제임에도 굳이 복잡하게 돌아간 적도 있었고, 간단한 문제라고 생각했는데 파면 팔수록 복잡하게 얽혀있을 때도 있었다.

수많은 자충수로 뒤통수를 처맞고 다시 처음으로 돌아가고를 반복하며 깨달음을 얻는 중이다.

이 역량에 따라 문제를 바라보는 시선이 달라질 것이고 해결할 수 있는 문제의 범위가 넓어질 것이라고 생각한다.

자연스럽게 주어지는 권한과 책임 또한 많아지겠지.

열심히 살까? 말까?

'열심히 살까? 말까?' 고민하며 '불편'한 '평온'을 즐긴 한 해

24년은 이렇게 정리하면 되겠다.

올해 초, 취업 이후 모 코치님께 식사를 대접하며 하소연 아닌 하소연을 늘어놨었다.

뭐 대충 요약하면, '취업 후에도 여전히 열심히 살아야 하는데, 지금은 그냥 흘러가는 대로 살고 있다. 어떻게 하냐?'는 답정너 질문이었다.

코치님은 '열심히 살까? 말까?'라는 문구가 적힌 와펜을 선물해 주시며, 그런 대로도 살아보라는 우문현답을 해주셨었다.

원하는 것을 이루고 바라는 삶을 살기 위해서는 의식적인 노력이 필요하다.

비교를 떠나, 당연하다. 다른 사람들보다 더 큰 노력을 해야 비로소 가까워진다.

하지만 올해는 취업이라는 큰 산을 하나 넘고 나서는 별다른 목표를 세우지 않았다.

스스로의 나태함을 꾸짖으며 자책하면서도 그냥 적당히 흘러가는 하루하루가 나쁘지 않았다.

회사 업무 열심히 하고, 사내 스터디 몇 개 참여해서 강제로 공부도 조금 하고, 잊혀질만 하면 한번 씩 운동하고.

'뭔가 이상한데...' 싶다면 정확하다. 그냥 내가 그런 사람이다.

나태함을 인지하면서도 쉽게 목표를 세우지는 않는다.

적당히 자책하며 또 나름대로 밀도 있는 하루, 일주일을 보내고 그렇게 흘러가는 삶에 만족한다.

이런 싸이클이 여러 번 돌다 보면 버닝 타임이 오고 그 때 목표와 향해 미친 듯이 달려 나간다.

굳이 따지면 건강한 사이클은 아닌 것 같지만, 어쨌든 돌아가고 그 안에서 발전이 있으니 아무렴 어떤가.

원하는 것을 얻기도, 잃기도 했다.

있다가도 없었고, 없다가도 있었다.

끝이 어디든 데굴데굴 굴러서 도착할 수만 있다면 된다.

행복을 잃지 말고 지금처럼 나아가자!

정말 고생 많았고 2025도 힘내보자!

신입 개발자 이도현 시작!

Creative_Lee — Sat, 3 Feb 2024 15:08:14 +0900

이 글은 프론트엔드 개발자 취업에 도움되는 내용이 아니다.

신입 개발자로 취업했다고 호들갑떠는 글이니, 키워드로 유입된 분들은 돌아가셔도 좋다.

3년

21년의 이도현

이런 글을 쓴다는게 어딘가 상당히 어색하고 부끄럽기도 하다. 초등학교 시절 쓰던 일기 이후에는 내 생각을 정리하는 글을 써본적이 없기 때문이다. 이곳에는 정말 하고 싶은 아무 말이나 다

think0wise.tistory.com

22년도 1월 1일.

프로그래밍을 독학한지 1년이 지난 시점에 작성한 회고이다.

글의 끝에는 본격적으로 학습을 해보겠다며 다니던 회사를 그만두겠다 선언하고 있다.

22년의 이도현

다니던 회사를 그만두고 프로그래밍 공부에 전념해야겠다고 다짐한 후 벌써 1년이 흘렀다. 22년을 마무리하는 시점에서 지난 1년 동안 이루어 낸 것들과 아쉬웠던 부분을 정리해 보고, 23년 목표

think0wise.tistory.com

22년도 12월 30일.

회사를 그만두고 프로그래밍에 본격적으로 몰입하며 보냈던 22년을 돌아본 회고이다.

우테코에서 좋은 동료가 되고 싶다는 작은 소망, 나아가 취업을 할 수 있는 좋은 개발 실력을 갖추길 기대하는 모습이다.

23년의 이도현

우아한테크코스와 함께한 23년 분명 많은 것을 이루었을 23년 처절하게 노력했던 지난날을 돌이켜 보자. 우아한테크코스 시작 합격 메일을 받고 나서 곧바로 알바를 구했고 열심히 서빙을 했다.

think0wise.tistory.com

24년 1월 1일.

우테코 생활을 통해 더 단단한 개발자가 되어가는, 다사다난 했던 23년을 돌아본 회고이다

원하는 회사에 취업하겠다는 의지와 함께 더욱 더 정신없는 24년을 보내길 기대하는 모습이다.

취업

그로부터 대략 2주가 채 지나지 않은 시점에 한국신용데이터에 최종 합격 및 오퍼를 진행하고 합류하게 되었다.

3년 동안 차곡차곡 쌓아온 내 개발 능력.

좋은 동료를 만나 내 자신을 돌아볼 수 있었던 우테코.

리쿠르팅데이로 우연히 알게 된 좋은 회사와 지원 기회.

내 인터뷰를 긍정적으로 평가해준 회사 구성원들.

모든 것들이 잘 맞물리며 운이 따랐고, 그 운을 잘 잡았다고 생각한다.

일 잘 하는 개발자 VS 개발 잘 하는 개발자

둘 중에는 우선 일 잘 하는 개발자를 목표로 한다.

어느 회사를 가든 기본이라고 생각하기도 하고... 신입은 쫌 굴러야 되지 않겠나.

당장은 사수의 업무를 최대한 분담해서 사수의 야근을 줄이고?!

나는 빠르게 적응하는 윈윈 구조를 만드려고 노력중이다.

정신없는 24년

신입 개발자가 된 이 시점에 내가 어떤 한 해를 보내고 싶은지 생각해 봤는데, 잘 모르겠다.

그냥 지금처럼 '정신 없음'으로 꽉찬 24년이 됐으면 좋겠다. ㅋㅋㅋ

(벌써 첫 출근으로부터 2주가 지났다는게 믿기지 않는 걸 보면 무난하게 이뤄질듯 싶다... ㅋㅋㅋㅋㅋㅋ)

23년의 이도현

Creative_Lee — Mon, 1 Jan 2024 01:59:00 +0900

우아한테크코스와 함께한 23년

분명 많은 것을 이루었을 23년

처절하게 노력했던 지난날을 돌이켜 보자.

정말로 고생이 많았구나

우아한테크코스

시작

합격 메일을 받고 나서 곧바로 알바를 구했고 열심히 서빙을 했다.

알바와 부모님 찬스로 생활비를 구했고 서울 고시원으로 향했다.

태어나서 처음 공부를 위해 금전적 지원을 해줄 수 있냐는 말에 적잖이 당황하면서도 알겠다 말하던 아빠 얼굴이 선하다.

덕분에 이 철부지는 무사히 1년을 버텨낼 수 있었다.

고시원

무개념 입주자로 인해 고시원에 대한 추억은... 뭐 그리 좋지는 않다.

제발 오늘은 조용히 잠만 자자고 기도했지만, 침대에 누운 지 5분 만에 들려오는 온갖 소음에 허탈하게 웃어버린 적도 있다.

그래도 뭐... 옥상 실외기 위 판자에 올려놓고 먹던 라면은... 참 좋았다.

라면이 뭐라고 ㅋㅋㅋ

레벨 1, 2

우아한테크코스의 레벨 1, 2 과정은 작은 프로그래밍 미션을 수행하고 선배 프로그래머에게 코드 리뷰를 받는 식으로 진행된다.

시작은 분명 패딩이었는데, 어느새 형광색 반바지를 입고 있었고 그렇게 레벨 1, 2가 끝났다.

이 기간에는 개발도 개발이지만, 리뷰어와의 소통이 더 기억에 남는다.

단 하나의 코드라도 이야기 나눠보기 위해 뒤죽박죽인 생각을 정리하고 어떻게든 글로 표현하려 노력했기에 그런 것 같다.

실제로 PR에 남긴 내용 외에도 무수히 많았던 고민을 했겠지만 기억나는 게 거의 없다.

레벨 3, 4 그리고 S-HOOK

어려서부터 얄팍하거나 불안정한 상태의 지식을 다른 사람에게 알려주는 것을 좋아했다.

조금만 깊이 있는 사람을 만나면 바로 밑천이 드러난다.

그런데도 계속 알려주다 보면 어느 순간 스스로 정리되는 때가 있다. 혹은 깊이 있는 사람이 정정해 주거나 더 나은 방식을 알려주곤 한다.

이렇게 정리된 상태의 온전한 지식으로 다시 알려주면서 공부하곤 했다.

난 테코톡으로 우테코의 존재를 알게 되었다. 사람들에게 우르르 둘러싸여 개발 관련 지식을 전파한다. 사람들은 경청한다.

테코톡은 우테코의 환경이 부럽다고 생각했던 이유이자 지원을 결심한 계기이기도 하다.

결과적으로는 1번의 테코톡과 1번의 미니 발표를 진행했다.

테코톡외의 작은 발표를 더 많이 못한것이 아쉽다.

근데 뭐... 하려고 했다면 다른 하나를 포기해야 하지 않았을까?

하고 싶은 무언가를 밤새 해본 적이 있는가?

새벽에 떠오르는 해를 보고 뿌듯했던 적이 있는가?

내 인생에는 지금까지 3번의 큰 도전이 있었는데, 신기하게도 매번 떠오르는 새벽 해를 봤다.

잠을 줄여 무언가를 이루기 위해 노력하는 사람에게 이거라도 보고 힘내...라는 의미가 아닐까? ...하하

새로운 사람에 대한 호기심이 많고 사람을 사귀는 것을 좋아하는 성향이라 팀 프로젝트에 대해서는 걱정이 없었다.

참... 이렇게 오만한 생각이 따로 없다.

코드는 마치 필터와 같았고, 이를 뚫고 생각을 전달하는 것은 쉽지 않았다.

코드를 가운데 낀 상태로 사람과 대화를 하다 보면, 내 생각은 상당 부분 걸러져 의도와는 다르게 전달되곤 했다.

작성 의도와 생각은 온전히 전달하면서 독성 말투, 부정적 스탠스와 같은 좋지 않은 것들만 잘 걸러낼 줄 알아야 한다.

앞으로의 개발 인생에서도 어쩌면 가장 중요한 부분이 되지 않을까 싶다.

정말 과분한 팀원을 만났고 그들의 많은 이해와 배려 덕분에 보완해야 할 부분과 더 키워나가면 좋을 부분을 명확하게 인지할 수 있었다.

너무나 감사하다.

사진을 보고 다시 한번 느꼈다.

나는 내 결과물을 자랑하고 인정받는 것을 정말 좋아하는 사람이다.

인정을 다음으로 나아가기 위한 에너지원으로 사용한다.

인정 외에 다른 에너지원을 찾으려고 노력한다면 더 나은 사람이 될 것 같다.

'우리의 목표는 킥보드를 만드는 거야 !!'

킥보드로 각인된 애자일... 팀 프로젝트의 전부였다고 생각해서 담았다.

레벨 5

맨날 여기저기 신청하면 다 떨어져서 가보지 못한 컨퍼런스도 갔었다.

열정을 가진 사람들이 이렇게나 많구나. 그리고 무대에 있는 저 사람 정말 대단하고 멋있구나.

한참 운동을 많이 할 때, 바디빌딩 대회를 구경하러 가서 느꼈던 가슴 뛰는 기분을 또 한 번 느낄 수 있었다.

우테코를 하면서 6시 퇴근 시간이 다 되어도 집에 안 가는 사람들이 꽤나 많았다.

나 역시 그중 하나였고 그냥 자연스레 같이 공부하던 몇 명을 내 맘대로 패잔병이라고 불렀다.

사실 그 누구도 패배하지 않았다. 누구보다 열심히 하고 있는걸?

근데 이미 네이밍이 정해져 버려서 '잔병이들'이라고 귀엽게 부르긴 한다.

(패잔병 네이밍 때문에 우형 전환 다 떨어진 거 아니냐고 욕먹을 때는 살짝 아찔하긴 했다.)

취준은 단어만으로도 뭔가 측은하다. 실제로 많은 사람들이 힘들어했다.

나도 마찬가지고.

이건 내 최애짤인데, 커피 두 잔으로 풀 도핑을 했지만 졸고 있는 내 모습에 짠한 마음과 열심히 했다는 생각이 들어 좋아한다.

마무리

좋은 동료들과 함께해서 너무 좋았다.

그리고 정말 재미있었다.

후배라는 이유만으로 많은 부분을 도와주고 알려주셨던 선배 기수분들과 리뷰어 분들 너무 감사하다.

또 어린애처럼 징징거리는 거 다 받아주시고 응원해 주신 코치님들 너무 감사하다.

다들 고생 많았고 24년도에는 원하는 것 다 이루었으면 좋겠다.

24년에는 어떻게?

사실 23년에 아쉬운 것, 못 이룬 것 천지이다.

근데 그 모든 것을 다 이룰 수 있었냐? 하면 절대 아니다. 이건 확실해.

그래서 그냥 넘어가려 한다. 충분히 열심히 살았으니깐.

24년도에는 원하는 회사에 취업하고 싶다.

그리고 나 자신에게 정말 순수한 휴식과 안정을 주고싶다.

좋은 동료를 만나고 싶고 당연하지만 맡은 일 잘 쳐내는 사람이 되고 싶다.

또 재미있는 서비스를 개발하고 발전시키며 성장하고 싶다.

우테코와 같이, 아니 더 정신없는 한 해가 되기를 소망한다.

정말 고생 많았고 2024도 힘내자.

진짜 개구장이 그 자체네

Tanstack Query, TkDodo 도아일체 (1)

Creative_Lee — Fri, 22 Dec 2023 15:20:02 +0900

https://tkdodo.eu/blog/practical-react-query

Practical React Query

Let me share with you the experiences I have made lately with React Query. Fetching data in React has never been this delightful...

tkdodo.eu

2018년경 GraphQL과 아폴로 클라이언트가 핫하던 시기에 사람들은 리덕스를 대체할 것이라며 난리법석이었다.

나는 전혀 이해하지 못했다 '데이터 패칭 라이브러리가 어떻게 전역상태 관리라이브러리인 Redux를 대체하지?'

아폴로는 데이터 패칭 기능뿐만 아니라, 서버 데이터 캐싱도 지원했다.

여러 컴포넌트에서 동일한 쿼리를 사용하면 캐싱된 데이터를 제공하는 기능이 있었다.

당시 사람들은 서버 데이터를 전역으로 사용하기 위해 리덕스를 사용하고 있었다.(불편함을 느끼면서도?)

자연스럽게 서버상태를 클라이언트 상태랑 별다를 것 없이 취급했었던 것 같다.

생각해보니, 서버상태는 화면에 표시하는 것 외에는 딱히 사용하지 않더라.

화면에 표시할 상태를 서버 상태로 따로 분리한다고 하면, 막상 진짜 전역 상태는 몇 개 없더라.

그제야 사람들이 Redux를 대체할 수 있다며 열광했던 것을 이해했다.

나는 아폴로가 제공하는 로딩/오류 상태, 데이터를 가져오는 방식이 부러웠다.

REST API에도 비슷한 것이 있다면...

React query 기본옵션

쿼리 옵션의 기본값은 이미 완벽하게 설정해두었지만, 기호에 따라 커스텀할 수 있다.

또 사람들이 흔하게 실수하는 쿼리 옵션의 기본값에 대해 몇 가지 조언을 하려고 한다.

1. staleTime의 기본값은 0인데, 그렇다고 매 랜더링마다 queryFn을 호출하지 않는다!!

만약 예상치 못한 refetch가 발생한다면, 아마 refetchOnWindowFocus 때문일거다.

이 옵션 덕분에 사용자가 탭이동 후 복귀 했을 때, 로딩 상태 없이 자연스럽게 refetch를 시도한다.

데이터의 변경사항이 있다면 캐시와 화면 데이터를 업데이트 한다. 랜더링을 다시 한다는 말이지.

없다면 그대로 둔다.

2. gcTime과 staleTime 혼동하지 마라.

staleTime: 쿼리가 fresh -> stale 로 전환되기까지 시간이다.
쿼리가 fresh면 데이터는 캐시에서 가져오는거다. 네트워크 요청 없이!

쿼리가 stale 이여도 캐시의 데이터를 가져와 보여준다. but 너가 설정한 조건에 따라 백그라운드에서 refetch할 수도 있다.

gcTime: inactive 상태의 쿼리가 delete 로 전환되기까지 시간이다. gcTime이 시간이 지나면 캐시는 삭제된다.

해당 쿼리를 사용하는 모든 컴포넌트가 언마운트되면 inactive상태가 된다.

보통 옵션중 뭔가를 바꾸고 싶다는 생각이 들면, 대부분 staleTime일 거다.

query key를 dependency array 라고 생각해!

왜냐면 React query는 query key가 변경될 때 마다 refetch를 하거든!

자 생각해봐.

대부분의 경우에 너는 queryFn에 넘기려는 인자가 바뀔 때, 새로운 데이터를 불러오길 원할거야.

보통 인자는 상태로 관리되겠지.

이때 queryKey에 그 인자를 추가해주는 것 만으로도 새 데이터를 fetch할 수 있어.

'상태(인자)가 변경되면, effect로 fetch를 해주세요.' 라는 코드를 작성할 필요가 없다는거야.

queryKey만 변경해주면 된다는거지!

난 queryFn에 전달하는 인자를 queryKey에 포함하지 않았던 적이 없는 것 같아.

거의 모든 상황에 함수의 인자를 queryKey에도 포함했어.

하드로딩이 보고싶지 않다면, initialData

간단한 투두 앱을 예시로 탭 컴포넌트가 있다고 가정할게.

탭 전환마다 [모든 일정] / [완료 일정]을 각각 fetch 한다고 하면, 첫 탭 전환시에는(query 캐시가 없을 때) 하드 로딩 상태가 돼.

즉, 스피너가 표시될 수 있다는 거지.

스피너보다 더 앞서나가서 로딩 상태를 아예 안 보여주고 싶다면, initialData 옵션을 사용할 수 있어.

export const useTodosQuery = (state: State) =>
  useQuery({
    queryKey: ['todos', state],
    queryFn: () => fetchTodos(state),
    initialData: () => {
      const allTodos = queryClient.getQueryData<Todos>([
        'todos',
        'all',
      ])
      const filteredData =
        allTodos?.filter((todo) => todo.state === state) ?? []

      return filteredData.length > 0 ? filteredData : undefined
    },
  })

queryClient로 부터 [모든 일정] Query를 가져오고 클라이언트에서 필터링 한 결과를 미리 보여주는거야.

[완료 일정] fetch가 백그라운드에서 완료되면 리스트는 업데이트 되겠지.

적절한 상황에 사용해 보도록 해.

서버 상태와 클라이언트 상태를 나눠라!

useQuery로 가져온 서버 데이터를 로컬 state에 넣지 마.

React Query가 수행하는 모든 백그라운드 업데이트를 암시적으로 무시할거야.

그런데 만약 데이터의 기본값을 가져온 후에 랜더링 하려는 것 같이 명확한 목적을 가지고 있다면 사용해도 좋아.

대신 이 경우에는 첫 1회 fetch 외에 백그라운드 업데이트가 일어날 필요는 없겠지?

이럴 땐 staleTime을 Infinity로 설정해서 캐시를 무한대로 설정해서 불필요한 업데이트를 막아보자.

enabled 옵션으로 많은 것을 할 수 있다.

1. 종속 쿼리

종속 쿼리는 A api에서 가져온 결과값으로 B api를 보내야 하는 경우를 말해.

옵션으로 A query의 결과값을 성공적으로 가져왔을 때에만 B query를 실행하도록 할 수 있어.
(다만 네트워크 워터폴이 발생하니, 가능하면 병렬적으로 가져올 수 있도록 api를 구성하는게 좋아. 항상 가능한건 아니겠지만...)

2. 쿼리 on/off

refetchInterval 옵션으로 데이터 폴링을 하고있는 경우라고 가정해봐.

만약 모달이 열려있다면, 백드롭 뒤쪽 화면은 업데이트 되지 않는게 자연스러울거야.
이런 경우에도 쿼리를 중단할 수 있어.

3. 사용자 입력을 기다렸다 실행하기

쿼리키에 필터 옵션들을 포함시키면서도, 유저가 필터기능을 사용하지 않는 동안에는 쿼리를 비활성화 할 수 있어.

const Test = () => {
  const [filterOption, setFilterOption] = useState(null)
	
  const { data } = useQuery({
    queryKey: ['', filterOption],
    queryFn: () => {...},
    enabled: filterOption !== null
  })

  return <div>{data}</div>
}

4. 사용자 입력 후엔 쿼리 비활성화 하기

위 예제와 비슷해. 서버 데이터 보다 우선시 해서 보여줘야하는 초기 데이터가 있을 때 유용해.

query Cache를 로컬 상태로 사용하지 말것.

쿼리 캐시(queryClient.setQeuryData)는 낙관적 업데이트를 해야 하거나,

mutation후에 서버에게 받은 데이터로 덮어 써야할 때에만 사용해야해.

기억해! 모든 백그라운드 refetch는 기존 데이터를 덮어 쓸 수 있어.

커스텀훅을 만들어라.

이미 익숙하겠지만, 단지 useQuery 하나를 래핑하는 용도라도 커스텀 훅은 의미가 있어.

실제 데이터 패칭 코드는 ui 밖으로 빼면서, useQuery 호출에 대해서는 co-location을 유지할 수 있지.

쿼리키도 하나의 파일에서 관리할 수 있고 말이야.

옵션을 변경해야한다거나, 데이터의 형태를 변경해야할 때에도 한 곳에서 해결할 수 있어.

여기까지 도도형의 실전압축 reactQuery 포스팅 1편을 읽고 정리해봤다.

역시나 아주 달달한 정보가 많다.

평소에 몰랐던 부분, 잘못 사용하고 있던 부분을 알 수 있었다.

staleTime 0 이라고 리랜더링 마다 쿼리쏘는게 아니라는 것, 쿼리키를 디펜던시 어레이로 바라보는 시선,

initialData, enabled 옵션의 올바른 사용예시까지...

아주 좋구만. 음 좋아.

아직도 역시나 기본이 중요하구만.

Tanstack Query, TkDodo 도아일체

Creative_Lee — Fri, 15 Dec 2023 21:32:25 +0900

라이브러리를 학습하다보면, 공식문서만큼 해당 라이브러리에 대한 철학이 잘 드러난 곳이 있다.

바로 컨트리뷰터의 블로그...!

아무래도 잘 알려진 컨트리뷰터들은 개인의 철학보다는 해당 라이브러리의 철학을 기반으로 글을 작성하는 경향이 있다.

자신이 곧 라이브러리가 되어버렸다고도 할 수 있겠다.(Dan Abramov형 처럼...)

인간 Tanstack Query, TkDodo형의 블로그에 총 23편의 장편으로 구성된 실전 압축 팁이 모여있다. ( 도도형이 직접 언급)

도도형은 어떤 생각을 가지고 라이브러리를 만들었으며, 각 꿀팁들에 대한 생각을 흡수해보자.

이번 시리즈는 도도형의 꿀팁들을 읽고 정리하며 내실을 다지는 포스팅이 될 것 같다.

시작!

기본이 중요하다!

우테코 레벨3, 4 학습 내용 총정리

Creative_Lee — Mon, 2 Oct 2023 13:29:07 +0900

레벨3, 4 학습 내용 총정리

팀 프로젝트 S-HOOK과 함께한 레벨3, 4

소중한 기억을 정리해보자!

그래서 뭘 배웠어? ‍♂️

개인적으로 몰입했던 키워드는 다음과 같다.

프론트엔드 개발 환경
프론트엔드 최적화 + AWS
찐~한 협업과 찐~한 소프트 스킬

1. 프론트엔드 개발 환경

팀 프로젝트를 위한 개발 환경을 밑바닥부터 하나하나 설정했다.

오만가지 설정법과 설명이 있는 webpack docs를 보고있자면 토가 나오는 것 같았지만 아무렴 어때!

개발 환경 구성에 필요한 기술들을 접하고 이해하면서 프론트엔드 개발환경의 큰 그림을 이해하게 됐다.

webpack, babel, eslint, TS, react... 이외에도 자잘한 부수 기능까지...!

입맛대로 환경대로 골라서 적용하는게 점점 재미가 붙었다.

'아는 만큼 더 잘 쓸 수 있는 번들러의 세계'라고 할 수 있을 것 같다.

CRA와는 이별이다. 안녕...!

2. 프론트엔드 최적화 + AWS

최적화. 단어만 들어도 묵직하고 엄청난 지식과 스킬이 있어야 할 것 같다.
하지만 막상 부딪혀 보면 별거 없고, 하나도 어렵지 않다.
알아야 할게 많을 뿐.

레벨4 무렵에는 최적화 미션을 통해 프론트엔드에서 고려할 수 있는 전반적인 최적화 방법에 대해 배웠다.

2-1. 요청 크기 줄이기

번들 크기, 정적 파일 크기 최적화 등등 요청의 크기를 줄이는 방법은 다양하다.

minify, uglify
소스맵 타협
css파일 추출
gzip, brotli 와 같은 압축 포멧 적용
정적 asset의 사이즈 줄이기 ex) 이미지, 비디오

이외에도 다양한 방법으로 요청하는 리소스의 크기를 줄일 수 있다.

2-2. 필요한 것만 요청하기

만약 당장 필요하지 않다면 요청을 하지 않도록 하면 된다.

code spliting
Tree shaking

2-3. 같은 건 매번 새로 요청하지 않기

다시 요청할 필요가 없다면 안 하면 된다.

CDN(cloud front), 브라우저 캐싱
api 응답 캐싱

2-4. 최소한의 변경만 일으키기

변화가 일어나야 하는 부분만 변경시키는 것이 당연하다.

React.memo
Repaint, Reflow 최적화

2-4. AWS 환경 이해

EC2, S3, CloudFront 를 직접 구성하여 프로젝트를 배포하고, 캐시 정책을 설정하면서 AWS의 각 환경에 대한 이해도가 높아졌다.

다음 프로젝트에서는 혼자서 거의 모든 환경 구축이 가능한 수준이 되었다!

3. 찐~한 협업, 소프트 스킬

단언컨데 가장 성장한 부분이 아닐까 싶다.

평소 새로운 사람들을 사귀는 것을 좋아하고, 서글서글한 성격을 가져 사람과 소통하는 것에 자신있었다.

물론 코드를 사이에 두고 대화해보기 전까지 말이다.

찐한 협업을 진행하면서, 내 코드에 대한 확증편향을 내려놓을 수 있었다.

이게 좋다, 저게 좋다. 이런건 사실 크게 의미가 없었을지도 모른다.

꽉꽈라꽉꽉 눌러담은 레벨3, 4

꺼억~

우테코 생활이 마무리 되었다.

얼마나 많은 밥을 먹었을까?

나는 얼마나 많은 성장을 했을까?

이제 증명할 시간이 왔다.

취준 드가자!

HTTP cache(with. MDN)

Creative_Lee — Sun, 24 Sep 2023 14:26:24 +0900

이번 포스팅에서는 HTTP cache에 대해 알아보겠습니다.

포스팅의 전반적인 내용은 MDN - HTTP caching 문서 기반입니다.

다루지 않은 디렉티브나 내용에 대해 더 자세하게 알아보고 싶다면 문서를 참고하세요!

HTTP caching - HTTP | MDN

The HTTP cache stores a response associated with a request and reuses the stored response for subsequent requests.

developer.mozilla.org

캐시(cache)란?

자주 사용되는 자원(데이터, 값)을 임시로 복사해서 보관하는 장소를 말합니다.
기존 자원에 접근하는 시간 혹은 다시 계산하는 시간을 절약하고자 사용합니다.

HTTP cache

cache는 웹 통신 과정에서도 사용합니다.

프로젝트 성향에 맞게 JS, CSS, image와 같은 파일들을 cache해서 불필요한 통신 리소스를 줄일 수 있습니다.

통신 시간의 절약은, 곧 빠른 페이지 로딩으로 이어지고 사용자 경험을 향상시킵니다!

1. HTTP cache의 종류

HTTP cache는 크게 private, shared 2가지로 나뉩니다.

1-1. private cache(비공개 캐시)

클라이언트에 (일반적으로 웹 브라우저)에 저장되는 캐시입니다.
다른 클라이언트와 공유되지 않으므로, 사용자의 개인 응답을 저장할 수 있습니다.

1-2. shared cache(공유 캐시)

클라이언트와 서버(origin) 사이에 저장되는 캐시입니다.

shared cache는 다시 Proxy Cache와 Managed Cache 2가지로 나뉩니다.

Proxy Cache(프록시 캐시)
클라이언트의 바로 다음단에 위치하는 포워드 프록시에 저장되는 캐시입니다.
HTTPS가 점차 대중화 되면서 캐시의 역할보다는 필터링, 익명 접근, 접근 제한 등의 역할로 사용되고 있습니다.
(종단간 암호화를 보장하는 HTTPS 특성 상 포워드 프록시에서 그 내용에 접근하기 어렵기 때문입니다.)
Managed Cache(관리형 캐시)
오늘 포스팅의 주인공인 CDN 서비스 그리고 리버스 프록시, 캐시 API와 결합된 서비스 워커와 같은 환경에 저장되는 캐시입니다.
관리형 캐시 서비스는 대부분 캐시 제어 헤더(Cache-Control)와 자체 구성 파일 또는 대시보드로 캐시의 동작을 제어하는 기능을 제공합니다.

2. HTTP cache의 유효 기간

저장된 HTTP cache는 Fresh, Stale 상태로 나뉩니다.

Fresh - 일반적으로 응답이 아직 유효하며 재사용할 수 있음을 의미합니다.
Stale - 응답이 만료되었음을 의미합니다.

2-1. Cache-Control header

Cache-Control은 HTTP 에서 캐시 메커니즘을 지정하기 위해 사용되는 헤더입니다.

Cache-Control 헤더에 작성하는 지시문을 디렉티브(directive) 라고 합니다.

*HTTP는 가능한 한 많이 캐시하도록 설계되었기 때문에 Cache-Control 헤더가 없더라도 캐싱을 합니다.

이를 휴리스틱 캐싱이라고 합니다.

2-1-1. max-age, s-maxage 디렉티브와 age

max-age는 캐시가 유지될 최대 시간을, s-maxage는 shared cache(공유 캐시)에 유지될 최대 시간을 의미합니다.

age는 응답이 생성된 후 경과된 시간을 의미합니다.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Cache-Control: max-age=604800
Age: 86400

<!doctype html>
…

위 예제에서 응답에 대한 캐싱은 604,800초 동안 유지되며, 응답이 생성된지 86,400초가 경과했음을 의미합니다.

max-age에 명시한 시간내에 중복된 요청에 대해서는 캐시에 저장된 응답을 제공합니다. - Fresh

age가 max-age를 넘어선 후 부터는 origin(원본서버)에 요청합니다. - Stale

*HTTP/1.0 에서는 Expires 헤더를 사용하기도 했습니다.

Expires: Tue, 28 Feb 2022 22:22:22 GMT

하지만 위 시간 형식은 의도치 못한 버그가 많았고, HTTP/1.1 에서는 max-age 디렉티브가 채택되었습니다.
Expires 헤더는 사용하지 않는 것이 좋겠습니다.

2-2. Validation

cache가 Stale 하다면 origin으로 요청을 해야합니다.

이때 origin에서 받아올 데이터가 이전과 변함이 없다면, 같은 데이터를 또 받아오는 것은 낭비가 될 수 있겠죠.

이러한 이유로 Stale한 캐시는 즉시 폐기되지 않습니다.

HTTP는 origin에 요청할 때 Stale한 캐시를 그대로 갱신하여 사용할지, 새로운 응답으로 갱신할지 검증하는 메커니즘이 있는데

이를 revalidate 라고 부르고 conditional requests 과정을 통해 진행됩니다. (캐시 유효성 재검증 및 조건부 요청)

캐시 유효성 재검증 방식은 크게 2가지로 나뉩니다.

Last-Modified / If-Modified-Since - 리소스의 마지막 변경 시간으로 검증하는 방법
ETag / If-None-Match - 리소스 식별자로 검증하는 방법

위 2가지 방식 모두

리소스가 변경 되지 않았다면, 304 Not-Modified 상태 코드와 함께 Stale한 캐시를 그대로 갱신하여 재사용 합니다.

변경이 없는 사실만을 전달하면 되므로, 응답 body가 없어 전송 크기 자체가 매우 작고 빠릅니다.

변경 되었다면, 200 상태 코드와 함께 새로운 응답으로 캐시를 갱신합니다.

2-2-1. Last-Modified / If-Modified-Since 방식

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600

<!doctype html>
…

리소스 응답에 Last-modified 헤더가 포함되고, 마지막 변경 시간이 담겨있습니다.

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-Modified-Since: Tue, 22 Feb 2022 22:00:00 GMT

이후 Stale cache에 대한 재검증 시

이전 응답으로 받은 Last-modified 헤더의 마지막 변경 시간을 If-Modified-Since 헤더에 담아 리소스의 변경을 검증합니다.

파일의 수정 시간은 비교적 쉽게 얻을 수 있기에 간단하게 재검증을 구현할 수 있습니다.

정적 파일을 제공하는 경우에 유용하죠.

그러나 1초 미만의 단위로 조정이 불가능 하고, 주석/개행의 수정과 같이 유의미한 변경이 아닌 경우에도 변경으로 취급하기에 불편함이 있습니다.

2-2-2. ETag / If-None-Match 방식

리소스 식별자 기반의 재검증 방식이 위와 같은 불편함을 해결해 줄 수 있습니다.

ETag 응답 헤더에 포함되는 식별자는 서버에서 생성하는 임의의 값입니다.

이 값의 형식에는 제한이 없어, 자유롭게 생성 가능합니다.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
ETag: "33a64df5"
Cache-Control: max-age=3600

<!doctype html>
…

리소스 응답에 Etag 헤더가 포함되고, 식별자가 담겨있습니다.

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-None-Match: "33a64df5"

이후 Stale cache에 대한 재검증 시

이전 응답으로 받은 Etag 헤더의 식별자를 If-None-Match 헤더에 담아 리소스의 변경을 검증합니다.

2-3. no-cache / no-store

Cache-Control의 디렉티브

no-cache - 캐시를 사용하되, 매번 재검증을 통해 Origin의 신선한 리소스를 가져오도록 합니다.
no-store - 캐시를 사용하지 않습니다.

2-4. private / public

Cache-Control의 디렉티브

private - 브라우저에만 캐싱을 허용합니다.
pubilc - 공유캐시(Shared cache)에서도 캐싱을 허용합니다.

네트워크 재밌자네?

CloudFront(CDN), S3란?

Creative_Lee — Thu, 14 Sep 2023 22:43:41 +0900

1. CDN(Content Delivery Network)이란?

클라이언트와 서버의 물리적 통신거리가 긴 경우(ex. 한국에서 미국 웹사이트에 접속) 동영상 또는 웹 사이트 이미지와 같은 대용량 파일을 로드하는 데 시간이 오래 걸립니다.

CDN은 클라이언트와 서버 중간에서 통신에 관여해 위와 같은 문제를 해결해 줍니다.

클라이언트와 물리적으로 가까운 CDN을 통해 데이터를 주고받아 웹 트래픽을 줄이고 빠른 로딩으로 사용자 경험을 개선할 수 있습니다.

1-1. CDN 적용 시 장점

물리적 거리 감소 및 캐싱을 통해 페이지 로드 시간 단축되고, 이로 인해 사용자 경험이 좋아집니다.
자체 캐싱 및 최적화를 통해 서버가 제공해야하는 데이터 양을 줄일 수 있고, 이로 인해 서버 호스팅비용을 절감할 수 있습니다.
트래픽 급증시 트래픽을 분산하여 서버에 미치는 영향을 줄일 수 있습니다.

2. CloudFront란?

AWS에서 제공하는 CDN 서비스입니다.

전세계의 각 지역마다 엣지 로케이션(임시 데이터 저장소)를 가지고 있으며, 오리진으로부터 데이터를 받아 보관합니다.

사용자는 가까운 엣지 로케이션으로부터 데이터를 받아 빠르게 서비스를 사용할 수 있습니다.

2-1. 캐시 정책

CloudFront가 어떤 방식으로 캐싱할 지 지정하는 옵션입니다.

제공되는 캐시 정책을 선택해도 되고, 새로운 캐시정책을 만들수도 있습니다.

정책 내부로 들어가면 TTL, 압축 지원 등의 세부 정책을 설정할 수 있습니다.

2-1-1. TTL(Time To Live)

CloudFront가 origin(원본 데이터를 소유하고 있는 곳)으로 부터 받은 데이터를 캐시할 최소, 최대, 기본 시간을 나타내는 옵션입니다.

TTL 옵션은 origin의 Cache-Control(max-age, s-maxage) 및 Expires 설정에 따라 선택적으로 적용됩니다.

자세한 정책은 공식 문서를 참고하세요!

2-1-2. 압축 지원

CloudFront가 지원할 압축 형식을 지정하는 옵션입니다.

뷰어(브라우저)가 지원한다면, 객체를 Gzip 또는 Brotli 형식으로 압축하여 전달합니다.

2-2. 응답 헤더 정책

CloudFront가 뷰어(브라우저)에게 응답을 전달할 때 함께 실어 보낼 HTTP Header를 지정하는 옵션입니다.

반대로 제거할 Header를 지정할 수도 있습니다.

보안, CORS, 사용자 지정 헤더(Cache-Control등) 를 지정할 수 있습니다.

2-1-1. 사용자 지정 헤더, origin 재정의

CloudFront가 뷰어(브라우저)에게 전달할 커스텀 헤더(예시에선 Cache-Control)를 지정할 수 있습니다.

오리진 재정의는 원본(Origin에서 전달받은 CloudFront에 캐시된 데이터)에 동일한 헤더가 포함되어 있을 때,

원본의 헤더를 덮어쓸지(무시) 선택하는 옵션입니다.

자세한 정책은 공식문서를 참고하세요!

3. S3(Simple Storage Service)란?

AWS에서 제공하는 인터넷 파일 서버 서비스입니다.

텍스트파일, 이미지, 비디오 어떤 종류의 파일이던지 저장할 수 있습니다.

3-1. S3 장점

S3는 트래픽, 용량, 데이터 유실, 서버 다운, 보안 등 여러 이슈에 대한 부분을 대행합니다.
때문에 사용자는 본래 목적인 저장에만 집중하여 사용할 수 있습니다.

3-2. 기본 용어 개념

객체(Object)

데이터가 저장되는 기본 단위이며 파일과 메타데이터로 구성됩니다.
key value 형식의 객체 개념을 생각하면 됩니다.

하나에 객체에는 여러개의 또 다른 객체가 있을수도 있고, 여러개의 파일이 있을수도 있습니다.

버킷(Bucket)

S3에서 최상위 디렉터리의 개념입니다.

버킷 단위로 지역(region)을 지정할 수 있고, 버킷에 포함된 객체에 대해 일괄적인 설정이 가능합니다.

3-3. 메타데이터

key-value 형태로 객체의 정보를 나타내는 속성입니다.

주로 Cache-Control 과 같은 헤더를 정의하는데 사용됩니다.

각 객체마다 개별 메타데이터 설정이 가능합니다.

이를 통해 객체 별 캐싱 전략을 다르게 가져갈 수 있습니다.

CloudFront와 같이 사용하는 경우, 캐시 정책과 관련된 헤더의 값 및 우선 순위에 변동이 생길 수 있으므로 주의해야 합니다.

infra도 기본이 중요하다!

[삽질] - imagemin 패키지의 Unknown plugin 오류

Creative_Lee — Sat, 2 Sep 2023 20:52:48 +0900

1. 사건의 발단

이미지 최적화 관련 webpack플러그인 중 하나인 ImageMinimizerPlugin은 여러 하위 플러그인과 함께 사용하는 패키지이다.

하위 플러그인인 imagemin-xxx 패키지들을 설치하여 빌드할 때 해당 패키지들을 찾지 못하는 오류 발생

2. 문제 원인 분석

빌드 관련 패키지의 종속성의 버전이 낮았던 것이 원인.

*build 스크립트에서 webpack-cli 패키지를 사용하고 있었다.

*실행 일자 기준 2년전 생성한 프로젝트로 webpack-cli 패키지의 버전이 4.x.x 버전이었다.(최신 5.x.x)

3. 원인에 대한 학습

이미지 최적화 관련 패키지를 설치하기 전까지 build 커멘드는 문제없이 작동했기에, 새로 설치한 패키지(이미지 최적화 관련)에 대한 부분만 의심한 케이스.

build 자체는 관련이 없다고 생각했다.

하지만 원인은 build 커멘드와 가장 밀접한 패키지의 버전에 있었고, 오류가 발생한 원인 동작(build)부터 의심해 볼 필요성을 느꼈다.

또한 해당 프로젝트는 생성된지 2년이 넘은 레포였다.

오래된 프로젝트에서 관련된 종속성을 업데이트 하거나, 새로운 패키지를 설치할 때는 package.json에 명시된 각 패키지의 버전이 낮아 관련한 문제가 발생할 수 있다는 것을 알 수 있었다.

4. 문제의 해결

해당 패키지의 github issue에 해당 에러 키워드를 입력해 관련된 코멘트를 찾았고,

webpack-cli 패키지를 업데이트하여 해결하였다.

에러 추적은 발생지부터, 오래된 프로젝트는 버전체크부터!

배웠다 배웠어!

S-HOOK - 서비스 런칭 [Week 7 ~ 8]

Creative_Lee — Wed, 23 Aug 2023 00:13:54 +0900

어느덧 레벨3 마지막 스프린트를 진행했습니다.

성공적인 런칭 페스티벌! 그 마지막 여정은 어땠는지 되돌아 봅시다!

1. 사용성 위주의 피드백 반영

이번에도 역시 지난 데모데이 피드백을 반영했습니다.

사용성 위주의 피드백이 많았던 만큼 실제 유저가 느낄 수 있는 불편함을 해결하고자 노력했어요.

1-1. 듣기 / 등록 - 플로우 분리

등록과 듣기라는 정책을 함께 묶어 제공하던 기존의 방식은

오히려 듣기 기능을 주로 사용하는 유저에게 불편함을 줄 수 있었습니다.

관련한 문제점에 대해서는 이미 우려했던 부분이기에 관련하여 정책을 변경하였습니다.

별도의 페이지에서 한정된 기간 동안 특정 노래에 대해 킬링파트를 등록할 수 있도록 하고,

듣기 페이지에서는 이미 선정된 킬링파트를 들을 수 있게 하여 플로우를 완전히 분리하였습니다.

1-2. 듣기 버튼 강조

듣기 페이지에 대한 피드백중

'상대적으로 듣기 버튼이 영상에 비해 잘 눈에 띄지 않는다. 강조되어야 할 것 같다.' 라는 피드백도 있었습니다.

기존 UI

개선된 UI

이 부분에 대해 팀원 모두 공감하였고,

'듣기 기능'을 제공한다는 것을 유저가 명확하게 알 수 있도록 버튼 UI를 변경했습니다.

1-3. 스와이프를 통해 더 쉽게, 더 편하게 듣기

기존의 듣기 플로우는 다음과 같습니다.

메인페이지 노래 리스트의 노래 선택 → 듣기 페이지 이동 후 듣기

→ 다시 메인 페이지로 이동 후 노래 선택 → 듣기 페이지 이동 후 듣기

위 플로우에 대해

'유입된 초기 유저는 킬링 파트를 등록하기보다는 빠르게 여러 노래를 듣고자 할 것 같다.'

'빠르게 많은 노래를 소비할 수 있도록 하는 것이 중요하다고 생각한다.' 라는 피드백이 있었습니다.

스와이프

이에 대해 기존보다 더 빠르게 새로운 노래를 탐색할 수 있는 방법을 생각해 보았고, 스와이프 기능을 도입했습니다!

이를 통해 화면 드래그 한 번이면 다음 노래를 들을 수 있게 되었습니다.

2. 보다 더! 편하게

피드백 반영 이후에도 사용자가 느낄 수 있는 불편함에 대해 깊게 생각해 보았고,

다음과 같은 사용자 편의성 관련 기능을 추가했습니다!

파트 재생 중임을 시각적으로 알려줄 수 있는 progress bar 구현
파트 재생 중 스와이프 시 기존 파트 자동 정지 기능
신뢰할 수 있는 데이터를 위한 로그인 기능
좋아요를 통한 파트 아카이빙 기능

3. 런칭 페스티벌

이 모든 내용을 담아 대망의 런칭 페스티벌(4차 데모데이)을 진행했습니다

많은 사용자를 대상으로 실사용 피드백을 받을 수 있었어요!

생각하지도 못했던 부분에 대한 피드백을 많이 주셔서 너무 감사했습니다

4. Week 7 ~ 8 돌아보기

레벨 3의 모든 스프린트를 통틀어 가장 바쁘고 정신없었던 스프린트가 아닐까 싶어요.
개발해야 할 기능이 쏟아졌고 자연스레 밤을 새우기 일쑤였죠.
이런 정신없는 상황 속에서 팀원이 무엇을, 어떻게 개발해 나가고 있는지 놓치기도 했습니다.

개인적으로 나와 같은 목표를 가지고 나아가는 팀원이 무엇을 하는지, 또 어떤 생각을 가지고 있는지 알아야 한다고 생각해요.
팀이라는 울타리 안에서 문제를 해결하기 위해서 제일 기본이 되는 요소가 아닐까 싶습니다.

기본이라고 생각한 부분을 놓쳐서 여러모로 아쉬운 점도 많고 반성하게 됩니다.

가슴 뛰는 S-HOOK의 런칭과 함께

'이상적인 협업'에 대해 생각해 보게 된 마지막 스프린트였습니다!

레벨3 팀 프로젝트 회고는 여기까지 입니다.

레벨4 팀 프로젝트 고도화와 함께 돌아올게요!

컴포넌트 관심사 분리의 중요성 뼈 속까지 직접 느껴보기(feat. 의식적인 리팩터링)

Creative_Lee — Mon, 7 Aug 2023 01:32:08 +0900

이번 포스팅에서는 진행중인 프로젝트의 Page 단위 컴포넌트를 리팩터링 하는 과정과 느낀점을 담아보겠습니다.

도메인이 듬뿍 담긴 컴포넌트의 리팩터링 과정을 담다보니 다소 복잡합니다.

코드를 이해하기 보다는 가볍게 느낌만 봐주세요. (느낌만 봐도 충분히 복잡합니다..ㅎ)

과정과 설명 없이 Page컴포넌트의 Before / After 만 보고 싶으시면 아래 접힌글을 펼쳐서 코드를 확인해 주세요.

맨밑으로 가서 느낀점만 보셔도 됩니다...

Before

After

1. Page 컴포넌트의 문제점

우선 리팩토링 대상 컴포넌트 코드를 살펴봅시다.

미리 주요 관심사들에 대해 주석으로 표시해 두었습니다.

코드를 하나하나 이해하는 것 보다는, 주석 부분만 읽으면서 '관심사가 이렇게 많구나~' 정도만 파악하시면 좋을것 같아요.

위 page 컴포넌트를 보고 제가 느낀 문제점은 다음과 같습니다.

수 많은 관심사를 처리하고 있기 때문에 한눈에 파악하기 힘들다.
각 하위 컴포넌트로 전달되는 props와 그 역할이 구분되지 않는다.
페이지의 DOM 구조 또한 파악되지 않는다.

만약 기획이 변경되어 해당 페이지가 수정되어야 한다면?

개발자는 우선 코드 흐름을 파악하는데 많은 시간을 들여야겠죠.

또한 기존 기능을 유지하며 특정 기능을 수정하기 매우 어려울겁니다.

어디를 어떻게 수정해야 하는지 감을 잡고나면, 이미 많은 시간이 흘렀을 겁니다.

(실제로 저는 코드를 파악하는 데만 꼬박 2일이 걸렸습니다... )

2. 관심사 분리 시작

개인적으로는 해당 페이지의 레이아웃을 나타내는 것이 Page 단위 컴포넌트의 주 역할이라고 생각합니다.

나머지 역할을 최대한 분리해 봅시다.

2-1. 투표 관련 컴포넌트를 총괄하는 상위 컴포넌트 생성(컴포넌트 분리)

Page 컴포넌트에 존재하던 투표 관련 컴포넌트를 총괄하는 VoteInterface 컴포넌트를 생성합니다.

이후 투표와 관련된 모든 로직을 옮겨봅니다.

VoteInterface

VoteInterface 컴포넌트에 투표 관련 상태, 핸들러 함수 및 유틸 함수를 모두 옮겼습니다.

(VideoPlayer 관련 로직은 우선 주석처리 했습니다.)

로직이 분리된 Page 컴포넌트를 봅시다.

SongDetailPage

컴포넌트와 로직이 총괄 컴포넌트로 묶여 비교적 가벼워진 모습입니다.

보이지 않던 DOM 구조가 보이기 시작합니다.

2-2. 투표 관련 상태 및 로직 Context로 분리하기 (복잡하게 얽혀있는 상태와 Props 정리)

하지만 여전히 여러개의 상태가 어떻게 사용되는지, 어디서 어디로 흐르는지 알기 어렵습니다.

투표 관련 컴포넌트들이 공통적으로 필요로 하는 상태를 찾아 Context로 분리하겠습니다.

VoteInterfaceContext

Context를 SongDetailPage의 VoteInterface 컴포넌트에 적용해 줍니다.

SongDetailPage

Context를 적용한 VoteInterface 컴포넌트를 봅시다.

VoteInterface

표시된 부분처럼 각 투표 관련 컴포넌트에서 공통으로 요구하던 상태를 Context로 부터 제공받습니다.

과도한 props가 줄어들었습니다.

2-3. VideoPlayer 관련 상태 및 로직 Context로 분리하기

투표와 관련된 분리 외에도 유튜브 API에 의해 제공되는 player 객체를 초기화하고 사용하기 위해서는 상태가 필요했습니다.

(초기화는 Youtube컴포넌트에서 이뤄집니다.)

또한 각 투표 관련 컴포넌트에서는 이 상태를 통해 VideoPlayer를 조작할 수 있어야 했습니다.

이를 위해 VideoPlayer 관련 상태와 로직도 Context로 분리해 보겠습니다.

VideoPlayerContext

Youtube 컴포넌트(player상태가 초기화되는 곳)와의 재사용을 고려하여 투표 도메인과 관련된 로직을 두지 않았습니다.

Context를 SongDetailPage의 Youtube, VoteInterface 컴포넌트에 적용해 줍니다.

SongDetailPage

이때 의도대로 VideoPlayerProvider를 Youtube 컴포넌트와 재사용할 수 있도록

재사용 가능성이 없는 VoteInterfaceProvider 보다 상위에 두었습니다.

이제 Page 컴포넌트에 존재하던 player 반복재생 effect 로직도 분리 가능해졌습니다.

투표 관련 상태들의 변화에 의존하던 effect를 VoteInterfaceContext에 격리해 봅시다.

VoteInterfaceContext

2-4. 유틸함수 분리 및 메세지 관련 로직 정리

마지막으로 Page컴포넌트에 존재하던 클립보드 복사 관련 함수를 유틸로 분리해주고

기획의 변경으로 인해 더이상 사용하지 않는 메세지 관련 함수를 삭제합니다.

코드는 따로 담지 않겠습니다.

3. 관심사 분리 끝

이제 관심사가 분리된 각 컴포넌트를 확인해 봅시다.

3-1. SongDetailPage

관심사 분리를 통해 DOM 구조를 파악하기 비교적 쉬워졌으며,

Page 컴포넌트가 어떤 역할을 하는지도 명확하게 알 수 있습니다.

초기 Page 컴포넌트와 비교하면 책임이 상당히 줄어든 것을 확인할 수 있습니다.

api 통신의 결과를 하위 컴포넌트로 전달하는 책임정도만 가지고 있네요.

3-2. VoteInterfaceContext

투표 관련 상태와 핸들러, 이에 영향을 받는 effect 로직까지 Context에 잘 모여 있습니다.

투표 플로우와 관련된 에러가 발생한다고 가정했을 때, 더이상 Page 컴포넌트까지 가지 않아도 됩니다.

Context 선에서 해결할 수 있습니다.

3-2. VideoPlayerContext

자세하게 설명하진 않았지만, YouTube 컴포넌트에서 videoPlayer 상태를 초기화한 후

VideoPlayerContext를 통해 어디서든 videoPlayer를 컨트롤 할 수 있습니다.

전체적으로는 여전히 개선할 부분이 많지만, 기존과 비교하면 정말 많이 나아졌네요!

4. 기능 개발 vs 리팩터링 (feat. 한정된 시간...⌛)

이번 스프린트에서 페이지 단위 리팩토링을 진행하면서, 기술적인 부분을 제외하고도 여러 가지 생각을 하게 됐습니다.

4-1. 기능 개발이 우선인가? 리팩터링이 우선인가?

당연히 무엇 하나 놓치지 않는게 베스트이겠지만 현실적으로 쉽지않죠.

이건 정답이 없는 문제인것을 알지만 조금 오래 고민했던것 같아요.

작업을 진행하면서 '당장 프로젝트에서 개발해야 하는 기능은 많은데, 리팩터링을 하고있는게 맞나?' 생각하기도 했어요.

한편으로는 '주요 기능이 모여있는 컴포넌트인데... 이거 이대로 두면 안되는데...' 생각하기도 했고요.

당장 서비스의 상황만 놓고 보면 우선도가 높지 않았을 수도 있어요.

하지만 머지않은 미래에 해당 코드를 수정해야 하는 개발자는 제 노력만큼의 시간을 아낄 수 있겠죠.

4-2. 의식적인 리팩터링의 중요성

답이 없는 고민을 반복하다가 내린 결론은 코드를 작성하면서, 의식적으로 코드 흐름을 정리해야 한다는 것입니다.

작성한 코드 흐름이 내 머리속에서는 자연스럽다고 생각 하더라도, 잠시 되돌아 본다면 운좋게 어색한 부분을 찾을 수도 있겠죠.

결국 언젠가는 눈덩이가 구르겠지만, 마당이라도 한번 더 쓸어놓으면 혹시 모르지 않을까요...?

대왕 눈덩이가 되는 것은 막을 수 있을지도...

4-3. 마무리

이건 메모장에다가 코드를 파악하면서 적어놓은 내용중 일부입니다.

다음에 해당 코드를 수정하는 팀원은 이와 같은 수고를 덜 수 있었으면 좋겠습니다.

이 모든 과정이 저에게도 큰 경험치가 되었을 거라고 믿습니다.

한정된 시간에서의 리팩토링이 하나의 기능 개발보다 의미 있었기를 바라면서 포스팅 마무리할게요~!

S-HOOK 최고!

S-HOOK - 좋은 서비스를 위한 길 [Week 5 ~ 6]

Creative_Lee — Sat, 5 Aug 2023 22:15:39 +0900

눈 깜짝할 사이 시간이 흘러 3차 데모데이를 진행했습니다.

이번 스프린트에서는 어떤 일이 있었는지 한번 돌아봅시다!

1. 이전 데모데이 피드백 반영

이번에도 역시 지난 데모데이 피드백을 반영했습니다.

1-1. 플로우에 혼동이 생기는 여러 요소

2차 데모 플로우에서는 사용자에게 만족감을 주려던 목적으로

등록 후 자신이 등록한 킬링파트의 순위에 따른 메세지를 보여주거나, 득표수를 보여주었는데요!

이에 대해

'등록과 공유라는 핵심 가치외의 부가적인 가치를 제공하기 위한 수단이 플로우에 혼동을 준다'는 피드백을 받았습니다.

또한 '등록과 투표라는 용어의 혼동이 있다'는 의견도 있었어요.

이후 만족감이라는 가치가 현 상태의 S-HOOK에서 고려되어야 하는 가치인지 깊이있게 생각해 보았습니다.

회의 끝에 핵심 가치 관련 기능이 모두 개발 된 이후에 만족감과 같은 부가 가치를 고려하기로 결정했습니다.

최종적으로 위 사진처럼 모달에서 애매한 만족감을 주는 문구를 삭제하였고, 용어를 통일했습니다.

2. 스프린트 진행

이번 스프린트에서는 크게 다음과 같은 작업을 진행했습니다.

테스트 전략 수정 및 자동화
웹접근성 개선 및 개발
AWS EC2 + Nginx 환경에 배포

2-1. 테스트 전략 수정

프론트 파트는 크게 유닛테스트와 단일 컴포넌트 테스트를 진행했었습니다.

매 스프린트가 진행되면서 기획과 디자인의 변경이 이루어 졌는데요!

이에 따라 컴포넌트 수정이 불가피했고, 자연스레 테스트 케이스에 대한 수정 리소스가 증가했습니다.

배보다 배꼽이 더 큰 상황이 발생한거죠.

이런 문제점들을 해결하기 위해 테스트 전략 회의를 진행했고, 단일 컴포넌트의 기능테스트를 작성하지 않기로 했습니다.

또, 이런 단일 컴포넌트들이 여러개 조합되어 동작하는 기능에 대한 통합 테스트를 추후 고려해보기로 했습니다.

2-2. 테스트 자동화

테스트를 통과하지 못했거나, 빌드가 실패하는 작업물을 merge하면 안되겠죠.

이런 과정들을 매번 수동으로 확인하는 것은 매우 귀찮은 일입니다.

이번 스프린트에서는 merge를 위한 코드 확인 과정을 자동화했습니다.

PR을 작성하면 github actions에 등록한 CI task가 돌아가면서

Lint → 테스트 케이스 → build 순으로 확인합니다. 이 중 하나라도 실패한다면 수정 후 재시도 하도록 설정했습니다.

이제 코드 병합 과정을 보다 간편하고 안전하게 진행할 수 있게 되었습니다!

2-3. 웹접근성 고려

다양한 사용자를 위해 접근성도 개선했습니다.

제일 기본적인 접근성 관련 속성을 적용하고 시멘틱하지 못한 태그를 수정했어요. (현재 진행형입니다.__.)

여기에 저시력자를 위한 명도 대비 기준을 준수하기 위해 프로젝트의 primary 컬러를 조정했어요.

프로젝트가 다크모드 기반이라(검정 배경 흰 글씨) 명도 기준을 만족하기는 어렵지 않았습니다.

접근성 관련 학습을 하면서 접근성이 장애를 가진 사용자만을 위한 것은 아니라는 것을 알게 되었습니다.

예시로 마우스 없이 키보드만 사용하는 유저는 focusable한 요소가 없는 서비스를 사용하지 못하고 떠나버린다는 거죠.

여태까지 접근성 관련 개선을 미뤄왔던것을 반성하는 계기가 되었습니다.

2-4. 개발

이번 스프린트는 투표와 공유라는 핵심 가치가 제공되는 상태에서

더 다양한 노래를 제공하고, 킬링파트를 소비하도록 하는것이 중점이라고 생각했습니다.

따라서 '인기있는 노래를 빠르게 접하고 소비할 수 있도록 하자' 를 목표로 했어요.

이에 따라 위와 같은 기능을 도출하고 개발했습니다.

2-5. AWS EC2 + Nginx 환경에 배포

프론트엔드 배포관련 설정을 팀 협업으로 진행했습니다.

빌드 결과물(정적 파일)을 EC2 내부에 위치시키고 이를 Nginx가 서빙하도록 했습니다.

EC2는 무엇인지, 배포 과정 중에 Nginx는 어떤 역할을 수행 하는지 이해할 수 있게 되었습니다.

3. 데모데이 및 피드백

이 모든 내용을 담아 3차 데모데이를 진행했습니다.

서비스 플로우 관련 피드백이 주를 이뤘는데요! 정리하면 다음과 같습니다.

- 특정 기능을 귀찮다고 느낄 사용자들에게 확실하게 소비시키려면 어떻게 해야할지 고민해보기
- 이미 갖추어진 컨텐츠를 더 많이 소비하게끔 개선하기
- 서비스 이용이 더 편하게, 더 자연스럽게 개선하기

이번에 받은 피드백을 통해 다음 4차 데모데이에는 사용자 경험을 위주로 개선해야겠습니다.

4. Week 5 ~ 6 돌아보기

웹 표준, AWS, Nginx, CI, 개발까지..!

머리속으로 들어오는 정보가 많아 꼭꼭 눌러 담느라 쉽지 않았던 3번째 스프린트였습니다.

한편으로는 그만큼 성장한거라고 생각합니다.

또, 한정된 시간안에 서비스를 개발하는데 있어서 기존의 코드를 개선하는 일과 새로운 기능을 개발하는 것.

둘을 어느정도 비율로 가져가야 할지 깊게 생각해보기도 했네요.

(이 부분에 대해서는 느낀점이 많아 리팩터링 과정과 더불어 별도의 포스팅으로 다뤄보겠습니다.)

Week 5~6 회고는 여기까지 입니다.

4차 데모 데이 내용으로 다시 만나요!

TS + React + webpack 기반의 개발 환경 구성(feat. loader, HMR)

Creative_Lee — Tue, 25 Jul 2023 22:30:50 +0900

지난 webpack 핵심 컨셉 포스트에 이어서 프로젝트에 사용할 webpack 설정 파일을 작성한 과정에 대해 담아 보려 합니다.

목차는 다음과 같습니다.

webpack 설정
babel-loader 적용
ts-loader 적용
react 설정
HMR 적용

위 키워드 외 eslint, prettier, jest 등 기타 설정에 대한 내용은 추가로 포스팅하겠습니다.

React + TS 환경을 구성하는 각 과정을 패키지별로 나누어 설명하기에는 패키지 간 의존이 다소 깊습니다.
개연성이 다소 떨어질 수 있어요.

꼬리의 꼬리를 무는 구조이다 보니 전체 설정이 끝나기 전까지 설정에 대한 피드백을 받기 어렵습니다.

차근히 따라 해 보는 용도로 봐주시면 감사하겠습니다

(모든 설정이 끝나고 로컬에서 띄워지는 화면을 보면 희열이 있답니다 )

1. webpack 설정

우선 webpack 관련 패키지를 설치합니다.

webpack-cli : 웹팩의 커멘드라인 인터페이스를 제공
webpack-dev-server : 웹팩의 개발 서버 관련 기능을 제공
html-webpack-plugin : html 파일 생성 및 번들 파일 자동주입 플러그인

1-1. 설정 파일 작성 방식

설정 파일을 커스텀할 때 development 환경과 production환경을 구분하여 처리하는 방법은 크게 2가지가 있습니다.

하나의 설정 파일 내부에서 환경에 따라 분기하기
환경에 따라 설정 파일을 나누어 작성하기

개인적으로는 어떤 속성을 어떻게 사용했는지 명확하게 구분하여 보고 싶었고, 이를 위해 후자를 선택했습니다.

1-2. webpack.common.js

모든 환경에서 적용될 공통 속성을 정의하는 파일입니다.

보편적인 react 렌더링 시작점 파일(root) 경로를 entry 속성으로 지정했습니다.

또한 root div가 포함된 html 파일을 번들파일을 주입될 템플릿으로 지정했습니다.

resolve.extensions: 웹팩에게 모듈의 확장자를 해석하는 방식을 알려주어
import시 배열에 나열한 확장자들에 대해 확장자 생략이 가능하게 하는 속성

1-3. webpack.dev.js

development 환경에서 적용될 속성을 정의하는 파일입니다.

merge 메서드를 통해 공통 설정파일과 dev 환경 설정을 병합할 수 있습니다.

devServer.historyApiFallback: URL 직접 접근 혹은 새로고침시 404 page 대신 index.html로 이동시키는 기능
devServer.open: 서버 시작후 바로 브라우저가 열리도록 하는 기능

1-4. webpack.prod.js

production 환경에서 적용될 속성을 정의하는 파일입니다.

output.filename의 contenthash: 파일의 내용 변경에 따라 해시값을 변경하는 옵션
브라우저의 캐싱으로 인해 사용자가 새로운 배포 버전을 사용하지 못하는 상황을 방지하기 위해 사용
output.clean: 번들링 시 기존 번들링 결과물을 삭제하는 옵션. 예상치 못한 충돌을 방지할 수 있다.

기본적인 설정은 끝났습니다.

위 구조를 바탕으로 여러 loader와 plugin을 적용하며 설정 파일이 더 커지게 됩니다...!

2. babel-loader 적용

다음으로 babel 관련 패키지를 설치하겠습니다.

@babel/core: 바벨의 트랜스 파일링 수행을 위한 기능을 제공
@babel/preset-env: 트랜스 파일링할 기능을 지정하는 플러그인을 번들로 묶어 제공
@babel/preset-react: jsx를 js 코드로 변환하기 위한 기능을 제공
core-js: 바벨의 트랜스 파일 과정에서 폴리필(polyfill)을 제공
babel-loader: webpack 번들 과정에서 바벨의 트랜스 파일링을 수행하도록 함

2-1. bable.config.js

프로젝트 전역으로 적용할 바벨 속성을 정의하는 파일입니다.(root 경로에 위치)

presets - preset-env
- useBuiltIns: 'usage', 'entry' 옵션 중 선택
  - usage: 실제로 사용한 코드의 폴리필만 삽입
  - entry: 전체 폴리필 삽입
- corejs: polifill을 제공하는 주체인 corejs의 버전 명시
presets - preset-react: react에서 필요한

*프로젝트에서는 브라우저 지원범위를 포함한 기타 옵션들을 아직 확정하지 않았습니다.

2-2. babel-loader 적용

webpack.common.js 파일에 babel-loader 관련 설정을 추가해줍니다.

.ts, .tsx 확장자를 가진 파일에 대해서만 babel-loader를 적용하도록 설정했습니다.

node_modules 는 babel의 트랜스 파일 대상에서 제외했습니다.

*프로젝트에서는 ts-loader를 사용해 ts -> js 트랜스파일 하기로 했습니다.

우선 .ts, .tsx를 대상으로 적어두고 넘어갑니다. (아래 ts-loader 문단에서 나옵니다.)

3. ts-loader 적용

다음으로 ts 관련 패키지를 설치하겠습니다.

ts-loader: webpack 번들 과정에서 ts -> js 트랜스 파일을 수행하도록 함

3-1. tsconfig.json

프로젝트 전역으로 적용할 tsc 설정을 정의하는 파일입니다.(root 경로에 위치)

compilerOptions
- target: 어떤 버전의 js 파일로 트랜스 파일링 할것인지 정하는 옵션 (보통 es6를 많이 사용하고 기본값이다.)
- lib: 프로젝트에서 사용할 특정 문법에 대한 type 파일을 제공하는 옵션 (target 옵션에 따라 기본값이 지정된다.)
- jsx: .tsx 파일의 트랜스 파일링 방식을 지정하는 옵션 (_jsx 함수의 호출로 반환하도록 react-jsx 옵션을 사용)
- module: 트랜스 파일된 결과물이 사용할 모듈방식을 지정하는 옵션(target 옵션에 따라 기본값이 지정된다.)
- moudleResolution: 트랜스 파일링시 모듈의 해석방식을 지정하는 옵션
- resolveJsonModule: .json 파일을 모듈로 해석할 수 있게 하는 옵션(.json 파일의 import가 가능해진다.)
- allowJs: .js 파일을 허용하는 옵션
- isolatedModules: 프로젝트 내 모듈 생성을 강제하는 옵션(단일 파일 기반 트랜스 파일러에서 발생할 수 있는 문제 해결)
- esModuleInterop: CommonJS, AMD, UMD 같은 모듈 방식을 es6 모듈 인것 처럼 사용하게 해주는 옵션
- forceConsistentCasingInFileNames: 파일의 대소문자를 구문하게 해주는 옵션
- strict: 타입스크립트의 각종 타입 체킹 동작을 전부 활성화하는 옵션
- noFallthroughCasesInSwitch: switch 문을 올바르게 사용하도록 강제하는 옵션
- skipLibCheck: 모든 선언 파일(.d.ts)의 타입 체킹을 스킵하는 설정이다. (라이브러리에서 제공하는 .d.ts 파일은 이미 타입 체킹이 된 파일일 것이라는 가정)

3-2. ts-loader 적용

webpack.common.js 파일에 ts-loader 관련 설정을 추가해줍니다.

4. React 적용

react 관련 패키지를 설치합니다.

4-1. react 프로젝트 기본 디렉터리 및 파일 추가

root를 생성할 index.tsx,

root div를 포함하는 index.html 파일을 생성합니다.

5. HMR 적용

HMR 관련 패키지를 설치합니다.

5-1. react-refresh/babel 적용

plugins 속성에 추가해 줍니다.

5-1. react-refresh-webpack-plugin 적용

plugins 속성에 추가해 줍니다.

6. 최종 확인!!!

이제 지금까지의 설정이 잘 동작하는지 확인해봅시다.

HMR 동작까지 확인!

여러 설정들이 잘 적용되어 번들링이 성공했음을 알 수 있고,

개발 서버 실행 + HMR도 잘 동작하는 것을 확인할 수 있습니다

지금까지 TS + React + webpack 기반의 개발환경을 직접 구성해봤습니다.

위 설정만으로도 개발을 시작할 수 있지만,

일관된 코드 스타일을 유지하기 위한 eslint, prettier와 같은 설정이 필요할 수도 있습니다.

eslint, prettier, jest 등 기타 설정에 대한 추가 포스팅으로 다시 돌아오겠습니다

기본이 중요하다!

S-HOOK - 기초가 중요하다 [Week 3 ~ 4]

Creative_Lee — Mon, 24 Jul 2023 00:28:57 +0900

어느새 2주라는 시간이 흘러 2번째 데모데이를 진행했습니다.

git branch 전략 및 페르소나 변경 이에 따른 핵심 가치 기능의 변경까지 정말 많은 일이 있었어요!

기초의 중요성을 느낀 스프린트! 그 내용을 차근히 정리해 보았습니다.

1. git branch 전략 변경

지난 1차 데모데이 포스팅에서 git flow의 release 브랜치를 제외 한 브랜치 전략을 사용하기로 했었는데요!

이에 대한 피드백을 받았어요~!

말씀하신대로 배포한 상황이 없을 텐데, 조금 더 간소한 브랜치 전략을 가져가는 것은 어떨지?

1-1. github flow로 변경

이에 대해 팀원들과 회의를 진행하게 되었습니다.

초기에 정한 전략이 틀린건 아니지만,

초기 배포 버전이 없는 현 상황에서 브랜치 관리 리소스는 빠른 개발을 방해하는 요소라고 판단했어요.

피드백을 적극 수용해서 배포를 시작하고 규모가 커지기 전까지 사용할 전략을 찾게 되었고,

github flow를 사용하기로 결정했습니다.

모든 기능 단위 브랜치를 main 브랜치에서 파생시키고 merge하게 되는 간단한 흐름입니다.

현 상황처럼 작은 규모의 프로젝트에서 적당하다고 생각했어요.

추후 규모가 커지면 변경을 고려하는 것으로 마무리 되었습니다!

2. 페르소나 변경

페르소나에 대한 피드백도 받았었습니다.

기능에 맞춘 페르소나가 아닌지?

기존 페르소나는 기획을 통해 이미 기능을 도출한 뒤, 기능에 맞춰 페르소나를 작성했기에 다소 어색했어요.

이를 통해 도출한 핵심 기능인 킬링파트 등록과 조회 역시 프로젝트의 가치를 나타내기 어려웠죠.

2-1. 새로운 페르소나

때문에 피드백을 적극 수용하여 페르소나 재정의 회의를 진행했어요.

기획에 맞춰진 페르소나 탈피와 핵심 가치를 좁히는 것을 중점으로 했습니다.

일반적인 사람들

핵심기능 재정의

조금 더 일반적인 페르소나(노래를 공유하고 싶은 사람)를 지정했고, 이를 통해 공유가 핵심이라는 결론을 도출할 수 있었습니다.

(S-hook의 s가 share 였다는 사실을 다시 한번 상기했죠 )

등록과 공유.

목표가 기존보다 더욱더 명확해져, 빠르게 달려나갈 수 있는 발판이 되었어요~

3. 개발 시작!

그리고 드디어! 개발을 시작했습니다.

3-1. 와이어 프레임 및 디자인

피그마를 사용해 각자 와이어 프레임을 만들고 회의를 통해 디자인을 취합했어요.

핵심 기능으로 정한 킬링파트 등록, 공유에 대한 페이지를 우선으로 고려했습니다.

3-2. 이슈 단위 기능 개발

페이지 시안을 확정한 뒤 본격적으로 코드를 작성했습니다.

기능을 이슈 단위로 작게 나누고 이슈단위로 개발하는 구조로 진행했어요.

1 issue === 1 PR 작성으로 작업내용이 명확하게 나뉘어 있어서 편했답니다.

3-3. PR 코드 리뷰

프론트엔드 팀원의 코드리뷰도 진행했습니다.

주고

받고

역시나 코드리뷰를 통해 팀원에게 배울게 정말 많았습니다!

내 코드에 대해 합당한 이유를 들어 설명하고,

더 나은 코드를 위한 조언을 받고 수용하면서 많이 발전할 수 있다고 생각해요!

때문에 코드 리뷰는 정말 중요하다고 생각합니다.

4. 데모데이 및 피드백

여러 변경사항과 데모 시연을 담아 2차 데모데이를 진행했습니다.

주요 피드백 사항을 정리하면 다음과 같습니다.

- 핵심 기능 목표와 데모가 일치했으면 좋겠다.
- 다음에 구현할 기능이라고 넣기보다는 완성시켜서 다음 데모에 포함하면 좋을 것 같다.
- 사용자가 자신이 뭘 하는지 설명없이 이해할 수 있으려면 플로우가 조금 더 확실한게 좋겠다.

전체적으로 재정의한 핵심 가치와 기능을 잘 구현하였고 목표를 달성했기에 뿌듯했습니다.

이번에 받은 피드백을 통해 다음 3차 데모데이에는 설정한 목표에 맞는 정확한 플로우를 제공하는 것을 기준으로 잡아야겠네요!

4. Week 3 ~ 4 돌아보기

페르소나 및 기획 재정의로 인한 많은 회의, 본격적인 개발의 시작으로 여전히 바쁜 두번째 스프린트였습니다.

팀문화를 비롯한 여러 규칙들 아래 개발을 시작하면서

실제로 지켜지는 것과 현실적으로 지키기 어려운 것들을 확인할 수 있었어요.

빠르게 업데이트 해야할 부분이네요 ㅎㅎ

그리고 다시 한번 기초가 중요하다는 것을 느낄 수 있었습니다.

페르소나 재정의 없이 이전 목표 그대로 진행했다면, 팀원 모두가 한 곳을 바라보며 나아가기 어렵지 않았을까 싶습니다.

다음엔 또 어떤 시련을 이겨내고, 어떤 목표를 달성할까요?

정말 기대됩니다!

Week 3~4 회고는 여기까지 입니다.

다음 스프린트로 다시 만나요!

path.resolve, __dirname

Creative_Lee — Fri, 14 Jul 2023 13:44:50 +0900

Webpack 공식 문서를 읽다보면 경로 관련 속성에서 자주 등장하는 키워드가 있습니다.

path.resolve 와 __dirname 인데요. 대체 무엇인지 한번 알아보겠습니다.

1. path

우선 path를 먼저 알아볼게요.

path 모듈은 node.js 내장 API 입니다.

운영체제별로 경로 구분자가 달라 발생하는 문제를 해결하기 위해 탄생했습니다.

운영체제는 크게 Window 진영, POSIX 진영(macOS, Linux)으로 나뉘는데,

Window: ' \ ' (역슬레시)

POSIX: ' / ' (슬레시)

각각 위와 같은 구분자로 폴더를 구분합니다.

path 모듈의 메서드로 위와 같은 구분자 문제를 쉽게 해결할 수 있습니다.

1-1. path.resolve

path.resolve([...paths])

경로 인자들을 오른쪽에서 부터 왼쪽으로 읽고, 조합하여 root 경로를 고려한 절대경로로 반환합니다.

오른쪽부터 읽다가 '/디렉터리' 같은 절대 경로 형식을 발견하면 해당 경로를 바로 반환합니다.

만약 인자를 전달하지 않으면 작업 중인 디렉터리(working directory)를 절대경로로 반환합니다.

2. __dirname

파일의 현재 경로를 나타내는 전역 변수입니다.

이 역시 운영체제별로 구분자가 다르게 표시됩니다.

3. path.resolve( __dirname, 'dist' ) 의 의미

드디어 webpack 설정파일에 자주 등장하던

path.resolve( __dirname, 'dist')의 의미를 알 수 있습니다!

일반적으로 dist 폴더와 webpack.config.js 파일은 프로젝트 root 경로에 위치하게 되는데요~!

이때 __dirname을 통해 root 경로를 기준으로하게 되고,

resolve 메서드로 인해 root + dist의 절대 경로를 반환하게 되는 것이죠.

3. 절대경로를 권장하는 output.path

웹팩 공식문서에서는 output.path 속성을 절대경로로 설정할 것을 요구하고 있습니다.

(공식적인 이유는 찾을 수 없었어요. 추후 찾으면 추가하도록 하겠습니다.)

이때 팀원의 운영체제가 다름으로 인해 발생하는 구분자 이슈를 방지하기 위해

path.resolve와 __dirname을 함께 사용해 볼 수 있겠네요!

포스팅은 여기까지 입니다.

기본이 중요하다.

S-HOOK - 그토록 바라던 첫 팀 프로젝트의 시작 [Week1 ~ 2]

Creative_Lee — Thu, 13 Jul 2023 14:32:09 +0900

저의 우테코 자소서 내용중 이런 부분이 있습니다.

우테코에서 동료들과 함께 흔들리지 않고 단단하게 성장하고 싶습니다.
제게 동료들과 함께 배울 수 있는 소중한 기회가 주어진다면,
이 글에 미처 담지 못한 열정 괴물 이도현의 성장을 우테코에서 꼭 보여드리겠습니다!

레벨 1, 2가 흘러 어느덧 레벨3.

드디어 그토록 바라던 팀 프로젝트를 진행하게 되었습니다...!!

우테코에서는 2주 단위로 *데모데이를 진행하는데요~!

앞으로 데모데이를 기준으로 프로젝트 주요 이슈와 피드백 사항에 대해 간략하게 정리하고 회고하려 합니다.

*데모 데이: 각 팀이 추구하는 목표와 방향성 공유하고, 피드백을 주고 받는 날

1. 'S-HOOK' 이 뭔데?

노래의 도입부만 듣고 취향이 아니라고 생각하여 놓친, 알고보면 좋은 노래들이 많습니다.
이런 노래들도 킬링파트만 들어볼 수 있었다면 어땠을까요?

Share의 약자인 'S'와 hook을 합쳐 S-HOOK!

사용자가 투표한 킬링파트(Hook)를 기반으로 노래를 공유하자! 라는 아이디어에서 시작한 프로젝트입니다.

고심 끝에 고른 서비스 명 'S-HOOK'

2. 주요 작업 내용

첫 2주 동안 진행한 주요 작업은 다음과 같습니다.

주로 팀원간의 생각 차이를 좁이는데 사용했네요!

사용자 스토리 맵핑
페르소나 정하기
컨벤션 및 브랜치 전략
데모데이 발표

2-1. 사용자 스토리 맵핑

각자 다른 것을 상상한다.

우리는 보통 요구사항에 대한 부분을 문서화 하여 공유합니다.
빠르게 소통할 수 있지만, 같은 문서를 읽고도 서로 다른 것을 상상한다는 문제점이 있죠.
우리가 같은 것을 생각하지 않았음을 깨닫는 순간은
소프트웨어를 한참 개발하는 도중이거나 소프트웨어를 고객에게 전달한 후 입니다.
이런 문제를 어떻게 해결할 수 있을까요?

사용자 스토리 맵핑 활동을 통해 위와 같은 문제를 해결해 볼 수 있습니다.(더 궁금하신 분들은 여기에서 확인하세요)

일전에 근로 워크샵에서 '사용자 스토리 맵핑'을 처음 접했었는데,

구성원 모두의 생각이 일치되는 경험이 너무 좋았어요.

팀원에게 사용자 스토리 맵핑 활동을 제안했고 흔쾌히 승락해 주었습니다.

스케치북에 진행한 스토리 맵핑

활동은 *작업(Task) 나열하기 *활동(Activity) 구성하기 *스토리(Story) 나열하기 순으로 진행했습니다.

초기 기획이 확실하지 않던 상태에서 진행해서 다소 시간이 걸리긴 했지만,

팀원 모두가 생각이 일치되어 가는 것에 만족했습니다.

*Task: 사용자가 제품을 사용하는 동안 필요한 모든 작업

*Activity: Task 중 조금 더 큰 단위로 묶을 수 있는 그룹

*Story: Activity를 달성하기 위해 고려해야하는 상황을 정리한 것

2-2. 페르소나 정하기

S-HOOK을 사용할 페르소나를 지정하고 시나리오를 도출해 보기도 했어요.

사용자 스토리 맵핑 활동과 더불어,

'무엇이 우리 서비스의 핵심 기능인가?' 를 도출하는 데 도움이 됐습니다.

2-3. 컨벤션 및 브랜치 전략

회의를 통해 팀내 PR 코드 리뷰 Rule과 각 파트별 코드 컨벤션을 구성했어요.

코드리뷰 Rule은 최대한 팀원의 성장을 도모할 수 있는 방향으로 정했습니다.

코드 컨벤션은 과한 제약으로 생산성이 떨어지지 않도록 큰 틀 부터 정해보려고 노력했습니다.

또한 브랜치 전략에 대해 학습하고 나름의 이유를 가지고 flow를 정해봤어요.

Git flow 전략에서 release 브랜치를 제외한 흐름으로 가져가보기로 했는데요!

아직 개발 서버가 존재하지 않고 규모가 크지 않기에 제외하게 되었습니다.

추후 서비스의 규모가 커짐에 따라 개발 서버의 필요성을 느끼는 순간에 release 브랜치를 추가하기로 했습니다.

3. 데모데이 및 피드백

그리고 드디어 1차 데모데이를 진행했습니다...!

좋은 피드백도 많이 받았어요~!

주요 피드백 사항을 정리하면 다음과 같습니다.

- 현재 배포한 상황이 없을 텐데, 조금 더 간소한 브랜치 전략을 가져가는 것은 어떨지?
- 주어진 기능에 맞춰서 페르소나를 맞춘 것은 아닌지?
- 아무도 이 파트를 지정하지 않으면 아무도 킬링파트를 들을 수 없는 것이다.
초창기에는 노가다가 들어가야할 것 같고. 어느정도 정해지면 악의적인 사용자의 어뷰징을 막아야 할것 같다.
- 가능한 저작권 문제 없고, 노래를 들을 수 있으면서 구간을 지정할 수 있는 기능을 완료하는 것이 먼저.

현재 위 피드백을 바탕으로 브랜치 전략을 간소화 중에 있고, 페르소나 및 기획을 조정하고 있어요.

기초 공사를 조금 더 단단히 해야할 필요가 있다고 느꼈습니다.

4. Week1 ~ 2 돌아보기

아무래도 기획 관련된 내용으로 회의가 많기도 했고, 컨벤션 외 기타 여러 것들을 논의하느라
전반적으로 정말 바쁜 첫 사이클이었습니다.

본격적인 개발에 앞서 팀 문화를 비롯한 여러 규칙을 정하고 따르고 있는데,

실제 개발 단계에서도 이런 것들이 정말 잘 지켜지는지,얼마나 도움이 되는지 얼른 다음 사이클을 진행해 보고 싶네요!

또 반성해야 할 부분이 생각나는데요.
팀원과 페르소나 or 아이디어 회의 중에 '보통의 경우, 일반적인 경우'라는 말을 많이 사용한 것 같아요.
개인의 기준으로 전체를 판단한 경우가 생겨 조심해야겠다고 생각했습니다.

또 개발자는 코드를 짜는 직업이 아니라, 문제를 해결하는 직업이라는 것을 몸소 느낄 수 있었어요.

수 많은 기획과 서비스들은 결국 사람들이 겪고 있는 문제를 해결하기 위함이라는 거죠

앞으로의 개발 인생에서도 계속 되뇌이면 좋을 부분이라고 생각합니다.☝

이제 시작..!

Week 1~2 회고는 여기까지 입니다.

다음 사이클에 다시 만나요!

webpack이란?(feat. 핵심 컨셉)

Creative_Lee — Sun, 9 Jul 2023 22:35:27 +0900

첫 팀 프로젝트를 시작하면서 프로젝트 성향에 맞는 커스텀한 개발 환경 설정이 필요했습니다!

직접 개발 환경을 구성해 보면서 전반적인 개발 환경에 대해 이해하고자 합니다.

그 첫 주제는 바로 webpack입니다.

1. webpack 이란?

webpack

웹팩은 대표적인 *번들러중 하나로

웹을 구성하는 자원을 각각의 모듈로 취급하고 이를 병합하여 하나의 결과물로 만들어 주는 도구입니다.

(js 파일 뿐만 아니라 css, 이미지, 폰트와 같은 기타 파일도 모듈로 취급할 수 있습니다.)

*번들러(bundler): 의존성이 있는 여러 개의 js파일(모듈)을 하나의 js파일로 합쳐주는 도구

2. webpack의 핵심 컨셉

웹팩 공식문서에서는 웹팩을 이해하기 위한 핵심 컨셉을 소개하고 있습니다.

2-1. entry

entry 속성을 통해 번들링을 시작할 파일의 경로를 지정할 수 있습니다.

웹팩은 이 속성에 명시된 모듈에서부터 시작하여 각 모듈의 의존성 그래프를 생성하게 됩니다.

2-2. output

반대로 output 속성으로 번들링 된 결과물이 저장될 경로 및 파일명을 지정할 수 있습니다.

*path: node.js api로 파일의 경로를 지정하기 위해 사용
*path.resolve, __dirname : path.resolve, __dirname란?

2-3. loader

로더는 js파일 외의 파일들도 모듈로 취급할 수 있도록 합니다. 즉 번들링 결과물에 포함시킬 수 있습니다.

또한 특정 유형의 모듈을 변환할 수 있습니다. (ex. ts --> js 변환, babel로 코드 변환)

module 속성으로 설정합니다.

*로더는 역순으로 실행됨에 유의

*예시에서 사용한 로더

css-loader: css파일을 js코드로 변환(모듈화)해 주는 로더
style-loader: js로 변경된 css를 동적으로 돔에 추가해 주는 로더

2-4. plugin

플러그인은 번들링된 결과물의 후처리를 담당합니다.

이외에도 에셋 관리, 환경변수 주입 등, 번들링 과정 전반에 걸쳐 여러가지 기능을 합니다.

plugins 속성으로 설정합니다.

*예시에서 사용한 플러그인

HtmlWebpackPlugin: HTML 파일을 생성하고, 번들 파일을 script 태그로 주입해주는 플러그인

2-5. mode

모드 속성으로 webpack에 내장된 환경별 최적화를 활성화 할 수 있습니다.

옵션은 'development', 'production', 'none' 이 있습니다.

기본적으로 각 모드별로 process.env.NODE_ENV 환경 변수가 자동으로 설정됩니다.

또한 'production' 모드에서는 최적화와 관련된 여러 플러그인이 적용됩니다.

3. 번들링 / 결과물 확인

핵심 컨셉을 바탕으로 작성한 설정파일로 아래의 간단한 예시코드를 번들링 해보겠습니다.

2개의 모듈에 의존하고 있는 index.js를 준비했습니다.

결과물을 확인해보면...

webpack은

entry 경로로 지정한 index.js 파일로 부터 의존성을 분석하여

output 경로에 맞게 번들 파일이 생성되었고,
loader가 잘 적용되어 css코드도 번들에 합쳐졌습니다.
plugin도 잘 동작하여 html 파일 및 삽입된 script태그를 확인할 수 있습니다.

4. 마치며...

여기까지 webpack의 핵심 컨셉에 대해 알아보았습니다.

webpack에는 위에서 소개한 속성 외에도 수 많은 속성과 세부 속성이 있습니다...!

필요할 때 마다 그때그때 공식문서로 학습하는게 좋아보이네요!

시간을 두고 천천히 알아가보도록 합시다.

기본이 중요하다.

우테코 레벨2 학습 내용 총정리

Creative_Lee — Mon, 19 Jun 2023 16:24:22 +0900

레벨2 학습 내용 총정리

그야말로 대 환장 파티...! 레벨2를 마무리했다.

레벨1의 고된 시절이 생각나지 않을 만큼 정말 빠르게 지난 간 8주였다.

학습 내용을 정리하며 흐려지는 기억들을 주워 담아보자!

그래서 뭘 배웠어? ‍♂️

개인적으로 몰입했던 키워드는 다음과 같다.

React
CDD(with storybook)
UI / UX
협업

1. React

질긴 인연

2년 전 이맘때에 React를 처음 배웠었다. 그저 문법을 외우고 작업물을 찍어내기 바빴다.

'React란 무엇이고, 왜 많은 사람들이 사용하는가?' 제일 기본이 되는 것조차 모르고 사용했었다.

이번 레벨 2에서는 React의 '근본'에 대한 것을 많이 학습했다.

1-1. why React?

누군가 '왜 react를 사용하는 거야?' 물으면 나는 이렇게 답변할 것이다.

React는 복잡한 사용자 인터렉션과 이벤트, 이에 따른 UI의 변화를 직접 컨트롤 할 필요없게 추상화되고 최적화된 라이브러리야.
때문에 개발자는 UI에 집중해서 선언적인 개발이 가능해~!

레벨1에서 바닐라JS만으로 어플리케이션을 구현하면서 여러 불폄함을 느꼈기 때문에, 비로소 이해하게 되었다고 생각한다.

1-2. React - keyword

virtual dom
jsx
key
context API
controlled & uncontrolled Components
memoization
custom hook
재사용 가능한 컴포넌트

위 키워드 외에도 정말 많은 React 관련 키워드를 학습했다.

각 키워드마다 기억에 남는 에피소드 하나씩은 꼭 있는것 같다...ㅋㅋㅋ

React 코어와 관련된 내용도 내용이지만, 개인적으로는 custom hook과 같은 로직 분리 부분에서 많이 성장한 것 같다.

컴포넌트 하나에 1000라인이 넘어갔던 옛 시절은 이제 상상도 할 수 없다.

1-3. 결국 여전히 중요한것은 관심사의 분리

레벨1에서부터 이어져서 결국 특정 컴포넌트의 관심사는 무엇인지, 어디까지 알고 어디까지 몰라야 하는지가 중요하다고 생각한다.

비동기 통신과 같은 방해꾼들을 어떻게 잘 분리할 것인지 더 많이 고민해 봐야 한다.

2. CDD(with storybook)

Component Driven Development
작은 부품 단위의 컴포넌트에서 시작해 페이지 단위까지,
Bottom - Up 방식으로 UI를 만들어 나가는 개발 방법론을 말한다.

밋밋해서 재탕

2-1. CDD / Bottom - Up 개발의 짜릿함

과거의 나는 컴포넌트라는 개념이 전무했다.

Top-down 방식, 어쩌면 아무런 방식도 없이 그저 적당히 커지면 나누면서 개발했었다.

파일이 커져가는 것을 인지하지 못했고, 어디서부터 어느 정도를 컴포넌트로 구분해야 하는지 기준이 없었다.

때문에 어수선한 코드와 애매한 크기의 컴포넌트들이 즐비했다.

그런 내가 어쩌면 인생 처음으로 찐 Bottom-Up 방식의 개발을 해본 것이 아닐까 싶다.

가장 작은 단위의 컴포넌트부터 설계하고 storybook의 도움을 받아 UI로 확인하며 작성하는 경험은 정말 신세계였다.

비록 내가 적용하고 경험한 것은 일부분이겠지만, 앞으로의 컴포넌트 설계에 큰 도움이 될것이라 생각한다.

2-2. storybook

컴포넌트 단위의 독립적인 UI 개발 환경을 지원하는 툴

평생을 Top-down으로 개발했던 사람으로서 스토리북을 잘 사용하기까지 다소 긴 시간이 걸렸다.

작은 단위의 컴포넌트를 만들어 가면서 차차 그 가치를 알게 되었다.

프로젝트와 독립적인 환경에서 컴포넌트 개발이 가능하다는 점 외에도

문서화와 배포를 통해 다른 개발자 및 타 직군에게도 컴포넌트를 보여주고 설명할 수 있다는 점이 좋았다.

(크루들의 질문에 컴포넌트만 쏙쏙 보여주는 게 얼마나 편했는지 모른다.)

앞으로의 모든 react 프로젝트에는 무조건적으로 사용할 것이다.

3. UI / UX

레벨 1에서 레벨 2 초반부까지는 기술, 지식적인 것에 치중한 면이 있었다.

이 모든건 사용자를 위함임을 잠시 잊었다.

깔끔하고 좋은 코드 vs UI / UX

사실 'vs'라고 표현해도 될까 싶은 정도로 둘 다 놓칠 수 없는 것들이다.

둘 사이의 경계를 잘 잡아 발전시켜 나가야 한다.

한정된 기간 안에 결과를 만들어 내면서 밸런스 있게 둘 다 챙기는 법을 조금씩 알아가고 있다.

4. 협업

아! 재밌다...!

인생 첫 백엔드와의 협업이었는데 정말 재밌었다.

사람도 너무 좋았고, 첫 협업 회의도 재미있었고, 개발하는 과정도 재미있었다.

우여곡절 끝에 API를 적용하고 정상적으로 돌아가는 어플리케이션을 확인했을 때 정말 기분 좋았다.

배운 것도 참 많았고 마냥 신기했다ㅋㅋㅋ

4-1. MSW

Mock Service Worker
서비스 워커(Service Worker)를 사용하여 네트워크 호출을 가로채는 API 모킹(mocking) 라이브러리

백엔드와의 협업을 진행하기 앞서, MSW의 덕을 봤다.

API 완성을 기다릴 필요 없이 예상 명세를 토대로 mocking 로직을 작성해두고, 이를 기반으로 개발을 진행했다.

기본적으로는 성공, 실패 응답에 대해서 mocking을 작성하고 테스트했는데,

백엔드의 작업이 예상치 못하게 길어지는 경우에는 백엔드 로직의 일부를 작성해서 더 다양한 경우를 테스트해도 좋을 것 같다.

4-2. SOP / CORS 관련 에러와의 첫 만남

Same Origin Poilcy(동일 출처 정책)
동일한 Origin(Protocol, host, port) 사이에서만 리소스를 공유할 수 있다는 정책

Cross Origin Resource Sharing(교차 출처 리소스 공유)
Origin이 다르더라도 리소스를 공유할 수 있도록 하는 정책.
SOP정책에 의해 제한되었던 교차 출처간 리소스 공유가 가능해졌다.

'왜 안돼?'를 가장 많이 외치게 한 에러가 아닐까 싶다...

개발 환경(http)에서 배포 서버(https)로 API 요청을 해놓고 안된다고 징징거린 적도 있었고(혼자 ),

백엔드 로직의 설정 누락인 경우도 있었다.(ex. Access Control expose headers)

무엇 하나 쉽게 내어주지 않는 브라우저의 보안정책에 시원하게 담궈지고 나서야 방향을 잡아갈 수 있었다.

본격적인 프로젝트를 진행하게 되는 레벨3, 4에서는 간단한 에러나 빠르게 해결된 해프닝도 기록해보는 습관을 가지려고 한다.

더 꽉꽉 눌러담은 레벨2

꺼억~

고봉밥 만큼 적절하게 표현되는 짤이 없더라.

이번에도 아쉽긴 하다.

워낙 방대한 내용이었기 때문에 놓친 부분도 많다.

그럼에도 매 순간 노력했기에 한 공기 가득 채워졌다.

이제 절반을 마쳤다.

앞으로 진행하게 될 프로젝트도 정말 기대된다!

힘내보자 도현아!

react - key props(feat. 공식문서)

Creative_Lee — Wed, 14 Jun 2023 00:58:20 +0900

이번 포스팅에서는 react의 key props에 대해 탐구하는 시간을 가져보겠습니다.

1. Key란 ?

React 구 공식문서에는 이렇게 나와 있습니다.

Key는 React가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕습니다.
key는 엘리먼트에 안정적인 고유성을 부여하기 위해 배열 내부의 엘리먼트에 지정해야 합니다.

React 신 공식문서에는 이렇게 나와있구요.

key는 각 컴포넌트가 어떤 배열 항목에 해당하는지 React에 알려주어 나중에 매칭할 수 있도록 합니다.
이는 배열 항목이 (정렬 등으로 인해) 이동하거나, 삽입되거나, 삭제될 수 있는 경우 중요해집니다.
잘 만들어진 key는 React가 정확히 무슨 일이 일어났는지 추론하고 DOM 트리를 올바르게 업데이트하는 데 도움이 됩니다.

아직 잘 모르겠네요...!

key가 등장한 이유를 먼저 알아봅시다...!

2. key가 등장한 이유(feat. diffing Algorithm)

key의 등장은 react의 diffing Algorithm과 밀접하게 연관되어 있습니다.

설명에 앞서 위 내용에 대한 구 공식문서 링크를 첨부합니다.

가볍게 정리하면 다음과 같습니다.

react는 보다 효과적으로 UI를 갱신하기 위해 diffing Algorithm을 사용합니다.
이를 통해 기존과 비교해 어떤 변화가 있었는지 판단하고, 변경된 사항만을 실제 DOM에 반영합니다.
(기존 react element tree와 새로운 react element tree를 비교합니다.)
하지만 트리 변환을 위한 최첨단의 알고리즘도 O(n3)의 복잡도로 매우 비싼 연산비용이 발생했고,
react는 2가지 가정을 기반으로 이를 O(n) 복잡도까지 최적화 했습니다.
이 2가지 가정 중 하나가 바로 key props입니다.
개발자가 list element의 자식 element에 key를 명시하여 어떤 자식 element가 변경되는지 알려줄 수 있습니다.

3. key를 명시하지 않았을 때 발생하는 비효율

그렇다면, 하라는대로 하지 않았을 때 어떤 비효율이 발생할까요?

key가 없을 때 볼 수 있는 경고

특정 위치에 있는 요소에 이동, 삽입, 삭제 등의 작업이 일어날 경우 react는 각 자식 element를 고유하게 식별할 수 없기에

이미 존재하는 자식 element 임에도 다시 랜더링 할 수 밖에 없습니다. 상당히 비효율적이죠.

이는 배열의 규모가 크고 복잡할수록 더욱더 비효율적이게 됩니다.

4. 배열의 index를 key로 사용하는 것을 지양해야 하는 이유(버그 가능성)

한편, react는 key가 명시되지 않은 경우 기본적으로 배열의 index를 key로 사용합니다.

하지만 이는 공식 문서에도 나와 있듯 성능 문제뿐만 아니라, 버그를 야기하기도 합니다.

예시를 통해 직접 보며 알아봅시다.

4-1. 예시 코드 & 설명

예시 코드는 다음과 같습니다.

// 부모 컴포넌트
const Parent = () => {
  const [names, setNames] = useState(["도밥", "세인", "참새"]); // 부모의 배열 상태

  // 배열 요소 삭제 함수
  const deleteName = (targetName) => {
    const updatedNames = names.filter((name) => name !== targetName);
    setNames(updatedNames);
  };

  return (
    <div className="App">
      {names.map((name, idx) => (
        <Child key={idx} name={name} deleteName={deleteName} /> // index를 key로 사용
      ))}
    </div>
  );
}

부모 컴포넌트는 크루들의 이름으로 이루어진 배열을 순회하며 자식 컴포넌트를 랜더합니다.

이때 index를 key로 사용했습니다.

// 자식 컴포넌트
const Child = ({ name, deleteName }) => {
  const [text, setText] = useState(""); // 각 자식의 고유 상태

  return (
    <>
      <input
        value={text}
        onChange={(e) => setText(e.target.value)}
      />
      <div>{name}</div>
      <button onClick={() => deleteName(name)}>
        {`이름 배열에서 ${name} 지우기`}
      </button>
    </>
  );
};

각 자식 컴포넌트는 고유한 text 상태를 가지고 있습니다.

독립적으로 입력 가능

때문에 각 텍스트 상자에 독립적으로 입력이 가능합니다.

4-2. 삭제 실행 결과... 버그 발생!

이때 이름 배열의 맨앞에 있는 '도밥'을 삭제하면 어떻게 될까요?

의도대로라면 다음과 같이 동작해야 합니다.

'세인', '참새' 만을 포함한 배열로 리렌더링
자식 element는 각 text 상태를 그대로 유지함

한번 삭제해 봅시다.

????

삭제는 되었으나, text 상태가 이상합니다!

이미 삭제된 '도밥'의 text 상태를 '세인'이 가지고 있네요.

'참새'의 text 상태는 사라지고 엄한 '세인'의 text 상태를 가지고 있습니다!

버그가 발생했습니다.

4-3. 버그의 이유

버그의 이유는 구 공식 문서에 다음과 같이 나와 있습니다.

컴포넌트 인스턴스는 key를 기반으로 갱신되고 재사용됩니다.
배열의 index를 key로 사용하면 항목의 순서가 바뀌었을 때 key 또한 바뀔 것입니다.
그 결과로 컴포넌트의 state가 엉망이 되거나 의도하지 않은 방식으로 바뀔 수도 있습니다.

구 공식문서에서 추천하는 index를 key로 사용했을 때의 부정적인 영향 상세 설명 블로그를 보면 다음과 같이 말합니다.

If the key is same as before React assumes that the DOM element represents the same component as before.
키가 이전과 동일한 경우 React는 DOM 요소가 이전과 동일한 구성 요소를 나타낸다고 가정합니다.

위 내용을 토대로 예제를 풀어서 설명하면 다음과 같습니다.

도밥(0), 세인(1), 참새(2) 의 key를 가지고 첫 렌더
도밥 삭제
세인(0), 참새(1) 의 key를 가지고 리렌더
- 이때 react는 0, 1이라는 key를 확인하고 기존 0, 1 key에 해당하는 컴포넌트 재사용
- 기존 0, 1 key에 해당하는 컴포넌트는 각각 '나는 도밥', '나는 세인' text 상태를 가지고 있음.
의도하지 않은 버그 발생

4-4. Bug fix !

이제 버그를 고쳐봅시다.

 return (
    <div className="App">
      {names.map((name) => (
        <Child key={name} name={name} deleteName={deleteName} /> // 고유한 key를 사용
      ))}
    </div>
  );

부모 컴포넌트에서 고유한 key를 사용하도록 변경했습니다.

편안

이제 의도한 대로 동작하는 것을 확인할 수 있습니다.

번외. key 유무에 따른 렌더링 성능 테스트

포스팅 당시 마침 크루 요술토끼가 key의 유무에 따른 랜더링 성능 테스트를 하고 있었어요.

직관하다가 부탁해서 성능 측정 자료를 제공받았습니다! (고마워요)

1. 테스트 설명

총 5만개의 div, span

홀수 번째에는 div를, 짝수 번째에는 span을 넣어 총 5만개의 요소가 들어있는 list를 랜더링한 모습입니다.

테스트 하고자 하는 내용은 다음과 같아요.

n번째 요소와 n+1 번째 요소의 위치를 서로 바꾸도록 하고 그 과정에서의 성능을 profiler로 측정한다.
- 대조군 1에는 고유한 key를 제공한다.
- 대조군 2에는 key를 제공하지 않는다.

의도한 결과는 다음과 같습니다.

대조군 1은 자식요소의 위치만 변경되었다는 사실을 알 수 있고 자식 컴포넌트는 재사용된다.
대조군 2는 모든 자식 요소에게 부여된 새로운 key로 인해 5만개의 자식컴포넌트가 모두 새롭게 그려진다.

2. 테스트 결과

다음은 profiler로 확인한 결과입니다.

Key: 3.7s / no Key: 18.5s

Key : 3.7s

no Key : 18.5s

다른 조건들은 고려되지 않아 정확하지는 않겠지만,

랜더링 성능 측면에서 key가 주는 영향은 생각보다 엄청나다는 사실을 확인할 수 있었습니다.

끄읏...!

공식문서는 언제나 옳다.

serialization(직렬화)/deserialization(역직렬화)

Creative_Lee — Tue, 9 May 2023 09:56:06 +0900

우테코 동료 크루 솔로스타의 미션 코드와 리뷰 내용을 보며 학습중, 한 hook 코드에서 다소 생소한 단어들을 발견했어요.

생소한 단어들에 대한 의문을 해결하고 기억하기 위한 포스팅이 되겠습니다~!

~~하나의 스토리처럼 기억하기 위해 hook 추상화 과정도 넣게 되었습니다.~~
작성하던 중, context가 자주 바뀌어 글 이해를 방해한다고 생각해 따로 분리하게 되었습니다.(hook 추상화 글 바로가기)
솔로스타에게 허락을 받았음을 미리 알립니다

출발~

1. hydrate / dehydrate

export const usePersistedState = <S = undefined>(key: string, initialState: S) => {
  const dehydratedState = useMemo(() => localStorage.getItem(key), [key]);  // <-- 여기 
  const hydratedState = hydratedState === null ? initialState : JSON.parse(dehydratedState);  // <-- 여기 

  const [internalState, internalSetState] = useState<S>(hydratedState);

  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(internalState));
  }, [key, internalState]);

  return [internalState, internalSetState] as const;
};

위 hook 코드를 보면 hydrate, dehydrate 등의 생소한 단어들이 보입니다...

우선 사전적 의미를 찾아봤어요.

papago swag

'어떤 것'을 '물'이라고 은유적으로 표현한 느낌인데... 어느정도 추측만 가능할 뿐, 정확히는 모르겠네요...

GPT에게 물어보니 보다 명쾌한 대답을 받을 수 있었어요!

정리하면 다음과 같습니다.

hydrate: 간단한 형태로 변환된 데이터를 원래의 복잡한 구조나 객체로 변환하는 과정을 일컫는 말(수분 보충)
dehydrate: 복잡한 데이터 구조나 객체를 더 간단한 형태로 변환하는 과정을 일컫는 말(수분 제거)

그럼 이제 코드를 다시 봅시다.

 const dehydratedState = useMemo(() => localStorage.getItem(key), [key]);  // <--- 여기 
 const hydratedState = hydratedState === null ? initialState : JSON.parse(dehydratedState);  // <--- 여기

로컬스토리지에서 불러온, 이미 간단한 형태로 변환되어있는 값을 'dehydrated'State

변환된 데이터를 JSON.parse 메서드를 통해 원래의 구조로 재변환한 값을 'hydrated'State

라고 네이밍한 것을 알 수 있네요!

2. Serialization(직렬화) / Deserialization(역직렬화)

은유적인 표현을 알고나니, 정식 명칭이 궁금했습니다.

다시 GPT에게 물어봅시다.

serialization(직렬화) / deserialization(역직렬화) 이라는 명칭을 알려주었습니다.

조금 더 자세하게 물어봅시다.

hydrate / dehydrate와 비슷하지만 데이터 저장, 전송, 공유의 늬양스가 추가되었습니다.

정리하면 다음과 같습니다.

serialization: 저장, 전송, 공유에 유리하도록 데이터를 특정 형식에 맞춰 변환하는 과정
deserialization: 위 이유로 변환된 데이터를 다시 사용하기 위해 원래의 구조로 되돌리는 과정

예시를 들면 다음과 같습니다.

로컬스토리지에 값을 저장하기 위해서는 JSON 문자열 형식을 전달해야 합니다(특정 형식)
이를 위해 우리는 JSON.stringify() 를 사용하죠(변환)
이를 serialization(직렬화)한다고 할 수 있습니다.
또한 dehydrate(수분 제거) 라고 은유적으로 표현할 수 있죠.

로컬스토리지에서 가져온 값을 사용하기 위해서는 JSON 문자열 형식을 기존 형태로 변환해야합니다.
이를 위해 우리는 JSON.parse() 를 사용하죠.(재변환)
이를 deserialization(역직렬화)한다고 표현할 수 있습니다.
또한 hydrate(수분 보충) 라고 은유적으로 표현할 수 있죠.

dehydrate == serialization(직렬화)
hydrate == deserialization(역직렬화)

'de'의 쓰임이 같지 않다는 것에 유의합시다.

보통 사용되는 기술, 데이터 형식 및 처리 방법에 따라 용어들이 조금씩 차이가 있다고 합니다.

Marshalling / Unmarshalling - 프로토콜 버퍼(Protocol Buffers), RPC(Remote Procedure Call) 등

Encoding / Decoding - base64 인코딩 등

3. parsing - 번외편

parsing은 데이터를 읽고 그 안에 포함된 정보를 추출하거나 원하는 형식으로 변경하는 작업입니다.

또한 문법을 확인하고 검증하는 작업도 parsing이라고 표현합니다

deserialization과 비슷한 맥락이지만, parsing이 이를 포함하는 더 큰 개념이라고 할 수 있겠습니다

4. hook 코드 다시보기

export const usePersistedState = <S = undefined>(key: string, initialState: S) => {
  const dehydratedState = useMemo(() => localStorage.getItem(key), [key]); 
  const hydratedState = hydratedState === null ? initialState : JSON.parse(dehydratedState); 

  const [internalState, internalSetState] = useState<S>(hydratedState);

  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(internalState));
  }, [key, internalState]);

  return [internalState, internalSetState] as const;
};

단어가 내포한 뜻을 알고나니, 각 코드 라인을 이해하기 쉬워지지 않았나요?

다른 개발자와의 원활한 소통을 위해서라도 CS지식은 필수라고 생각드네요...

천천히 학습하겠다고 다짐하며 글을 마무리 하겠습니다~!

기본이 중요하다!

우테코 레벨1 학습 내용 총정리

Creative_Lee — Thu, 6 Apr 2023 21:56:35 +0900

레벨1 학습 내용 총정리

말도 많고 탈도 많았던 레벨1을 성공적으로 마무리 했다.

폭풍처럼 지나간 8주... 배운 것이 정말 많다.

방대한 학습 내용을 정리하며 지식을 조각모음 해보는 시간을 가져보자!

그래서 뭘 배웠어? ‍♂️

개인적으로 몰입했던 키워드는 다음과 같다.

관심사의 분리(feat. MVC 패턴)
컴포넌트
테스트

1. MVC 패턴

다음은 MDN에 나와있는 MVC 패턴의 정의이다.

MVC는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다.
소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다.

1-1. why MVC?

'MVC? 프론트엔드에 적용하기엔 구리다는데...' 숱하게 들었던 말이다.

하지만 '비즈니스 로직과 UI로직의 분리'에 대해 감이 오지 않았다.

전체 미션 요구사항 중 어쩌면 가장 중요하다고 할 수 있었던 핵심이었다.

때문에 많은 사람들의 노력으로 만들어진 정형화된 패턴을 따라 코드를 작성하며 감을 잡고 싶었다.

그중 레퍼런스가 가장 많았고, 여러 디자인 패턴의 근본이 된다고 생각하여 MVC 패턴을 선택해 도입하게 되었다.

이를 미션에 적용하며 직접 느낀 장점, 단점은 다음과 같다.

1-2. MVC 패턴의 장점

명확한 관심사의 분리

console 기반의 App을 web 기반으로 변경하는 과정에서 위 장점을 체감했다.

1단계에서 구현한 도메인 로직을 (최대한) 수정하지 않고, UI만 변경한다.
- 로또 미션 2단계 요구사항 중 -

View를 변경함에 있어서, domain로직의 큰 변화 없이 거의 모든 로직을 재사용할 수 있었다.

서로의 관심사가 잘 나뉘어져 있었기에 가능한 일이었다.

가독성 및 코드 흐름 개선

디렉터리 및 파일이 각 역할에 맞게 분리되었고, 이에따라 자연스레 코드의 가독성이 좋아졌다.

App의 전반적인 흐름 또한 파악하기 쉬웠다.

패턴 도입 이전의 코드와 비교하면 정말 월등히 좋아졌다고 생각했다.

그렇다면 단점은 무엇이었을까?

1-3. MVC 패턴의 단점(web)

너무 많은 View 로직

web 환경에서는 DOM 조작, 사용자 입력 등 컨트롤해야 할 View로직이 너무 많았다.

이에 따라 자연스럽게 View가 커졌고, 이를 분리해야 했다.

App의 규모가 조금만 커져도 무수히 많은 View가 필요했을 것이고, 관리가 힘들었을 것이다.

자연스레 커진 Controller

View가 많아지면서, 자연스레 이를 관리하는 Controller 또한 커졌다.

View와 Model 사이의 흐름 제어 역할을 수행하기에 원래도 비교적 로직이 많고 복잡했는데, 더 커졌다.

점차 가독성이 나빠졌다.

이벤트 관련 코드를 View, Controller로 나누기 애매함

사용자와 인터렉션하는 코드를 작성할 때 View와 Controller의 경계가 명확하지 않았다.

input요소로 사용자 입력을 받아 Model을 변화시키려고 한다.
이때 위 이벤트의 트리거는 button 요소의 click이다.

document.querySelector('button').addEventListener('click', (e) => {
	// input 요소의 값을 통해 Model 로직 실행 
})

button의 클릭이 곧 이벤트의 발생이고, 이벤트의 발생이 곧 Model의 변화였기 때문에

이벤트 등록 코드 및 핸들러 코드의 위치를 나누기 애매했다.

Controller의 개입이 애매하지 않나... 생각했다.

1-4. 결국 중요한것은 관심사의 분리

MVC를 web에서 적용했을 때의 단점을 체감한 후 더 이상 사용하고 싶지 않았다.

마침 컴포넌트 기반의 미션이 주어지면서 또 한번 사고의 전환이 필요했고, 조금씩 MVC의 틀을 허물게 되었다.

이후 제일 중요한 핵심은 '관심사의 분리' 라고 생각했고,

'비즈니스, UI 로직 분리'와 같은 본질적인 부분에 집중하기로 했다.

2. 컴포넌트

재사용 가능한 독립 모듈, App을 구성하는 기본단위이다.

블럭!

2-1. 컴포넌트에 대한 관점 변화

컴포넌트 기반의 사고를 요구했던 미션들을 통해 다음과 같이 개념을 확장했다.

미션3 초반) 도메인 데이터를 통해 동적으로 랜더 가능하면 컴포넌트!
미션3 중반) 상수 데이터로 랜더 가능한, 반복되는 태그들(ex. select - option)도 분리 - 이것도 컴포넌트!
미션3 마지막) 자신의 이벤트를 가지면서 핸들러로직을 주입받아 랜더 + 이벤트 등록 가능해야 컴포넌트!
미션4) 도메인과 관련없이 재사용 가능한 범용 컴포넌트 VS 도메인 종속적인 컴포넌트

2-2. 범용 컴포넌트 vs 도메인 종속 컴포넌트

범용 컴포넌트와 도메인 종속 컴포넌트는 개인적으로 가장 의미있었고, 또한 중요한 개념이라고 생각한다.

어쩌면 당연한 개념이지만, 미션중에는 개념이 확립되지 않고 마구 뒤섞여 혼동이 왔었다.

미션4 step2 PR에 첨부한 구조도를 보면 혼동과 고통의 흔적이 남아있다.

장장 3일간의 사투를 복기해보자.

2-2-1. 바라던 구조(하위 컴포넌트를 상위에서 전달 / 범용 컴포넌트)

바라던 구조

MovieList, Modal처럼 컨텐츠가 있는 컴포넌트는

상위 컴포넌트인 App을 통해 하위 컴포넌트(Card, DetailCard)를 전달 받는 구조로 구성하고 싶었다.

이유는 간단하다.

Modal은 컨텐츠가 무엇인지는 관심이 없고, 어떤 컨텐츠던 전달 받아 랜더링 하는 역할만 가지도록 하고 싶었다.

즉, 도메인에 종속되지 않고 재사용 가능한 범용 컴포넌트로 만들고 싶었다는 말이다.

피드백을 받기 전까지는 위 구조가 맞다고 생각했다.

반드시 전달 하는 구조로 구성하고 싶었지만, 결과는 실패

읽는 입장에서 여러 의문이 들겠지만 잠시 접어두고 최종 구조를 먼저 보자.

2-2-2. 최종 구조(하위 컴포넌트를 직접 import / 도메인 종속 컴포넌트)

최종 구조

MovieList, Modal 컴포넌트가 하위 컴포넌트(Card, DetailCard)를 import 하여 직접적으로 알고 있다.

import를 통해 컨텐츠를 직접 알아버리면, 도메인 종속적인 컴포넌트가 되어버려 재사용 할 수 없다...

피드백을 받기 전까지는 틀린 구조라고 생각했다.

2-2-3. 간단했던 해결 방법

오랜 시간 고민했던 부분이고, 틀렸다고 생각했기에 리뷰어어게 도움을 청했다.

다음은 리뷰어의 피드백 내용중 일부이다.

최종 구조가 일반적인 컴포넌트 멘탈모델에 부합하지 않나 싶은데...
모든 컴포넌트가 App에서 관리되어야한다고 생각한 이유가 궁금합니다.

Modal을 extend하는 MovieDetailModal을 별도로 구성해보면 어떨까 싶어요.
그렇게한다면 Modal자체는 도메인을 알지 않는 일반적인 UI컴포넌트로 남을 수 있을거라는 생각이 있어요.

오히려 최종 구조가 일반적이라는 말씀을 해주셨다.

Modal은 내가 원하던 대로 범용적으로 유지하고,

이를 상속받는 도메인 종속적인 컴포넌트를 만들어 사용하면 되는 것이었다...!

고민이 무색하게도... 해결방법은 간단했다.

2-2-4. 틀리지 않았다. 정답도 없다.

Modal을 범용 컴포넌트로 잘 설계 했음에도,

'상위에서 컨텐츠를 전달받아야 한다'라는 스스로 세운 규칙 때문에 더 나아가지 못했다.

행동을 과하게 제한하는 규칙에 대해 의심을 하지 못했다.

오히려 규칙에 맞지 않는 방법들을 틀렸다고 단정지었다... ‍♂️

이번 삽질 경험으로 범용 컴포넌트, 도메인 종속 컴포넌트에 대한 개념을 확실하게 채울 수 있었다.

또한 현재 컴포넌트에 대한 개념을 실시간으로 확장중이다.

컴포넌트와 관련된 여러 아티클을 보며 생각을 넓혀나가고 있다.

실질적인 코드의 차이 없이 이름만으로도 구성이 맞고 틀리고가 가능하다는걸 알아가면 좋지 않을까 생각해봅니다.
- 리뷰어의 한마디 -

레벨1에서의 삽질이 레벨2의 나에게 큰 도움이 될거라고 생각한다.

3. 테스트

작성한 코드가 의도대로 동작하는 지 검증할 수 있는 수단이다.
개발자들에게는 프로덕션 코드의 설명서 역할로 사용되기도 하고, 코드에 대한 검증을 통해 심리적 안정을 주기도 한다.
리팩토링이 필요한 상황에서 유연한 대응을 도와주는 역할도 한다.

테스트 피라미드

3-1. 단위 테스트(Unit) - 테스트 하기 좋은코드

단위테스트의 장점들을 체감한 이후로는, '테스트 하기 좋은 코드란 무엇인가?' 에 대해 고민했다.

내가 생각하는 테스트하기 좋은 코드는 다음과 같다.

같은 input에 대해 같은 output을 보장하는 코드(함수)
- output을 예측하기 쉬운 코드 === 코드가 의도대로 동작하는지 검증하기 쉽다.
제어할 수 없는 값, 동작에 의존하지 않는 코드
- 제어할 수 없는 값, 동작 -> Random / Date , 사용자 input, API 호출 등의 코드
  테스트 대상 코드(함수)에 위 동작이 혼재하면, 테스트 하기 어렵다. (mocking등 추가적인 처리를 해주어야 함)

제어할 수 있는 값(제어해야 하는 값)만 제어하는 코드는 관심사가 잘 분리되었을 확률이 높고

이런 코드는 다시 테스트 하기 좋은 코드로 귀결된다.

즉, 테스트 하기 좋은 코드 == 좋은 코드라고 생각한다.

단위테스트 시 mocking이 필요하다면, 먼저 관심사가 제대로 분리되지 않은 코드인지 생각해 보자.

다행히?! 아직까지는 mocking이 필요한 적이 없었다. (Domain 로직에 대해서는 분리를 잘 하지 않았나...)

앞으로도 최대한 경계해 볼 생각이다.

3-2. E2E 테스트(feat. cypress)

생각보다 어렵지 않았던 E2E 테스트(빙산의 일각이라 그런 것 같다..ㅎ)

서비스를 이용하는 사용자의 입장에 서서 flow를 테스트 했다.

API 요청에 대해 미리 만들어 놓은 고정된 응답(fixture)을 받게 해주는 intercept()도 사용해 보았다.

cypress Custom command를 만들어 가독성을 높여보기도 했다.

하지만 E2E 테스트를 작성하며 의미있는 수준의 장, 단점을 느끼지는 못했다.

unit 테스트에 비해 아직 경험치가 낮아 그렇다고 생각한다.

레벨2 미션에서도 추가로 적용하고 학습해 보자.

꽉꽉 눌러담은 레벨1

아쉬운 부분이 있긴하지만 정말 꽉~ 채워 학습했다.

푸짐하다 푸짐해!

총 정리 포스팅을 통해 학습했던 지식이 넘쳐 흐르지 않도록

잘 눌러 담은 것 같아 기분이 좋다.

잘 쉬고 잘 소화해서 레벨2에도 가득 먹어보자!

22년의 이도현

Creative_Lee — Fri, 30 Dec 2022 18:39:20 +0900

다니던 회사를 그만두고 프로그래밍 공부에 전념해야겠다고 다짐한 후 벌써 1년이 흘렀다.

22년을 마무리하는 시점에서 지난 1년 동안 이루어 낸 것들과 아쉬웠던 부분을 정리해 보고,

23년 목표를 설정해 보려고 한다.

이 열정 내년에도 가득하기를

22년에 이루어 낸 것들

개발과 관련된 기반 지식을 많이 쌓았다.

멀게만 느껴졌던 서버, DB 와 같은 분야를 가볍게나마 배워보면서 전체적인 웹의 흐름을 조금 더 이해할 수 있게 되었다.

또한 알고리즘과 자료구조에 대한 공부를 통해 구현능력과 사고력도 높아진 것 같다.

자바스크립트 코어도 꾸준히 학습하면서 기본 동작 방식에 대한 이해도 할 수 있었다.

처음으로 누군가에게 도움 되는 서비스를 만들었다.

친구의 업무 환경을 개선해 줄 수 있는 서비스를 만들어 실제로 유의미한 성과를 냈는데,
이를 통해 내가 공부하고 있는 방향에 대한 불확실한 마음을 덜어 낼 수 있었다.

또한 프로젝트를 통해 나에게 어떤 부분이 부족한지 명확하게 알게 되었다.

우아한테크코스 5기 프론트엔드 과정에 최종 합격했고, 많은 것을 배웠다.

회고를 쓰는 지금 이 순간에도 어안이 벙벙하다.

지원 준비 과정, 4주간의 프리코스, 1차 합격자 발표 및 최종 테스트까지

대략 5개월간의 긴 여정 끝에 운이 좋게도 합격하게 되었다.

이 시간 동안 클린 코드와 OOP, 테스트 코드와 같이 막연했던 부분들을 정면돌파하며 배울 수 있었다.

22년에 아쉬웠던 것들

작은 조각들로 이루어진 지식들을 하나로 모으지 못했다.

Javascript, React, TypeScript, Node, Express, mySQL과 같은 언어나 기술부터

자료구조, 알고리즘, CS, 네트워크처럼 개발의 근본이라고 할 수 있는 것들까지...

나의 뇌 속에 정리되어 있지 않은 상태로 여기저기 흩어져 있는 것 같다.

하나라도 더욱더 확실하게 파고들었어야 한다는 아쉬움이 든다.

가벼운 토이 프로젝트라도 다양하게 시도했어야 한다.

22년에는 1개의 프로젝트만 만들었는데, 작은 것이라도 여러 개 만들어 봤으면 어땠을까 생각이 든다.

TS, 서버 등등 다양한 것을 배웠지만, 실제로 이것들을 적용해서 프로젝트를 만들어보는 것만큼 더 좋은 복습은 없었을 것이다.

그러지 못한 것이 아쉽다.

또한 지금까지 만든 2개의 프로젝트에서 느꼈던 부족한 점이 많은데

새로운 프로젝트를 만들면서 이를 보완해 보는 시간을 가졌다면 더 좋았을 것 같다.

23년에 이루어 낼 것들

당장 1월 2일부터 평일에는 아르바이트, 주말에는 서울에서 생활할 방을 구하러 다녀야 한다.

2월부터 시작되는 우테코를 위해 마음가짐을 바로 하는 시간이 될 것 같다.

그 후에는 12월까지 10개월간 진행되는 우테코 5기 과정을 잘 마치고 싶다.

우테코를 통해 성장해서 누구나 함께 일하고 싶은 개발자가 될 것이다.

기술적으로는 현재 사용 중인 react를 보다 명확한 목적을 가지고 사용할 수 있도록 공부할 것이다.

이후 서버와 ssr에 대한 공부를 바탕으로 next.js 를 꼭 배워 사용해 볼 것이다.

23년 이후의 내가 바로 취업할 수 있도록,그에 맞는 실력을 가질 수 있도록 노력해야한다.

좋은 동료들도 많이 알고 싶고

나 역시 그들에게 좋은 동료가 됐으면 좋겠다

조금만 더 힘내자!

고생했다 22년! 잘가라!

우테코 프론트엔드 5기 - 최종 코딩 테스트 후기

Creative_Lee — Wed, 21 Dec 2022 00:38:56 +0900

12월 17일 토요일, 최종 코딩 테스트를 치렀다.
이번 후기에서는 프리코스 종료부터 시험 이후의 복기까지의 과정과
우테코 지원 과정을 최종적으로 마치며 드는 생각을 정리해 보려고 한다.

1차 합격자 발표까지 주어진 3주

프리코스 4주 차를 마치고, 1차 합격자 발표까지는 3주 정도의 시간이 있었는데,
프리코스 종료 안내 메일에서는 2~4주 차 미션을 다시 구현해 보길 권했다.
매주 미션을 진행하면서도 스스로 부족함을 느낀 부분이 많았고,
제출했던 미션 코드를 보면서 경악을 했던 기억도 있던 터라 자체적으로 프리코스를 연장해서 진행했다.

‍♀️ 기존 미션 복습

프리코스 종료 이후 바로 숫자 야구, 로또, 다리 건너기 미션을 복습했다.

복습을 하면서, 이전 제출 코드와는 확연히 비교되는 코드를 작성할 수 있었다.

물론 이미 한 번씩 구현해 본 기능들이라 익숙하기도 했지만, 이를 감안하더라도 분명한 발전이 있었다.

간단히 정리하자면 다음과 같다.

새로운 클래스로 기능을 나누고자 할 때, 분리의 기준이 생겼다.

분리를 통해 어떤 필드 변수를 생성하게 될지, 분리로 인한 이점과 단점은 어떤 것일지 생각하고 분리할 수 있게 되었다.

기존에 비해 생각할 시간이 더 필요해졌는데, 이전까지는 너무 가볍게 생각하며 분리한 게 아닌가 싶다.

밑줄 친 필드는 모두 같은 데이터이다.

2주 차 미션 제출 코드를 보면 기준 없는 클래스 분리의 결과가 그대로 나타난다.
각 클래스에 같은 데이터인 필드가 3개나 중복되어 존재한다. 물론 중복되어 존재할 이유가 없다.
이제는 더 이상 이런 코드를 작성하지 않을 것이다.

테스트에 대한 생각을 하며 기능 코드 작성을 할 수 있게 되었다.

제어할 수 없는 코드가 무엇인지 구분할 수 있게 되었고,
이를 인지해서 미리 도메인 로직에서 분리할 수 있도록 코드를 작성하는 능력이 생겼다.

해당 코드를 도메인 로직이 있는 클래스에서 사용하게 되었을 때, 테스트가 어려워진다는 사실을 4주 차에서 경험했기 때문이다.
또한 '좋은 코드란 무엇인가?'에 대해 테스트를 관점으로 생각할 수 있는 능력도 생겼다.

4주 차 제출 코드

처음엔 제어할 수 없는 코드의 개념을 몰랐기에 흐름이 자연스럽다고 생각하면 그대로 작성했었다.

개념을 알고 난 후에는 코드의 문제점을 파악하여 리팩토링할 수 있게 되었다.

최종적으로 현재는, 처음부터 충분한 생각을 통해 제어할 수 없는 코드를 도메인 로직에서 분리할 수 있다.

물론 아직 미션과 같은 콘솔 미니게임 형식 외의 코드에서 해당 상황을 접한 적은 없지만,

이런 부분들도 고려해야 한다는 것을 인지하게 된 것만으로도 큰 발전이라고 생각한다.

‍♀️ 커스텀 미션 만들어 풀어보기!

미션 복습 이후에는 무기 강화 게임 커스텀 미션을 만들어 커뮤니티에 공유하고, 직접 풀어보기도 했다.

만약 최종 테스트 기회가 주어진다면 새로운 미션을 마주해야 했기 때문에

과연 새로운 미션에서도 학습한 내용을 녹여낼 수 있을지 테스트해보고 싶었기 때문이다.

전체적인 틀은 4주 차 미션을 바탕으로 잡았고, 테스트 코드를 비롯한 조건을 변형하여 미션을 만들었다.

이후 완성된 커스텀 미션을 풀어보고 스터디원과 코드 리뷰하는 시간을 가졌는데,
프리코스에서 학습한 내용을 바탕으로 좋은 피드백을 주고받을 수 있었다.

또한 해당 미션을 우테코 지원자 커뮤니티에도 공유했다.

기분이 이상하더이다...

하하...ㅎ

그 결과... 인생 처음으로 누군가 내 저장소를 fork 하는 경험을 할 수 있었고,

미션의 완성도는 낮았겠지만, 지원자 동료들에게 작게나마 도움이 된 것 같아 뿌듯했다.

가져가서 풀어주신 분들께 감사하다는 말씀을 전합니다!

1차 심사 발표 결과 합격!!

그렇게 3주가 흘러 합격자 발표 당일 오후...

프리코스를 후회 없이 마쳤기 때문에 덤덤하면서도, 기대 반 걱정 반으로 메일을 확인했다.

감격...

결과는 1차 합격... 메일 확인하면서 '됐다!' 하며 크게 소리 질렀던 게 기억난다.

오프라인 테스트... 5시간의 시간 제한...

한 5분쯤 1차 합격의 기쁨을 누렸을까... 갑자기 엄청나게 긴장이 되기 시작했다.

최종 코딩 테스트는 오프라인 테스트였고, 5시간이라는 한정된 시간 동안 최종 미션을 구현해야 했다.

자랑은 아니지만... 사실 나는 실력에 대해 평가를 받은 경험이 없었다...
(현재는 '우테코 오프라인 최종 테스트' 라는 경험이 생겼다 )

흔하다면 흔한 온라인 코딩 테스트 응시 경험도 없었고,
프로그래밍 공부를 시작하기 전에 근무했던 직장들도 면접 외에 '테스트'의 개념은 없는 회사였다...

최종 코딩 테스트 까지... 단 3일

발표 당일인 수요일부터 최종 테스트 날인 토요일까지

수, 목, 금 딱 3일이 남았었다.

당장 내가 해야 할 것은 무엇인가 생각해 봤고, 시간 내에 과제를 구현하는 연습이라고 생각했다.

사실 프리코스 과정에서 스스로 구현 속도가 느리다는 것을 어림 짐작으로 느끼고 있었다.

아침 9시부터 새벽까지 매일 구현했는데도 막상 구현한 것은 얼마 되지 않는 상황이 여러 번 있었다. 대부분 가까스로 끝냈던 것 같다.

때문에 남은 3일을 구현 연습에 모두 사용하기로 했다.

기능 구현 목록 작성 연습

나는 구현 과제의 시작이었던 2주 차 미션에서 기능 구현 목록 작성에만 하루 이상이 걸렸었다.

2주 차 공통 피드백

위 2주 차 공통 피드백을 통해 첫 작성 시 내용을 간소화하고자 했고, 구현하며 업데이트하는 식으로 개선했었다.

그럼에도 목록 작성에 꽤나 많은 시간을 소모했다고 생각했기에, 기능 구현 목록 작성을 따로 연습했다.

2~4주 차 미션부터 커스텀 미션까지 구현 목록만 쭉 써보면서 시간을 최소한으로 사용하려고 했다.

연습을 하면서 느꼈던 점은 애플리케이션의 전체적인 흐름을 이해하는 것이 제일 중요하다는 점이다.

흐름을 충분히 잘 이해했다면, 세부적인 조건과 제약사항은 그때그때 녹여낼 수 있다고 생각했다.

커스텀 미션 모의 고사 결과...

최종 테스트 하루 전 금요일에는 스터디원이 만들어 공유해 준 커스텀 문제를 받아 1시부터 6시까지 모의고사를 진행해 보았다.

실제 환경과 비슷하면 좋지 않을까 싶어 근처 도서관 노트북 코너에서 진행했다.

결과는 좋지 않았다. 2/5 정도만 구현할 수 있었고 시간이 한참 부족했다.

스스로 복기해 보니 대부분의 시간을 클래스 분리, 특정 기능 메서드의 위치 고민, 파일 분리, 변수명 고민에 사용하고 있었다.

평상시에 프로그래밍을 공부하면서 시간의 제약을 둘 일은 없었고, 그나마 촉박했던 것은 친구를 위한 개인 프로젝트였는데,
이 역시도 강제성이 있던 것은 아니었기 때문에 스스로 시간 조절을 할 수 있었다.

시간의 제약이라고는 취업하기 전까지 나이를 먹어 가는 것 말고는 없었던 나로서는
어쩌면 당연한 결과일 수도 있겠다며 스스로 위로했다.

그리고 '조금 더 과감하게, 어떻게든 구현해 봐야겠다.' 생각하며 마인드 컨트롤을 하고 잤던 게 기억난다.

대망의 최종 코딩 테스트

아침부터 눈이 펑펑 오는 바람에 예매해둔 시외버스 티켓을 취소하고 지하철로 잠실에 도착했다.

간단히 식사를 마치고 생리현상도 미리 해결한 뒤 건물에 입성했다.

고마웠던 스터디원분들에게 하나씩 드릴 겸 나도 하나 마시려고 1층 약국에서 박카스도 한 박스 샀다.

시험장에 들어가고 나서부터 긴장이 시작되었다.
몇몇 스터디원분들을 만나 가볍게 대화하면서 화이팅도 하고, 자리 양옆 분들과도 괜히 막 인사 주고받고 그랬었다.

그럼에도 좀처럼 긴장이 사그라들지 않았다.

그러던 중 시험 시작 전 안내 사항 메일을 먼저 받았다.

시험 시작 전 안내 메일

전날 밤에 했던 구현 시간에 대한 고민과 함께 어떻게든 구현해 보자며 마인드 컨트롤했던 것이 생각나는 대목이었다.

그렇게 '보여지는 것에 신경 쓰지 않고, 돌아가는 쓰레기를 완성해 보자!' 다짐하며 긴장을 조금 덜어낸 뒤 시험을 시작했다.

실전 경험의 중요성을 느끼다.

제목 그대로다.
복기해 보자면, 정말 마지막 2시간 정도는 무아지경으로 코딩하지 않았나 싶다..

시작은 좋았다.
연습했던 덕분에 기능 구현 목록 작성과 애플리케이션 파악은 대략 15분 정도 만에 해결할 수 있었다.
초반부터 중반까지는 나쁘지 않은 페이스로 적당한? 쓰레기 코드를 써 내려가면서 기능을 구현했다.

이때까지만 해도 적당히 시간을 남겨서 반드시 코드 리팩토링을 해야겠다고 생각하기도 했다. (그저 꿈이었다..)

이 시점에 긴장도 거의 다 풀렸던 것 같다.

하지만 시간이 흐를수록 사소한 에러 하나에도 멘탈이 정말 많이 흔들렸고,

압박 속에서 기능 에러에 유연하게 대처하지 못했다.
특히 애플리케이션의 마지막 2개의 기능이었던 메뉴 추천 기능, 최종 추천 결과 출력 기능은 정말 앞만 보고 달렸다.

그렇게 종료시간 약 50분 정도를 남겨놓고 기능을 전부 구현했지만, 테스트 케이스에서 에러가 발생했다.

하필 문제가 발생한 코드는 앞만 보고 내달렸던 메뉴 추천 기능. 정신없이 디버깅하면서 이유를 찾고자 했다.

남은 시간 모두를 디버깅에 쏟아부었고, 의심 가는 부분을 찾긴 했지만 끝내 에러를 잡지 못한 체 제출했다.

제출 소감문은 정말 점 하나 찍어 냈다.

시험이 종료되고 한동안 자리를 떠나지 못했다.
돌아가는 쓰레기를 만들고자 함이 목표였는데, 돌아가지도 않는 쓰레기를 만들었다는 생각을 했던 것 같다.

왜 찾지 못했을까... 이유가 뭐였을까... 그렇게 한 30분 정도 생각에 잠겼던 것 같다.

고민 끝에 시간을 우선시 한 나머지, 뒤가 없는 코딩을 했기 때문이라고 결론지었고 짐을 쌌다.

뒤를 보니 코치님들이 모두 기다리고 계셨다... 시험 장소 정리를 하려고 하신 것 같다.

토요일이라 빨리 퇴근하고 싶으셨을 텐데 정리해야 한다는 말 한마디 없이 그냥 기다려주고 있던 코치분들께 너무 감사하고 죄송하다.

시험장 건물을 나와서는 조금 멍한 상태로 주변을 정처 없이 걸어 다녔다...
여기저기 걷다가 추워서 지하철역에 들어갔는데, 그때 정신을 딱 차렸다.
인생에서 이제 한 번 경험한 건데 처음부터 잘 할 순 없다고 위로했고, 털어버렸다.

끝나지 않은 에러 디버깅

기분은 나아졌으나 끝내지 못한 숙제가 남아있었다. 아직 에러를 잡지 못했다.
집으로 돌아오는 지하철에서도 원인을 찾지 못해서 집에 도착하자마자 다시 코드를 열었고,

그렇게 며칠을 하나씩 역으로 거슬러 올라가다 보니 원인을 찾을 수 있었다.

에러의 원인은 생각보다 복잡하게 연쇄적으로 얽혀있었다.

원인 1. 테스트 케이스가 내포하고 있는 의미를 파악하지 못함.

테스트 코드의 입력값을 직접 입력하여 테스트할 때에는 버그 없이 잘 동작하는데,
테스트를 돌리면 에러가 발생한 이유는!

테스트 코드가 내포하는 의미의 구현 코드와 내가 구현한 코드가 일치하지 않았기 때문이다.

mock함수는 1~9 값이 들어있는 배열을 사용한다.

위 코드는 제공된 테스트 코드의 일부분이다.

여기서 sequenced 함수는 shuffle 함수를 mocking할 때 사용되는데,
shuffle 함수에게 전달되는 인자 배열의 값을 1~9로 매핑하는 역할을 한다.

내가 구현한 실제 코드 - idx 배열은 0~8 값이 들어있다.

하지만 내가 구현한 코드는
배열의 값을 0~8로 매핑한 뒤 shuffle 함수에게 전달한다.

1~9 배열, 0~8 배열
이 둘의 차이가 바로 에러의 첫 번째 원인이었다.

0-8 값을 가진 배열을 넘기는 내 코드의 경우,
shuffle 함수는 다음의 순서대로 값을 return 하게 된다.

그 과정에서 mockQuestion 함수로 입력된 제임스의 못 먹는 메뉴인 떡볶이가 선택되어버리고,
못 먹는 메뉴 추천 시 새로운 메뉴를 다시 추천하도록 구현되어 있기 때문에,
제임스의 첫 번째 메뉴 선택에 총 2번의 shuffle 함수 return value를 사용하게 된다.

최종적으로는 마지막 메뉴 추천을 받지 못한 상태이므로, 메뉴 추천 로직은 한 번 더 실행되는데
이때 더 이상 mocking된 shuffle 함수 return값이 없으므로 리턴값은 undefined가 된다.

(추가적으로 6번째 mock return value처럼 '9'가 0번 idx 값으로 셔플 된 경우,
menu의 9번 idx는 없으므로 undefined가 메뉴로 추천되는 경우도 발생한다.)

shuffle 함수의 return값이 undefined 이므로 당연한 결과이다.

undefined의 0번 idx 값을 읽으려 하니 당연하게도 에러가 발생한 것이다.

해결 방법

추가된 코드

테스트 케이스의 shuffle mock함수 구현 코드의 형태로
작성한 구현 코드를 수정하여 해결 할 수 있었다.

원인 2. 테스트 케이스가 요구사항과 일치하지 않음.

여전히 남아있는 문제

이후 테스트를 다시 돌려보니, undefined 에러는 해결되었지만 출력 형태가 달라 테스트는 실패하게 되는데
이 부분에서 2번째 원인을 파악할 수 있었다.

바로 테스트 케이스가 요구사항과 일치하지 않는다는 것이다.

구현 요구 사항

요구사항은 [카테고리 추천 => 1번 코치 메뉴 추천 => 2번 코치 메뉴 추천] 의 순서로 구현을 요구한다.

테스트 코드

테스트 코드가 원하는 결과

하지만 테스트 코드는 그렇지 않다.
테스트 케이스는 [카테고리 전부 추천 => 1번 코치 메뉴 전부 추천 => 2번 코치 메뉴 전부 추천] 의 순서로 구현을 요구한다.

실제로는 번갈아가며 메뉴가 정해진다.

요구사항대로 구현했을 경우의 순서

요구 사항대로 코드를 구현할 경우 mockShuffles 함수는 위에서부터 순차적으로 각 코치의 메뉴를 추천하므로

테스트를 통과할 수 없다.

해결 방법

테스트 코드 수정 시 통과 가능하다

테스트 케이스의 mockShuffles 함수 내 코드를 순서에 맞게 수정하거나,

각 코치의 일주일 치 메뉴를 일괄 추천 하도록 구현 코드를 변경해야 한다.

시험이 아닌 또 다른 교육

- 최종 테스트 안내 메일 -

코드의 에러를 수정하는 과정에서 여러 가지 생각을 하게 됐다.

실제로 최종 테스트 진행 중에 메뉴 추천 로직을 구현하면서,

주어진 테스트 코드와 같이 '일괄 추천으로 구현하는 것이 코드 맥락을 이해하기 쉽지 않을까?' 같은 생각을 했었다.
실제로 그게 더 구현하기도 쉬웠고, 코드도 깔끔하게 정리할 수 있었다.

무엇보다도 일괄 추천으로 구현해도 최종 구현 후 기능의 동작은 똑같았기 때문이다.

(테스트 코드를 명확하게 파악하고 한 생각은 아니었다.)

하지만 이내 '요구사항은 요구사항이니 지켜야 한다' 생각하여 구현을 이어갔었다.

하지만 과연 어떤 것이 옳은 선택일까?

만약 코딩 테스트가 아니었다면, 업무 중 이런 상황이 발생했다면 나는 어떤 선택을 해야 할까?

✨ 우테코 지원과정을 마치면서...

우테코와 함께한 약 3개월간의 과정이 드디어 끝이 났다.

첫 지원, 자소서 작성부터 시작해서 운 좋게 얻게 된 최종 코딩 테스트까지...

지원할 때만 해도 '벌써 10월이네.. 시간 빠르다...' 생각했는데 어느덧 크리스마스가 눈앞이다.

머리를 싸매고 좌절한 적도 있었고, 약점이라고 생각한 부분을 극복하며 울컥한 적도 있었고,

끝까지 해내는 나 자신을 보며 자신감을 얻기도 했었다.

이러나저러나 드는 생각은 지원하길 정말 잘했다는 생각이다.

누구라도 지원을 망설이는 사람이 있다면 고민은 넣어두고 얼른 자소서 작성하길 바란다.

너무 나도 많은 걸 배웠고, 앞으로 어떻게 나아가야 하는지 방향을 잡을 수 있어 행복했다.

정말 대단히 감사하다.

우테코 프론트엔드 5기 - 프리코스 4주 차 후기

Creative_Lee — Tue, 22 Nov 2022 16:35:04 +0900

프리코스의 막이 내렸다. 말로 표현할 수 없는 감정이 오간다.
지금 이 감정에 대한 이야기는 글 마지막에 하도록 하겠다.
이번 후기에는 미션으로 성장했던 부분을 설명하고,
마무리로는 앞으로 프로그래밍을 공부하며 내가 가져야 할 태도와 자세에 대해 적어 보겠다.

3주 차 공통 피드백 수용

4주 차 미션 시작에 앞서 3주 차 공통 피드백을 점검했다.

객체의 상태 접근을 제한한다
객체는 객체스럽게 사용한다. / 데이터를 꺼내지 말고 메시지를 던지도록 구현한다.
필드의 수를 줄이기 위해 노력한다.

피드백의 worst 코드가 내 코드와 정확히 일치해서.. 뜨끔했다..

객체를 분리했다면 getter메서드로 데이터를 꺼낼 것이 아니라, 분리한 이유에 맞는 기능이 구현되어 있어야 한다는 뜻으로 이해했다.

(위 내용은 이번 미션에서 중요한 역할을 했다... 뒤에 이어진다.)

private 필드의 필요성도 피드백을 통해 알게 되어 따로 공부했다.

성공하는 케이스뿐만 아니라 예외에 대한 케이스도 테스트한다.
테스트 코드도 코드다. 리팩터링을 통해 개선해나가야 한다.
테스트를 위한 코드는 구현 코드에서 분리되어야 한다

테스트 코드 역시 코드라는 말에 한 방 맞은 것 같았다...

이전 미션까지의 테스트 코드를 돌아보며 메인 코드를 신경 써서 작성하는 것처럼
테스트 코드 역시 가독성과 의미 전달에 신경 써야겠다고 생각했다.

미션 레포지토리 링크

이번 후기는 게임을 구현하는 과정에서의 코드 변화를 중심으로 이어지기 때문에,

지원자분들 외의 분들의 내용 이해를 위해 다리 건너기 미션 repository를 첨부한다.

오징어 게임의 다리 건너기를 생각하면 되겠다.

‍♂️ ‍♂️ 4주 차 미션 - 다리 건너기 게임

4주 차 미션은 다리 건너기 게임을 구현하는 과제였다.
이번 미션에서는 공통 피드백에 해당하는 문제를 직접 맞닥뜨리고
피드백을 적용해 개선하는 과정에서 엄청난 성장을 할 수 있었다.

객체는 객체스럽게 사용한다. / 데이터를 꺼내지 말고 메시지를 던지도록 구현한다.
테스트를 통과하기 위해 구현 코드를 변경하거나 테스트에서만 사용되는 로직을 만들지 않는다.
단위 테스트 하기 어려운 코드를 단위 테스트 가능하도록 리팩터링한다. ( + 구체적 예시 )

데이터를 꺼내지 말고 메시지를 던져라!

공통 피드백 중 getter 메서드를 사용하지 않고, 객체에 메시지를 던져 객체가 일하도록 하라는 내용이 있었다.

관련 예시와 자료들을 찾아보며 공부했고, 어느 정도 이해했다고 생각하여 구현을 시작했다.

하지만 어느 순간 피드백 내용의 worst 케이스에 해당하는 코드를 또다시 작성하고 있음을 깨달았다.

이후 해당 코드를 개선하는 과정을 겪으면서, 피드백이 무엇을 말하고자 하는 것인지 온전히 이해할 수 있었다.

⌛ 코드 작성 당시 상황 설명 1

다리에 해당하는 Bridge 클래스를 만들어 다리 생성 기능을 구현한 뒤에 상황이다.

다리를 만들었으니 다리를 건너는 기능을 구현해야 했다.

이를 위해 다리의 방향과 사용자가 입력한 방향을 비교하는 로직이 필요했다.

개선 전 코드의 문제점

Bridge 클래스에 저장된 다리 방향

다리의 방향을 꺼내기 위해 getter 메서드를 작성했었다.

BridgeGame 클래스의 move 메서드

그리고 BridgeGame 클래스의 move 메서드 내부에서

getter를 사용해 다리의 방향을 그대로 가져온다...

이후 현재 위치에 해당하는 다리의 방향이 사용자 방향 입력과 일치하는지 비교한다.

위 코드의 문제점은 Bridge 클래스가 아무 기능도 하지 않는다는 것이다.

단지 다리 방향을 저장할 뿐 클래스로 나눈 의미가 없었다.

또한 private 처리한 다리 방향 상태를 그대로 꺼내어 사용하여 private의 의미도 사라졌다.

이를 개선하기 위해 다리의 방향과 사용자 방향 입력을 비교하는 로직을 Bridge 클래스 내부로 넣어보았다.

개선 후 코드

Bridge 클래스에 방향값을 전달받아 비교를 수행하는 메서드 생성

Bridge 클래스에 사용자 방향과 현재 위치 값을 전달받아 방향 값의 비교를 수행하는 메서드를 생성했다!

다리 방향 상태 값을 가진 Bridge 클래스에게 메시지를 던져 자신의 상태 값에 관련된 일을 하도록 개선된것이다.

상태 값을 꺼내지 않고도 비교가 가능해졌고, getter 메서드는 더 이상 필요가 없어 삭제했다.

⌛ 코드 작성 당시 상황 설명 2

다리를 건넌 후, 게임 상태에 따라 여러 가지 흐름으로 게임을 진행시켜야 했다.

그중 게임을 클리어했다면 게임을 종료 시켜야 했고,

이를 위해 게임의 클리어 여부를 판단하는 로직이 필요했다.

개선 전 코드의 문제점

다리의 길이를 꺼내기 위해 getter 메서드를 작성했었다.

명확한 상황 설명을 위해 뒷 로직은 포함하지 않았습니다.

그리고 BridgeGame 클래스의 isEnd 메서드 내부에서

getter를 사용해 다리의 길이를 그대로 가져온다.

이후 지나온 블록 수와 다리 길이를 비교해 모든 블록을 지나왔는지 결과를 낸다.

위 코드 역시 동일한 문제점이 있다.

지나온 블록 수와 다리 길이를 비교하는 로직을 Bridge 클래스 내부로 넣어보았다.

개선 후 코드

Bridge 클래스에 지나온 블록 수를 받아 다리길이와 비교하는 메서드 생성

Bridge 클래스에 지나온 블록 수를 받아 다리길이와 비교하는 메서드를 생성했다!

Bridge 클래스가 자신의 상태 값에 대한 로직을 수행하도록 개선되었다.

이 역시 상태 값을 가져오는 getter는 필요하지 않아 삭제했다.

테스트 코드 통과만을 위해 구현 코드를 변경하지 않기!

이 피드백 또한 테스트 코드 작성에 난항을 겪으며 이것저것 시도하고 나서야 비로소 이해할 수 있게 되었다.
테스트 편의를 위한 클래스를 생성하여 사용하다가 결국 근본 원인을 찾게 되어 삭제했던 과정을 소개한다.

테스트 편의를 위한 Builder 클래스

우선 결론부터 말하자면 클래스 생성 - 삭제 - 생성 - 삭제,
총 4번 생각의 변화가 있었다...

Builder 클래스를 생성한 이유

처음 다리를 생성하는 부분의 코드는 다음과 같았다.

BridgeGame 클래스의 build메서드로 다리 생성

BridgeGame 클래스의 build 매서드 내에서

미션에서 주어진 다리 생성 함수 makeBridge 를 통해 Bridge 클래스를 초기화하여 필드 변수에 저장하는 구조였다.

구현 이후 테스트 코드를 작성하려는데, 이게 웬걸... build 메서드는 테스트 자체가 불가능했다!

size 값을 전달하여 메서드를 실행시키면 접근할 수 없는 필드 변수에 생성된 다리를 저장하기 때문에
테스트 할 방법이 없었다.

나는 테스트 문제를 해결함과 동시에 다리를 짓는 건축자라는 표현이 있으면

코드도 부드럽게 읽히지 않을까 하는 생각으로 Builder 클래스를 만들었다.

Builder 클래스로 상황이 개선되었다는 착각

Builder 클래스

위와 같이 Builder 클래스를 만들고,
메서드로 생성 로직을 한 번 더 묶어서 Bridge 인스턴스를 return 하게 했다.

BridgeGame 클래스의 build 메서드 변경 사항

BridgeGame 클래스의 build 메서드는
내부에서 Builder 클래스를 초기화하고 buildBridge 메서드를 실행하도록 변경했다.

(이때 여전히 build 메서드는 테스트 불가능하다는 사실을 알지 못했다... )

테스트 작성 가능..?

위 코드처럼 원래 할 수 없던 BridgeGame클래스의 build 메서드 테스트를

Builder 클래스로 대신하게 되면서, 해결이 됐다고 생각했다.

하지만 곧 근본적인 문제를 맞닥뜨렸다.

Builder 클래스를 삭제하게 된 이유

BridgeGame클래스 내 move 메서드

문제는 위 코드처럼 사용자의 방향 입력을 받아 움직이는 기능을 만들고 나서 발생했다.

기능 구현 이후 테스트 코드를 작성하는데.. 이게 웬걸!! move 메서드 또한 테스트 자체가 불가능했다!

BridgeGame 클래스 내의 모든 기능 메서드를 테스트할 수 없는 근본적인 원인은 따로 있던 것이다...

테스트 불가능

원인은 위 테스트 코드를 보면 알 수 있다.

다리 건너기 게임은 BridgeGame 클래스의 build 메서드로 다리를 만들면서 시작하는데...

다리를 만드는 과정에 제공된 Random 유틸 함수가 사용된다.

BridgeGame 클래스 내부에서 Random 함수를 통해 다리를 생성하는 구조 자체만으로

다리와 연관된 모든 메서드를 테스트할 수 없게 되는 것이다.

원인을 알게 된 후 테스트 코드 작성이 주 목적이 되어 버린 Builder 클래스를 삭제했고, 코드를 리팩터링 했다.

단위 테스트하기 어려운 코드를 가능하도록 리팩터링 하기!

근본적인 원인 해결

결국 근본적인 원인은 Random 함수였고,

다리 성성을 BridgeGame 클래스 외부에서 해야한다는 결론이 나왔다.

GameController 클래스에서 다리생성

전달 받은 다리를 필드에 할당

사용자 입력을 전달받아 명령을 내려주는 GameController 클래스에서 다리를 생성하고,
BridgeGame 클래스의 인스턴스를 만들 때 생성된 다리를 전달하여 초기화하도록 개선하였다.

테스트 가능해진 메서드

move 메서드 테스트 가능

retry 메서드 테스트 가능

개선 이후 Random 함수와 BridgeGame 클래스가 분리되었고,
원하는 값으로 다리 생성이 가능해졌다. 이로 인해 메서드의 테스트도 가능하게 됐다.

해냈다....이도현...

프리코스를 마무리 하며...

마침내 결승선을 통과했다.

4주간의 마라톤을 끝내고 나니 성취감에 뿌듯하면서도, 끝이 났다는 게 아쉽기도 하다.

짦은 시간 동안에도 충분히 많은 성장을 할 수 있다는 것을 느낄 수 있는 시간이었다.

하지만 나는 더 성장해야 한다. 아니 평생 성장해야 한다.
이번 프리코스 과정에서 온전히 학습에만 집중한 것처럼 같은 자세로 열심히 배워간다면,

나는 분명 훌륭한 개발자가 되어있을 것이다.

고생했다 도현아!

Git - merge, rebase 개념과 차이

Creative_Lee — Fri, 18 Nov 2022 18:03:55 +0900

여러분은 branch를 병합하는 방법을 알고 계시나요?

우리는 협업 환경에서 Git을 사용합니다.

각 팀원은 자신이 맡은 기능을 개발하기 위해 branch를 만들어 작업합니다.

팀원들의 개발이 끝났다면, 모두의 작업물(branch)을 한 곳에 모아 하나의 작품을 완성해야 합니다.

이번 포스팅에서는 branch를 병합하는 대표적인 방법인 merge와 rebase에 대해 알아보겠습니다.

포스팅에 쓰이는 모든 시각화 자료는 https://learngitbranching.js.org 에서 발췌하였습니다.
Git의 여러가지 기능을 배우기 정말 좋은 사이트이니 사용해보시는 걸 추천합니다.

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

1. merge란?

merge 키워드를 사용하면 두 개의 부모가 있는 새로운 커밋을 만들어 branch를 병합합니다.

두 branch의 커밋 내역은 순서대로 정리되고 merge commit이 하나 남습니다.

그림으로 이해해봅시다.

merge 전

main branch에서 C0, C1을 commit 하였습니다.

이후 bugFix 브랜치가 생성되었고 버그는 C2 commit으로 해결되었습니다.
그동안 main branch에서는 C3 commit을 하였습니다.

merge 후

그럼 이제 merge 해봅시다! (main branch C3에서 진행합니다.)

git merge bugFix
git push

C2, C3를 부모로 하는 새로운 commit인 C4가 생성되면서 병합이 완료되었습니다.

이제 github에서 main branch의 commit log를 확인해 볼까요?

두 branch의 커밋 이력은 순서대로 정리되었고 마지막에 merge commit이 하나 남았습니다.

main branch에선 버그가 해결되었겠네요!

이후 bugFix branch를 유지하고 싶다면 git merge main하여 main branch와 동일하게 C4를 가리키게 하면 됩니다.

필요없다면 삭제하면 됩니다.

merge --squash

--squash 옵션을 추가하면 합쳐질 branch의 커밋 이력을 하나의 커밋으로 정리할 수 있습니다.

git merge bugFix --squash
git commit -m "merge with --squash"
git push

bugFix branch의 커밋 이력은 마지막에 원하는 커밋 하나를 남기는 것으로 대체되었습니다!

똑같이 main branch에선 버그가 해결되었습니다.

2. rebase란?

rebase 키워드를 사용한 브랜치의 커밋을 다른 브랜치에 떨궈놓는 것으로 branch를 병합합니다.

해당 브랜치의 커밋은 병합 대상 브랜치의 커밋 뒤로 정리됩니다. 마치 처음부터 병합 대상 브랜치에서 개발한 것처럼 보이게 됩니다.

rebase를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있습니다.

그림으로 이해해봅시다.

rebase 전

main branch에서 C0, C1을 commit 하였습니다.

이후 bugFix 브랜치가 생성되었고 버그는 C3 commit으로 해결되었습니다.
그동안 main branch에서는 C2 commit을 하였습니다.

rebase 후

그럼 이제 rebase 해봅시다! (bugFix branch C3에서 진행합니다.)

git rebase main

bugFix branch의 C3 커밋이 Main branch의 C2 커밋 뒤로 떨궈졌네요! 병합이 완료되었습니다.

하지만 main branch는 아직 제자리에 있습니다.

main branch도 병합 완료된 커밋을 가리키게 해보겠습니다.

main branch로 이동하여 똑같이 rebase 해줍니다.

git switch main
git rebase bugFix

이제 정말 병합이 완료되었습니다.

이제 github에서 main branch의 commit log를 확인해 볼까요?

C3 커밋이 Main branch의 C2 커밋 뒤로 떨궈졌기 때문에
커밋 시간과는 무관하게 bugFix commit 더 상단에 위치하네요!

병합이 끝났습니다. main branch에선 버그가 해결되었습니다.

변경된 커밋 해시

그런데 자세히 보면 C3는 C3` 으로 병합되었습니다.

rebase는 특정 브랜치를 base로 커밋 이력을 재정렬하겠다는 명령어 입니다.

bugFix 브랜치에서 main브랜치를 기준으로 rebase 시켰기 때문에,

main 브랜치를 기준으로 커밋이 재정렬 됩니다.

이 과정에서 커밋이력에는 이전과는 다른 새로운 해시가 생성됩니다.

만약 main 브랜치에서 먼저 rebase를 실행하면 어떻게 될까요 ?

git rebase bugFix

main 브랜치는 모든 브랜치의 기준 브랜치 입니다.

만약 main 브랜치에서 다른 브랜치를 기준으로 rebase을 실행하면,
main 브랜치의 커밋 해시가 변하게 됩니다.

이렇게 되면 main 브랜치에서 분기된 여러 브랜치에서 작업하던 팀원들은 변경된 해시로 인해 고통을 받게 됩니다!
때문에 main 브랜치에서 다른 브랜치를 기준으로 rebase을 하는 경우는 피하는게 좋겠습니다.

기본이 중요하다.

우테코 프론트엔드 5기 - 프리코스 3주 차 후기

Creative_Lee — Tue, 15 Nov 2022 17:14:58 +0900

프리코스 3주 차를 마무리했다.
3주 차는 매일매일 눈 떠보면 시간이 사라지는 마법 같은 하루를 보냈다.
뒤이어 설명할 추가된 요구사항이 큰 몫을 해줬다.
이번 후기도 성장했던 부분과 차주 목표를 중점으로 적어 나가 보겠다.

2주 차 공통 피드백 수용

3주 차 미션 시작에 앞서 2주 차 공통 피드백을 점검했다.

README.md를 상세히 작성한다.
기능 목록을 재검토한다.
기능 목록을 업데이트한다.

이전 미션을 진행하면서, 기능 구현 목록 작성에 너무 많은 시간을 할애했던 기억이 있다.

상세히 작성하는 것은 중요하지만 그렇다고 함수, 메서드의 설계와 구현처럼 언제든지 변경될 수 있고

구현하는 시점이 되어봐야 알 수 있는 것들을 미리 생각하고 적지 않도록 주의하라는 내용이었다.

이 피드백을 보고 첫 작성에 모든 것을 담으려는 생각을 버렸다!

값을 하드 코딩하지 않는다.

이번 3주 차 미션에는 하마터면 하드 코딩할 만한 값들이 정말 많았다.

피드백으로 한 번 더 점검하는 시간을 가졌다.

한 함수가 한 가지 기능만 담당하게 한다.
함수가 한 가지 기능을 하는지 확인하는 기준을 세운다.

한 가지 기능에 대한 확인 기준을 세워야 한다는 말이 상당히 큰 도움이 되었다.

코드를 작성하면서 '큰 범위로는 한 가지 기능인 것 같은데... 이걸 더 나눠야 하나..?' 와 같은 생각을 정말 많이 했었다.

이게 모두 기준이 없기 때문이 아니었을까 생각했다.

피어 리뷰의 매력

프리코스 커뮤니티를 통해 많은 사람의 코드를 보고 리뷰하면서, 코드 작성 꿀팁들을 정말 많이 얻었다.

또한 코드를 읽으면서 내 코드에 대한 개선 방향을 정할 수 있는 것도 참 좋은 것 같다.

나 역시 이전 미션에 대한 피어 리뷰를 부탁했는데, 많은 분들이 코드에 대한 조언을 해주셨다.

그중 Airbnb JS 컨벤션에 대한 피드백이 가장 많았다.
1주 차 시작과 함께 정독했었는데... 그럼에도 지키지 못한 부분이 많았다. 반성해야 할 부분이다.

리뷰를 토대로 3주 차 미션에서 많은 부분을 보완할 수 있었다.

다들 따듯한 말도 잊지 않으셨다.

오랜 시간 혼자 공부하면서 이런 말들을 해줄 사람이 거의 없었다. (훌쩍..)

다들 진심으로 너무 감사하다!

3주 차 미션 - 로또 게임

3주 차 미션은 로또 게임을 구현하는 과제였고, 이번에도 역시 요구사항이 추가되었다.

추가된 요구 사항 중, 내가 가장 많이 성장할 수 있었던 요구 사항은 다음과 같다.

클래스(객체)를 분리하는 연습을 할 것.
- 메서드의 길이가 15라인을 넘어가지 않도록 구현한다.
- 메서드가 한 가지 일만 하도록 구현한다.

클래스(객체) 분리의 중요성

나는 [분리]와의 악연이 있다. 1주 차 후기 글에도 등장했던 내 개인 프로젝트 이야기를 조금 해보겠다.

프로젝트 당시 몇 안 되는 파일에 모든 로직을 전부 모아 개발했고, 진행이 될수록 분리가 더욱 어려워졌었다.
어떻게든 완성하여 원하던 사람에게 이롭게 쓰였지만,

원하던 방향으로의 확장도, 리팩토링도 할 수 없는 기괴한 구조가 되어버려 프로젝트를 중단할 수밖에 없었다.

이전까지의 나는 이런저런 사건과 이유로 분리가 중요하다는 것은 뼈져리게 느꼈지만

그렇다고 분리에 대한 기준이 생기거나 분리를 잘하게 된 건 또 아닌, 정체되어 있는 상태였다.

3주 차 미션을 하기 전까지는 말이다.

이번 미션의 요구사항은 나의 정체기를 시원하게 뚫어주었다. ‍♂️

클래스를 분리하는 이유! (feat. 도메인,비즈니스 로직이란 ?)

제일 먼저 구글에 검색을 해보았다.

대부분의 글에서 SOLID 원칙, 객체 지향 설계 등의 키워드를 볼 수 있었다.

전체적으로 종합해 보면,

클래스가 하나의 기능(책임)을 가져야만 관심사가 분리되고, 유지 보수에 용이하다는 결론이 나온다.

‍♂️ 그래서 어떻게 하는 건데..? (학습 과정)

여러 자료를 보면서 느낌은 파악할 수 있었지만, 그래서 어떻게 하는 건지는 알 수 없었다.

상당히 부끄럽지만, 내가 3주 차 미션을 하면서 구현한 로또 앱의 구조를 공개한다.

내 생각의 과정을 적어두고, 앞으로도 이런 사고방식으로 학습하고 싶어서 글로 남긴다.

1차 로또 앱 구조

'UI를 담당하는 로직을 구분한다.'라는 요구사항을 의식하면서 코드를 작성하다 보니,

자연스럽게 콘솔에 무언가를 보여주는 기능을 모아둔 LottoGameView 클래스를 만들었다.

여러 입력에 대한 유효성 검사 로직은 중복되는 부분이 있었고, 재사용을 하고 싶었다.

이렇게 유효성 검사 로직을 모아둔 유틸 느낌의 Validation 클래스를 만들었다.

LottoGame 클래스는 입력을 받아

로또를 발행하고 로또를 비교하여 당첨 통계를 냈다.

첫 구현은 위와 같았고, 흐름에 문제가 없다고 생각했다.

하지만 코드를 보고 있자니, 왜 인지 모르게 중단하였던 내 프로젝트가 떠올랐다.
뭉쳐져 있고, 뭉쳐져 있고... 뭉쳐져있는...

읽기 어려운 코드와 엄청난 분량

당시 LottoGame 클래스의 메서드 부분만 캡처해 보았다.

포스팅하는 지금도 한 화면에 꽉 찰 정도로 길다... 180줄 가량의 코드가 한데 뭉쳐있었다.
로또 구매, 번호 비교, 당첨 통계에 대한 모든 메서드를 전부 가지고 있는 상태였고, 개선이 필요했다.

분리 기준 세우기

도메인 로직에 대한 이해를 통해 클래스의 분리 기준을 세웠다.

해당 블로그의 자료가 상당히 큰 도움이 되었다. eddy_song 님의 포스팅

위 내용을 바탕으로 새로운 구조를 그려보았다.

각 기능에 대한 의사결정 코드를 구분하는 것을 목표로 했다.

우선 기능별로 구분하고 보니 다음과 같이 나눌 수 있었다.

로또 구매
당첨 번호 입력
로또 번호 비교
결과 통계

그중 당첨번호 입력에 대한 기능은 단순히 번호를 저장하는 보관소 역할이라 도메인 로직 범위에서 제외하기로 했다.

나머지 3개의 기능에 대한 도메인 로직들을 각 클래스로 분리해 보았다.

로또 구매 : LottoPurchaseMachine
등수 계산 : PrizeCalculator
결과 통계 : Statistic

LottoGame 클래스의 변화

클래스를 나누고 나니, LottoGame 클래스에는 변화가 생겼다.

1. LottoGame 클래스의 의미 파악이 쉬워졌고, 파일의 길이가 줄었다.

개선 전 : 각 페이즈에서 필요한 여러 메서드가 모여있어 클래스의 의미를 파악하기 힘들다

개선 후 : 메서드 명만 보고도 '게임의 각 페이즈를 실행하는 곳'이라는 의미를 파악할 수 있다.

2. 각 페이즈의 기능 파악이 쉬워졌다.

개선 전 : drawLottoPhase에서 너무 많은 기능을 담당하여 정확히 무엇을 하는지 알기 어렵다.

개선 후 : prizeCalculatePhase라는 메서드명과 내용으로 '로또 등수를 계산한다' 라는 의미를 알 수 있다.
statisticsPhase도 마찬가지로 '통계를 한다' 라는 의미를 알수있다.

각 메서드 본문의 가독성이 확연히 좋아졌다.

디렉터리 생성 및 파일 분리

마지막으로 각자의 역할 별로 디렉터리를 만들어 파일을 분리해 보았다.

물론 위의 구조도 좋은 구조라고 말할 수 없다.

하지만 이전보다 좋은 구조라고 당당히 말할 수 있다.

후기를 읽는 분들이 혹시 지루할까, 웃고 가시라고 짤을 넣었지만...

화요일 새벽. 리팩토링을 마치고 잠자리에 들면서 조금 벅찬 감정을 느꼈다.

평소 약점으로 생각했던 부분을 정면 돌파하면서 저런 구조를 완성해낸 것만으로 여러 감정이 밀려왔다.

무슨 감정인지는 모르겠다만... '열심히 잘 하고 있는 거겠지...' 같은 생각을 했던 것 같다.

앞으로 보완할 점!

1. 앱의 구조를 조금 더 명확히 파악하고 코드 작성하기.

이번 3주 차 리팩토링은 다행히 성공으로 끝났지만,
만약 조금만 더 복잡한 구조였다면 내 프로젝트처럼 절반의 성공으로 끝났을 수도 있다.
물론 처음부터 완벽한 구조를 만들 순 없겠지만, 깊은 고민을 통해 조금이라도 더 괜찮은 구조를 얻도록 노력할 것이다.

2. 클래스에 익숙해지기.

프리코스의 시작과 함께 사용하게 된 클래스는 여전히 어색하다.
생성자에서 다른 클래스를 초기화해도 되는지,
메서드 내에서 초기화하는 것과는 무슨 차이가 있는지, 이것저것 궁금하고 모르는 것 투성이다.
더 많이 사용해 보고 관련 코드도 참고하면서 하나씩 풀어가야 한다.

3주 차를 마무리 하며

저번 후기에서 3주 차에는 속력을 높여 달려보겠다고 다짐했었는데,

바람대로 정말 미친 듯이 달린 것 같다.

이제 결승선을 통과하면 된다. 이대로 완주하자!

가자아!!!!!!!!!!

Jest - Matcher란?

Creative_Lee — Sat, 12 Nov 2022 15:07:37 +0900

여러분들은 Jest로 테스트 코드를 작성할 때 다양한 Matcher를 사용하고 계시나요?

오늘은 Jest에서 테스트 코드를 작성할 때 자주 사용하는 Matcher에 대해서 알아보겠습니다.

1. toBe( value )

기본형을 비교할 때 자주 사용합니다. 값이 같은지 비교합니다.

대상이 원시형(primitive type)이라면 값을 비교하고,

참조형(reference type)이라면 같은 대상을 참조하는지 비교합니다. (얕은 비교)

describe("toBe 테스트", () => {
  test("원시형 비교", () => {
    const result = "123";

    expect(result).toBe("123"); // test passed!
  });

  test("참조형 비교", () => {
    const result = [1, 2, 3];

    expect(result).toBe([1, 2, 3]); // test failed!
  });
});

때문에 위 테스트 코드에서 참조형인 배열 [1,2,3]의 toBe( ) 테스트는 실패하게 됩니다.

2. toEqual( value )

참조형을 비교할 때 자주 사용됩니다. 참조형의 모든 필드(프로퍼티, 요소)를 재귀적으로 돌며 비교해 줍니다. (깊은 비교)
원시형도 비교 가능합니다.

describe("toEqual 테스트", () => {
  test("원시형 비교", () => {
    const result = "123";

    expect(result).toEqual("123"); // test passed!
  });

  test("참조형 비교", () => {
    const result = [1, 2, 3];

    expect(result).toEqual([1, 2, 3]); // test passed!
  });
});

toBe( ) 테스트와 다르게 참조형인 배열의 toEqual() 테스트가 통과했습니다.

주의할 점

객체의 프로퍼티나, 배열의 요소에 undefined가 추가되어 있어도 테스트는 통과됩니다.

describe("toEqual undefined 테스트", () => {
  test("참조형 비교 - 객체", () => {
    const result = { a: 1, b: 2 };

    expect(result).toEqual({ a: 1, b: 2, c: undefined }); // test passed!!!!????
  });

  test("참조형 비교 - 배열", () => {
    const result = [1, 2, 3];

    expect(result).toEqual([1, 2, 3, undefined]); // test passed!!!!!???
  });
});

위 테스트 결과처럼 toEqual( ) 사용시 이 점에 유의하여 테스트 코드를 작성해야 합니다.

3. toStrictEqual( value )

위와 같은 toEqual( )의 문제를 toStrictEqual( )로 해결할 수 있습니다.

toStrictEqual( )은 undefined까지 비교합니다.

describe("toStrictEqual undefined 테스트", () => {
  test("참조형 비교 - 객체", () => {
    const result = { a: 1, b: 2 };

    expect(result).toStrictEqual({ a: 1, b: 2, c: undefined }); // test failed ^^
  });

  test("참조형 비교 - 배열", () => {
    const result = [1, 2, 3];

    expect(result).toStrictEqual([1, 2, 3, undefined]); //  test failed ^^
  });
});

위 테스트는 실패합니다.

jest 공식 문서에서도 이러한 특징때문에 toStrictEqual( ) 이 선호된다고 알려주네요!

꼼꼼한 toStrictEqual( )

toStrcitEqual( )은 객체의 인스턴스 타입까지 비교합니다.

describe.only("toEqual vs toStrictEqual 인스턴스 테스트", () => {
  class Test {
    constructor(test) {
      this.test = test;
    }
  }

  test("toEqual 인스턴스 테스트", () => {
    const instance = new Test(1);
    const normal = { test: 1 };

    expect(normal).toEqual(instance); // test passed !!
  });

  test("toStrictEqual 인스턴스 테스트", () => {
    const instance = new Test(1);
    const normal = { test: 1 };

    expect(normal).toStrictEqual(instance); // test failed !!
  });
});

같은 조건에 toEqual( ) 은 통과한 반면, toStrictEqual( )은 실패했습니다.

이 외에도 toStrictEqual( )은 [ ,1] 과 [undefined, 1] 을 다르다고 비교해 주는 등 보다 엄격하게 비교합니다.

toStrictEqual( )의 특징을 잘 활용하여 테스트 코드를 작성해 봅시다.

4. toBeTruthy( ), toBeFalsy( )

JS는 boolean 값을 true, false 만으로 한정하지 않습니다.
0, 빈 문자열 등을 false로 취급하는 것과 같이 말이죠.

이런값들을 비교할 때 toBeTrythy( ), toBeFalsy( )를 사용합니다.

describe("toBeTruthy / toBeFalsy 테스트", () => {
  test("toBeTruthy 테스트", () => {
    const result = "0";

    expect(result).toBeTruthy(); // test passed !!
  });

  test("toBeFalsy 테스트", () => {
    const result = 0;

    expect(result).toBeFalsy(); // test passed !!
  });
});

이 밖에도 Truthiness를 비교할 수 있는 matcher는 다양하니 알아두면 좋겠습니다.

toBeNull: 대상이 null 인지 검증합니다.
toBeUndefined: 대상이 undefined 인지 검증합니다.
toBeDefined: 대상이 정의되었는지 검증합니다.

5. toContain( element )

배열이 특정 요소를 가지고 있는지 검증합니다.

배열, 문자열, Set, 노드 리스트, HTML 콜렉션과 같은 iterable에 사용할 수 있습니다.

describe("toContain 테스트", () => {
  test("배열 테스트", () => {
    const result = [1, 2, 3];

    expect(result).toContain(1); // test passed !!
  });

  test("문자열 테스트", () => {
    const result = "문자열 테스트";

    expect(result).toContain("문자열"); // test passed !!
  });

  test("Set 테스트", () => {
    const result = new Set([1, 2, 3]);

    expect(result).toContain(1); // test passed !!
  });
});

6. toHaveLength( number )

대상이 length 프로퍼티를 가지고 있는지, 또한 length의 길이가 일치하는지 검증합니다.

배열이나 문자열의 길이를 체크할 때 유용합니다.

describe("toHaveLength 테스트", () => {
  test("배열 테스트", () => {
    const result = [1, 2, 3];

    expect(result).toHaveLength(3); // test passed !!
  });

  test("문자열 테스트", () => {
    const result = "문자열 테스트";

    expect(result).toHaveLength(7); // test passed !!
  });
});

7. toThrow( error? )

대상 함수를 호출했을 때 에러가 발생하는지 여부를 검증합니다.

describe("toThrow 테스트", () => {
  const testFunc = () => {
    throw new Error("에러 테스트 함수입니다.");
  };
  const errorObj = new Error("에러 테스트 함수입니다.");

  test("인자 X", () => {
    expect(testFunc).toThrow(); // test passed !!
  });

  test("문자열 인자", () => {
    expect(testFunc).toThrow("에러 테스트"); // test passed !!
  });

  test("Error 객체 인자", () => {
    expect(testFunc).toThrow(errorObj); // test passed !!
  });

  test("클래스 인자", () => {
    expect(testFunc).toThrow(Error); // test passed !!
  });
});

인자에 따른 기능차이

인자가 없을 때: 에러 발생을 검증합니다.
문자열 인자: 에러 발생 + 에러 메시지가 인자로 전달한 문자열을 포함하는지 검증합니다.
Error 객체 인자: 에러 발생 + 에러 메시지가 인자로 전달한 Error 객체의 메세지와 일치하는지 검증합니다.
class 인자: 에러 발생 + 에러 객체가 인자로 전달한 class의 instance 인지 검증합니다.

8. toBeInstanceOf( Class )

대상 객체가 인자 클래스의 instance 인지 검증합니다.

describe("toBeInstanceOf 테스트", () => {
  class Test {}
  const output = new Test();
  const fake = {};

  test("인스턴스 O", () => {
    expect(output).toBeInstanceOf(Test); // test passed !!
  });
  test("인스턴스 X", () => {
    expect(fake).toBeInstanceOf(Test); // test failed !!
  });
});

여기까지 다양한 matcher를 알아보았습니다.
소개한 matcher 외의 더 많은 matcher에 대한 정보들은 공식 문서에서 찾으실 수 있습니다.

Jest Matcher 공식 문서

Expect · Jest

When you're writing tests, you often need to check that values meet certain conditions. expect gives you access to a number of "matchers" that let you validate different things.

jestjs.io

다음 포스트에서는 mock의 개념과 mock 메서드, mock 함수에 사용하는 Matcher에 대해 알아보겠습니다!

기본이 중요하다.

우테코 프론트엔드 5기 - 프리코스 2주 차 후기

Creative_Lee — Tue, 8 Nov 2022 10:27:22 +0900

프리코스 2주 차를 마무리했다.
2주 차 미션은 우여곡절이 훨씬 많았다.
그걸 다 부셔내고 후기를 적고 있다니... 확실히 성장했다!
이번 후기도 성장했던 부분과 차주 목표를 중점으로 적어 나가 보겠다.

1주 차 공통 피드백 점검

2주 차 미션 시작에 앞서 1주 차 공통 피드백을 점검했다.

커밋 메시지를 의미 있게 작성한다.

1주 차 미션을 진행하며 커밋 컨벤션을 적용했지만, 익숙하지 않은 탓에 실수를 많이 했었다.
의미 있는 커밋 메시지에 대해 리마인드 했다.

이름을 통해 의도를 드러낸다.
축약하지 않는다.
공백 라인을 의미 있게 사용한다.

변수, 함수명을 축약하다가 중의적인 표현이 되어버린 적이 많은 것 같다.
이름이 길어지더라도 확실한 의도를 전할 수 있도록 해야겠다고 생각했다.

space와 tab을 혼용하지 않는다.
linter와 codeFormatter의 기능을 활용한다.
EOL(End Of Line)을 확인한다.

1주 차 미션을 진행하면서
작업 환경 별 코드 포멧팅이 상이하여 변경사항이 올바르게 표시되지 못한 커밋이 있었다.
이번 미션 시작과 동시에 prettier 설정 파일부터 작성했던 이유이기도 하다

⚾ 2주 차 미션 - 숫자 야구

2주 차 미션은 숫자 야구 게임을 구현하는 과제였고, 요구사항이 추가되었다!

추가된 여러 요구 사항 중, 내가 가장 많이 성장할 수 있었던 요구 사항은 다음과 같다.

Jest를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.
indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.

테스트 코드 작성의 중요성!

'Javascript info'라는 사이트에서 JS를 공부하면서, 테스트 자동화와 Mocha를 접한 적이 있다.

테스트 코드라고 말하기도 부끄러운 '1 + 1 은 2이다.' 같은 테스트 코드를 작성하며 이해해 보려 했었다.

당연하게도 테스트의 목적과 의미를 이해할 수 없었고, 심지어 문법조차 어렵게 다가왔다.
그렇게 해당 챕터를 넘어갔었다.

그때부터 지금까지 '프로덕션 코드부터 잘 짜고 그 후에 테스트 코드 공부하자!'
라는 생각으로 테스팅 공부를 미뤄왔던 것 같다. 그게 맞는 건 줄 알았다.

2주 차 미션을 하기 전까지는 말이다.

쉽지 않은 테스트 코드...

우선 기본을 다지기 위해 테스트 코드의 목적과 장점, Jest의 기본 문법에 대해 공부하며 포스팅하였고
이를 바탕으로 내가 만든 기능에 대한 테스트 코드를 작성해 보았다.

하지만 쉽지 않았고, 특히 코드의 형식을 어떻게 통일해야 하는지 감이 오지 않았다.
예시로 주어진 테스트 코드를 보고서는 감을 잡기 어려웠다.

고민은 깊어만 갔다.

한 줄기의 빛... MissionUtils 테스트 파일!

테스트 코드를 썼다 지웠다를 반복하며 고민을 이어가던 중,
'MissionUtils는 공개적으로 여러 명이 사용해야 하니깐 확실하게 검증하지 않았을까 ?'
'혹시... 테스트 파일이 있지 않을까 ?"
하는 마음에 뒤져 보았는데...

ㅇ..유..유레카!!

MissionUtils의 test 폴더를 발견했고, 테스트 파일의 코드에서 given, when, then 키워드를 발견했다!!!

given, when, then은 일종의 테스트 코드 패턴으로
앞서 테스팅에 대해 공부하며 알게 됐던 키워드이지만, 미숙했던 탓에 올바르게 적용하지 못하고 있었다.

이 발견을 통해 다양한 예시 코드를 보며 조금 더 나은 테스트 코드로 개선할 수 있었다.

재밌다! 테스트 코드!

테스트를 실행하고, 수정하고, 만들고를 반복하면서 이전에는 느끼지 못했던 장점을 조금씩 느낄 수 있었다.

기본적으로 내가 작성한 코드가 잘 동작한다는 것을 검증할 수 있었고, 버그 발생에 대한 불안함이 줄어들었다.

또한 코드를 리팩토링한 뒤 테스트를 실행하는 것만으로도 이전과 같은 올바른 동작을 하는지 검증할 수 있었다.

자연스레 리팩토링에 소요되는 시간도 줄어들게 되었다.

Good~

작성한 테스트가 Pass✅ 하는 걸 볼 때마다 더해지는 성취감은 덤이다.

물론 아직 기본적인 Matcher 메서드를 주로 사용하여 다소 1차원적인 모양이지만...

앞으로 의식적으로 테스팅을 연습하면서 더 깊게 공부해 볼 것이다.

** 테스팅을 학습하면서 큰 도움이 됐던 영상을 소개한다. [우아한테크세미나 TDD 리팩토링 by 포비]

** 어떤 방향으로 테스팅을 학습해야 하는지에 대해 중점적으로 보면 좋을 것 같다.

클린코드 작성하기 (feat. 동료의 관점)

클린 코드를 작성해야 하는 이유는 간단하다. 나만 볼 코드가 아니기 때문이다.

동료와 협업하는 과정에서 필연히 내 코드를 이해시켜야 하는 순간이 올 것이다.

추가된 요구사항도 비슷한 맥락에서의 의도가 아닐까 생각한다.

메서드가 한 가지 일만 하도록 최대한 작게 만들어라.
indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.

작성이 끝난 코드를 다시 살펴보면서 위 요구사항을 지키지 못한 부분이 있는지,

동료의 입장이 되어 코드를 처음 본다고 생각하며 읽어보았다.

상당히 주관적인 관점으로 작성한 코드가 많았고

많은 시간을 할애하여 리팩토링을 했다.

나만 아는 의미...

기존 코드

END_TRIGGER, Console.close()의 의미가 파악이 되지 않을 것이다.

위 코드는 trigger에 따라 게임을 재시작하거나 종료하는 로직이다.

나는 '재시작, 종료' 라는 조건을 알기 때문에 END라는 단어에서 종료의 의미를 찾을 수 있다.

Console.close() 함수는 사용자 입출력 인스턴스를 종료시키는 미션에서 제공한 유틸 함수이다.

나는 해당 함수가 무슨 동작을 하는지 알고 있다.

이 역시 나만 알고 있다.

조건을 모르고 처음 읽는 동료는 END, Console.close()의 동작을 바로 파악할 수 없다.

리팩터링 후 코드

Console.close() quitGame()으로

END QUIT으로 변경해서 종료의 의미를 강조하였다.

조건과 본문이 자연스럽게 이어지면서 의미 파악이 쉽다.

나만 편한 로직...

기존 코드

getStrikeBallCount는 스트라이크와 볼의 개수를 반환하는 함수이다.

목적을 알았어도 로직을 파악하기 어려울 것이다.

특히 밑줄 친 코드를 이해하기는 더욱 어려울 것이다.

'볼 개수에서 스트라이크 개수를 왜 빼주는 것이지?' 하고 의문을 가지게 되며

맥락 파악을 위해 다시 위쪽 for문으로 시선이 옮겨가야 한다.

이런 코드의 장점은 작성자가 편하다는 것이다.

이런 코드의 단점은 작성자만 편하다는 것이다.

리팩터링 후 코드

2개의 for문을 1개로 통합했고, 볼 개수에서 스트라이크 개수를 빼주는 로직도 제거하였다.

각 조건문에서 각자의 카운트만 계산하기 때문에 의미도 단순하고 파악하기 쉽다.
위에서 아래로 읽어 내려오면서 자연스럽게 로직의 맥락을 파악할 수 있는 코드가 되었다.

** 클린 코드를 학습하면서 큰 도움이 됐던 repository를 소개한다. [clean-code-javascript-ko]

** 코드를 작성할 때 어떤 것을 유의해야 하는가에 대해 중점적으로 보면 좋을 것 같다.

앞으로 보완할 점!

1. 테스트 코드 또한 동료가 이해할 수 있도록 가독성 있게 작성하기

테스트 코드에서 내 코드가 잘 작동한다는 검증을 할 수 있다.
반대로 테스트 코드를 보고 어떤 동작을 하는지, 어떻게 사용되어야 하는지 알 수 있어야 한다.
또한 프로덕션 코드를 추가했을 때, 테스트가 왜 실패하는지 쉽게 진단이 되어야 한다.
이번에 내가 작성한 테스트 코드는 위와 같은 부분을 지키지 못한 것 같다.
앞으로 더 많은 테스트 코드를 작성해 보면서 테스트 코드의 질 또한 높일 수 있도록 노력할 것이다.

2. 다른 사람이 작성한 코드 더 많이 보기

프리코스를 진행하면서 다른 사람의 코드를 읽는 경험을 하게 되었다.
개념에 대한 예시 코드나, 공식 문서가 아닌 실제 코드는 처음 읽는 것이다.
코드를 읽으면서 문맥을 파악하는 것도 실력이라고 생각한다.
앞으로 더 많은 사람들의 다양한 관점이 담긴 코드를 읽어보면서 배우고 흡수할 것이다.

2주 차를 마무리 하며

2주 차에 학습한 모든 내용 중 가장 뇌리에 깊게 박힌 건 단연 테스트 코드이다.

내겐 멀게만 느껴졌던 테스트 코드인데, 어느새 더 좋은 테스트 코드에 대한 고민도 하고 있다.

테스트에 대한 거리감을 어떻게 좁혀 나갈 수 있는지,

어떻게 내 것으로 만들 수 있는지 알게 되어 너무 좋다.

1주 차 미션으로 성장할 수 있는 길이 열렸었다.

이번 2주 차에는 목표했던 대로 열린 길을 따라 열심히 걸었다고 생각한다.

다음 3주 차에는 천천히 속력을 높여 달려보도록 하겠다!

가자!

Testing - 테스트 코드의 목적과 규칙, Jest 기본 문법

Creative_Lee — Thu, 3 Nov 2022 23:42:30 +0900

여러분들은 테스트 코드의 중요성을 알고 계신가요?

많은 개발자들이 자신이 작성한 코드를 테스트하기 위해, 또는

더 좋은 코드를 작성하기 위해 테스트 코드를 작성합니다.

코드를 위해 또 코드를 작성한다니 의아하지 않나요?

오늘은 테스트 코드를 작성하는 이유와

많은 개발자들이 사용하고 있는 Jest 테스팅 라이브러리에 대해 알아보겠습니다.

1. 테스트 코드의 목적

테스트 코드를 작성하는 목적이자 장점은 대표적으로 다음과 같습니다.

개발 과정 중 예상하지 못했던 문제를 미리 발견할 수 있다.
작성한 코드가 의도대로 동작하는지 검증할 수 있다.
코드 리팩터링 후 기존 소스와 동일한 동작을 하는지 검증할 수 있다.

장점만 있지 않겠죠?

흔히 테스트 코드의 단점으로 다음을 말합니다.

테스트 코드까지 작성해야 하므로 개발 시간이 오래 걸리게 된다.
어플리케이션에 변경이 발생하면 테스트 코드도 변경해야 한다.

하지만 버그를 발견하고 수정하는 과정이 많아질수록 오히려 개발 시간을 줄일 수 있다거나,

자유로운 수정과 삭제가 가능하므로 오히려 대처에 유연하다고 말하기도 합니다.

테스트 코드의 단점에 대해서는 관점을 달리하는 개발자도 많이 있는 것 같습니다.

2. 테스트 코드 작성 규칙

좋은 테스트를 위한 테스트 코드 작성 규칙은 다음과 같습니다.

독립적이어야 한다. 어떤 테스트도 다른 테스트에 의존하지 않아야 한다.
격리되어야 한다. Ajax, LocalStorage, UI Event 등 테스트 대상이 의존하는 것을 다른 것으로 대체한다.
given, when, then 단계에 따라 테스트 코드를 작성한다.

1번 규칙은 말 그대로 어떤 테스트가 다른 테스트 결과에 의존하거나 영향을 주면 안된다는 말입니다.

2번 규칙의 의존 대상을 다른 것으로 대체하는 것을 테스트 더블(Dummy, Stub, Fake, Spy, Mock)이라고 합니다.

3번 규칙의 예시를 들면 다음과 같습니다.

주어진 상황에(given) => 어떤 것을 요청, 이동, 생성, 작동하면(when) => ~~ 한다. (then)
( , ) 콤마 구분자 없이 => split 메서드를 사용하면 => 그대로 반환한다.

3. Jest 라이브러리 맛보기

지금까지 Jest를 설명하기 위한 빌드업이었습니다.

이제 기본적인 테스트 코드를 작성하며 Jest를 배워봅시다.

Jest는 Test Runner와 Test Matcher Test Mock 을 한 번에 제공해 주고, 별도의 설정이 필요 없어 각광받고 있습니다.

간단하게 Runner는 테스트 환경, Matcher는 비교 메서드, Mock은 테스트가 어려운 부분을 대체하는 도구입니다.

자세한 설명은 다음 포스트에서 알아보도록 하고,

오늘은 테스트의 형태를 만드는 기본 문법만 알아보겠습니다.

3-1. test 파일 생성

Jest는 기본적으로 test.js로 끝나거나,

__test__ 디렉터리 안에 있는 파일들은 모두 테스트 파일로 인식합니다.

취향에 따라 파일명.test.js 을 생성하거나, __test__ 디렉터리를 만들어 파일명.js 를 생성합시다.

3-2. test 파일 기본 문법

다음은 테스트 파일의 기본 구조와 문법입니다.

 /* --------- 문법 예제 ---------- */ 
describe("문자열 테스트", () => {
  test("repeat 메서드로 문자열을 여러번 반복", () => {
    const input = "abc";
    const result = input.repeat(3);

    expect(result).toEqual("abcabcabc");
  });
 })
  
 /* --------- 문법 설명 ---------- */ 
 describe("테스트 그룹에 대한 설명", () => {
  test("해당 테스트에 대한 설명", () => { 
    expect( 검증 대상 ).toXxx( 기대 결과 );
  });
 })

describe: 여러 테스트를 그룹으로 묶어주는 역할입니다.
내부에 테스트에 쓰일 변수, 객체 등을 선언합니다.
test: 개별 테스트를 의미하며 내부에서 검증을 실시합니다.
expext ( 검증 대상 ) : 검증하고자 하는 대상입니다.
.toXxx( 기대 결과 ) : toXxx 부분을 통해 검증 대상과, 기대 결과를 비교합니다.

3-3. toXxx ( a.k.a Test Matcher )

위 기본 문법에서 toXxx 부분이 바로 Matcher 메서드입니다.

toBe, toEqual, toContain 등 여러 가지 비교를 위한 다양한 matcher 메서드가 존재합니다.

다시 3-2 예제를 봅시다.

const input = "abc";
const result = input.repeat(3);

expect(result).toEqual("abcabcabc");

input 문자열인 "abc"를 3번 반복한 값과

"abcabcabc" 문자열을 대상으로

toEqual 비교를 하고 있습니다. 상당히 직관적이죠?
문자열은 서로 같기 때문에 test는 통과하게 됩니다.

어느 정도 감이 잡히는 것 같나요?
다음 포스트에서는 Jest의 여러 Matcher 메서드를 알아보겠습니다.

기본이 중요하다.

우테코 프론트엔드 5기 - 프리코스 1주 차 후기

Creative_Lee — Tue, 1 Nov 2022 01:06:05 +0900

드디어 기다리던 프리코스가 시작되었다!
짧은 시간이었지만, 배운 것은 엄청났고 성장했다.
남은 프리코스 기간동안 성장과 약점 보완을 목표로 달려나갈 것이다!
앞으로 매주 프리코스 후기를 작성하며 지난 한 주를 정리하려 한다.
성장했던 부분과 차주 목표를 중점으로 적어 나가 보겠다.

‍♂️ 1주 차 미션 - 온보딩

1주 차 미션은 코딩 테스트와 유사한 형식의 과제였고, 총 7개의 문제를 요구사항대로 처리해야 했다.

여러 요구 사항 중, 내가 가장 많이 성장할 수 있었던 요구 사항은 다음과 같다.

기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.

기능 구현 목록의 중요성

계획 없이 무작정 시작한 개인 프로젝트를 완성하기 위해 정말 많은 시간을 투자한 경험이 있다.

구현할 기능에 대한 기준 없이 시작한 개발이 원인이었다.

또다시 이런 문제를 만들지 않겠다고 다짐까지 했던 터라, 해당 요구사항에 더욱더 진지하게 임했다.

때문에 코딩 테스트와 유사한 과제임에도 기능 구현 목록을 꼼꼼하게 작성하려고 노력했다.

README.md 작성

문제를 해결하기 위한 기능들을 정리하면서 자연스럽게 전체적인 흐름이 이해되었다.

또한 명확한 목적이 생기다 보니 기능을 구현하는 시간도 단축됐다.

기능 구현 목록의 중요성을 다시 한번 상기시킬 수 있는 값진 시간이었다.
다시는 다짜고짜 코드부터 입력하지 않을 것이다...

올바른 커밋 메시지 작성하기

Git은 효과적인 버전 관리를 통해 효율적인 협업 환경을 제공한다.

하지만 나에게 Git은 개인 프로젝트를 위한 [혼자만의 저장소] 역할이었기에
평소 commit message를 대수롭지 않게 생각했고, 자유분방하게 입맛대로 작성하곤 했다.

이런 나에게 있어 [기능 단위 커밋] 이라는 요구사항은 나쁜 커밋 습관들을 부실 수 있는 기회가 되었다.

여러 개발자들이 따르고 있는 commit message convention에 대해 공부하고, 포스팅 하였고

이를 온보딩 미션 커밋에 적용시켜보았다.

컨벤션을 따르는 것만으로도 월등히 좋은 가독성을 얻을 수 있었고,

작성한 기능 구현 목록을 바탕으로 자연스럽게 기능 단위의 커밋 메시지를 작성할 수 있었다.

여전히 익숙하지 않은 탓에 제목에서 작업 내용을 서술하여 길게 설명하기도 하고,

commit type을 빼먹는 실수를 하기도 하지만, 앞으로도 꾸준히 컨벤션을 지켜 작성할 것이다.

다시는 이전과 같은 commit message를 작성하지 않을 것이다...

이전 커밋을 보고있자니... 그 차이가 너무나 명확하다...

제목과 본문 사이에 줄바꿈 하나 만으로 --oneline 옵션에서의 가독성을 챙길 수 있었다.

앞으로 보완할 점!

1. 기능 구현 목록은 전체적인 흐름을 이해하기 위한 용도로 작성하기

기능 구현 목록을 작성할 때 처음부터 구체적으로 작성하려고 하다 보니, 목록 작성 자체에 시간이 많이 소요됐다.
그럼에도 문제를 해결하는 도중, 기능을 추가해야 하거나 수정해야 하는 경우가 생기곤 했다.
앞으로 처음부터 모든 기능을 작성하려고 하기보다는 전체적인 흐름을 이해하며 작성하도록 노력할 것이다.

2. 내가 아닌, 다른 사람이 편하게 읽을 수 있는 코드 작성하기

PR로 과제를 제출하는 프리코스의 특성상 많은 사람들이 코드를 볼 수 있고, 필요하다면 참고할 수 있다.
때문에 이해하기 쉬운 직관적인 변수명에 대해 고민하며 코드를 작성했고,
모든 문제의 테스트 통과 이후, 작성한 코드를 살펴보면서 가독성이 좋지 못한 코드를 리팩토링했다.
그럼에도 타인이 나의 코드를 봤을 때 설명 없이 이해 하기엔 부족하다고 생각했다.
앞으로 코드의 가독성을 중점으로 발전된 코드를 작성하도록 노력할 것이다.

3. VSC 자체 설정 대신 Prettier 사용하기

과제를 진행하면서 의도하지 않았던 코드의 변경이 그대로 commit 되는 경우가 있었다.

노트북과 데스크탑을 오가며 과제를 수행하면서, VSC 코드 포맷팅 설정이 달라서 발생한 문제였다.

Tab size가 달라 위와 같은 문제가 발생했다.

width도 마찬가지

위와 같은 커밋에선 변경사항이 무엇인지 파악하기 어렵다. 의도하진 않았지만, 나쁜 커밋이 되어버린 것이다.

때문에 다음 미션부터는 Prettier를 사용할 것이다.

모든 작업환경에서 동일한 코드 포맷팅을 하여 위와 같은 일이 발생하지 않도록 해볼 생각이다.

1주 차를 마무리 하며

기능 목록과 기능별 커밋을 지키며 7문제를 풀었을 때 VS 백준, 프로그래머스에서 빠르게 7문제를 풀었을 때

모든 면에서 전자의 압승이었다.

앞으로의 성장에 필요한 중요한 키워드를 얻을 수 있어서 정말 좋았다.

미션을 진행하면서 새로운 방향으로 성장할 수 있는 길이 열린 것 같다.

2주 차에는 열린 길을 따라 쭈욱 걸어 나가보겠다!

Git - Commit message convention이란 ?

Creative_Lee — Sat, 29 Oct 2022 15:42:36 +0900

여러분은 Git을 어떻게 사용하고 계시나요?
commit message는 올바르게 작성하고 계시나요?

저는 Git을 작업 내용을 저장하거나, 기록을 남기는 [혼자만의 저장소] 느낌으로 사용하고 있었습니다.

때문에 commit message 또한 적당히 얼버무려 작성하곤 했죠..

하지만 실제 개발 업무는 대부분이 협업으로 이루어지고, 한 프로젝트를 여러 명이서 관리하게 됩니다.

때문에 협업 환경에서 효과적으로 Git을 사용하려면 Commit message convention을 지켜야 합니다.

이번 포스팅에서는 많은 개발자들이 사용하는 대표적인 구조를 토대로 설명하겠습니다.

1. commit message 기본 구조

기본 구조는 다음과 같습니다.

<type>(scope): <subject>
<공백 라인>
(body)
<공백 라인>
(footer)

< type >

작업 내용을 대표하는 키워드이며 필수사항입니다.
대표적으로 쓰이는 키워드는 다음과 같습니다.

feat: 기능의 추가, 수정, 삭제
fix: 버그의 수정
docs: 문서의 변경
style: 코드 스타일 변경( 코드 포맷팅, 세미콜론 누락 등 )
design: UI 디자인 변경(css 수정 등)
test: 테스트 코드에 대한 변경( production 코드 변경 X )
refactor: 코드 리팩토링( production 코드 변경 O )
bulid: 빌드 관련 파일 수정
ci: CI 설정 파일 수정
chore: 패키지 매니저 설정 변경과 같은 자잘한 수정
rename: 파일, 폴더명의 수정
remove: 파일을 삭제한 경우

(scope)

변경이 일어난 곳을 직접 표기하는 곳이며 선택사항입니다.
환경, 디렉터리 명, 파일명, 변수명, 클래스명 등이 들어갈 수 있습니다.

<subject>

작업 내용에 대한 제목을 표기하는 곳이며 필수사항입니다.

최대 50글자까지 허용하며, 제목의 끝에 마침표를 금지합니다. ( 한글 기준 25자 정도가 적당합니다.)

(body)

작업 내용에 대한 상세한 설명을 표기하는 곳이며 선택사항입니다.
'어떻게'보다는 '무엇을', '왜' 하였는가에 집중해 최대한 자세히 작성합니다.

이전과의 차이를 포함해도 좋습니다.

한 줄에 최대 72자까지 허용합니다. ( 한글 기준 36자 정도가 적당합니다.)

(footer)

관련된 이슈를 표기하는 곳이며 선택사항입니다.

[키워드 #이슈 ID] 의 형태로 표기하면 자동으로 해당 이슈를 종료합니다.

키워드는 다음과 같습니다.

close: 일반 개발 이슈
fix: 버그 픽스나 핫 픽스 이슈
resolve: 문의나 요청 사항에 대응한 이슈

2. convention의 효과

1. 좋은 가독성을 바탕으로 변경 내용을 이해하기 쉽다.

2. 변경 내용을 보다 확실하고 정확하게 전달할 수 있다.

3. 쉬운 이해와 정확한 정보를 바탕으로 빠르게 탐색할 수 있다.

4. 결론적으로 협업 환경에서 좋은 업무 효율을 기대할 수 있다.

3. 어느 쪽을 선택하시겠습니까?

둘 중 어떤 사람과 함께 일하고 싶나요?

좋은 코드를 작성하기 위해 많은 고민과 시간을 투자하는 것 처럼,

좋은 commit message를 작성하기 위해 노력해야겠습니다!
같이 일하고 싶은 사람이 되어봅시다.

기본이 중요하다.

JS - DocumentFragment 란?

Creative_Lee — Thu, 6 Oct 2022 16:37:17 +0900

우아한테크코스 5기를 준비하는 과정에서 프리코스 과제들을 접하게 됐습니다.

프리코스의 모든 과제들은 바닐라 자바스크립트로만 구현하여 제출해야하는데.....

바닐라 자바스크립트만으로 무언가를 만들어본 경험은

개발을 처음 배우기 시작했을 때 밖에 없는 것 같아 자신감이 떨어졌슴다!

아니나 다를까!
역대 지원자들의 코드를 찬찬히 살펴보던 중....

처음 보는 코드가 있더라구요...?

createDocumentFragment() 이게 무엇인고 ?
바로 공부 들어갔습니다!

0. DocumentFragment 에 대한 이해!

아래는 DocumentFragment에 대한 설명입니다.

DocumentFragment은 웹 문서의 메인 DOM 트리에 포함되지 않는,
가상 메모리에 존재하는 DOM 노드 객체입니다.
DocumentFragment 노드를 사용하면 메인 DOM 트리 외부에 경량화된 DOM을 만들 수 있어
브라우저 repaint 영향 없이 메모리에서 DOM 조작이 가능합니다.

무슨말인지 도통 이해가 가지 않으니, 하나씩 풀어서 이해해 봅시다!

1. createDocumentFragment( ) 로 DOM 요소 삽입하기!

DocumentFragment는 임시 바구니 입니다.

우리는 자바스크립트를 사용해 DOM 요소를 동적으로 추가할 수 있습니다.

이때 사용할 수 있는 방법중 하나가 바로 DocumentFragment 임시 바구니입니다.

임시 바구니로 DOM을 삽입해보면서,

DocumentFragment의 특징을 알아보겠습니다!

step 0. 목표

target-div에 3개의 <li> 태그를 자식으로 가지는 <ul> 태그를 추가하고 싶습니다.

DOM 접근은 최소한으로 하고싶습니다. ( 이유는 맨 뒤에 )

step 1. 바구니 만들기

let target = document.querySelector('.target-div') // 목표물
let $바구니 = document.createDocumentFragment() // 임시 바구니 생성

우선 임시 바구니를 하나 만들었습니다.

바구니는 document.createDocumentFragment() 메서드로 만들 수 있습니다.

*DOM 트리에 포함되지 않는, 가상 메모리에 바구니가 생성 되었습니다.*

이 바구니는 보이는 것 처럼 DOM 트리에 포함되지 않기 때문에,
*여기에 무엇을 담든 DOM에 영향을 주지 않습니다.*

step 2. 바구니에 자식 담기

const target = document.querySelector('.target-div')
const $바구니 = document.createDocumentFragment()
const $ul = document.createElement('ul')

const liArray = [1, 2, 3]
liArray.forEach(num => {
  const $li = document.createElement('li')
  $li.textContent = num
  $ul.appendChild($li) // ul에 li 담기
})

$바구니.appendChild($ul) // 바구니에 ul 담기
console.log($바구니)

ul의 자식으로 li를 담았고

바구니의 자식으로 ul을 담았습니다.

바구니를 출력해보면 다음과 같습니다.

바구니

*바구니에 무엇을 담던 여전히 DOM에는 영향이 없습니다.*

step 3. target DOM에 바구니 넣기

const $target = document.querySelector('.target-div')
const $바구니 = document.createDocumentFragment()
const $ul = document.createElement('ul')

const liArray = [1, 2, 3]
liArray.forEach(num => {
  const $li = document.createElement('li')
  $li.textContent = num
  $ul.appendChild($li)
})

$바구니.appendChild($ul)

$target.appendChild($바구니) // 타겟에 바구니 넣기

이제 target-div에 바구니를 넣었습니다.
원하던 목표를 달성했습니다.

*그런데 바구니는 사라지고, 내용물만 담겨있네요!*

바구니는 없다.

ul 만 옮겨졌어요

step 4. 바구니 확인

$target.appendChild($바구니) // 담고나서~
console.log($바구니) // 출력하면?

이후에 바구니를 출력해보면?

*바구니도 비어있습니다*

바구니에서 내용물만 옮겨졌네요!
어찌됐든, 1번의 DOM 접근으로 목표를 달성했습니다.

2. 중간 점검

여기 까지의 DocumentFragment 특징을 정리해보면 다음과 같습니다.

*여기에 무엇을 담든 DOM에 영향을 주지 않습니다.*
*바구니에 무엇을 담던 여전히 DOM에는 영향이 없습니다.*

- 최종적으로 DOM에 삽입 하기 전 까지는 아무 영향을 주지 않습니다.

*그런데 바구니는 사라지고, 내용물만 담겨있네요*
*바구니도 비어있습니다*

- DocumentFragment를 DOM에 삽입하면
fragment를 제외한 자식 요소들만 삽입되고, 이후 fragment 객체는 빈 객체가 됩니다.

3. createElement( ) 로 DOM 요소 삽입하기!

위 예제에서는 DocumentFragment 바구니를 사용했지만,
createElement로 평범한 DIV 바구니를 만들어 사용해도
1번의 DOM 접근으로,
DOM에 삽입 하기 전 까지는 아무 영향을 주지 않으면서
문제 해결이 가능합니다.

const $target = document.querySelector('.target-div')
const $DIV바구니 = document.createElement('div') // div 바구니~!
const $ul = document.createElement('ul')

const liArray = [1, 2, 3]
liArray.forEach(num => {
  const $li = document.createElement('li')
  $li.textContent = num
  $ul.appendChild($li)
})

$DIV바구니.appendChild($ul)

$target.appendChild($DIV바구니)

원하던 목표를 달성했습니다.

하지만 이번에는 바구니도 같이 들어가 있네요!

$target.appendChild($DIV바구니) // 담고나서~
console.log($DIV바구니) // 출력하면 ?

그리고 DIV 바구니에는 여전히 자식들이 담겨있습니다.

그냥 ul 태그를 바구니로 사용하면 해결되지 않나요?

const $target = document.querySelector('.target-div')
const $ul바구니 = document.createElement('ul')  // ul 바구니~

const liArray = [1, 2, 3]
liArray.forEach(num => {
	const $li = document.createElement('li')
	$li.textContent = num
	$ul바구니.appendChild($li)
})

$target.appendChild($ul바구니)

네 실제로 해결된것 처럼 보이네요!

$target.appendChild($ul바구니)
console.log($ul바구니)

여전히 ul 바구니에는 자식이 담겨 있긴 하지만요!

4. 만약 여러개의 루트 노드들을 한 번에 추가하고 싶다면?

그러면 이제 마지막으로 문제를 한번 바꿔보겠습니다.

target-div에 <ul>, <div>, <h3> 이렇게 3개의 루트 노트만 깔끔하게 추가하고 싶다면 어떻게 할까요?

createElement() 을 사용해서 DOM에 추가하면 무조건 바구니도 같이 들어갑니다.
깔끔하게 상위태그 없이 삽입하려면
어쩔 수 없이 3번 접근해서 DOM에 삽입해야겠네요.

createDocumentFragment() 를 사용하면 어떨까요?
여전히 1번의 접근으로 DOM에 삽입가능합니다!

5. DocumentFragment 의 장점

이제 결론을 지어봅시다.

1. DocumentFragment는 브라우저 성능 최적화에 도움을 줍니다.

DOM을 수정하는 행위는 브라우저의 Reflow를 일으킵니다.
Reflow는 성능에 매우 큰 영향을 미치기 때문에 최대한 적게 발생시키는게 중요합니다.

즉 DOM에 요소를 여러개 삽입하더라도, 가능하다면 묶어서 한 번에 삽입하는 것이 좋습니다.

만약 위와 같은 상황이라면, DocumentFragment를 사용하는 것이 성능에 도움을 줄수 있겠죠?

2. DocumentFragment는 메모리 소비 걱정을 하지 않아도 됩니다.

위 예제에서 봤던것 처럼 DocumentFragment는 DOM에 삽입된 즉시 비어있게 됩니다.
메모리에 대한 걱정을 하지 않아도 되는 이유입니다.

6. 성능상으로도 빠른가?

그렇지 않습니다.
createElement VS createDocumentFragment

엔진 별로 차이가 있다고 하네요. 미미해서 의미도 없다합니다.

성능보단 가독성의 향상 측면에서 바라보는 것이 좋겠습니다!

물론 Reflow가 여러 번 발생 될 수 있는 case라면 후자가 절대적으로 좋습니다!

7. 찐 결론

DOM에 요소를 삽입 할때에는

createDocumentFragment 메서드를 사용하자!

기본이 중요하다 !

알고리즘 - 투 포인터 (js 예제 구현)

Creative_Lee — Wed, 21 Sep 2022 16:30:08 +0900

1. 투 포인터(Two pointer) 알고리즘 이란 ?

배열이나 문자열 같이 선형으로 이루어진 구조에서

각자 다른 값을 가리키는 2 개 혹은 그 이상의 포인터를 두고
값 들을 비교하여 문제를 해결하는 알고리즘 입니다.

2. 예제 문제로 이해하기

input = [-2, -1, 1, 0, 1, 2]  answer = [-2, 2]

위와 같이 숫자로 이루어진 배열이 주어졌을 때,
배열의 요소 중 2개의 합이 0 이 되는 경우 중 ,
가장 빠른 경우에서의 두 수를 구하여라!
(배열은 오름차순으로 정렬되어 있다.)

위 예제문제를 풀어보며 이해해 봅시다.

2-1. 이중 for문 사용하기 / O(n^2)

function solution() {
  for (let i = 0; i < input.length; i++) {
    for (let j = i + 1; j < input.length; j++) {
      if (input[i] + input[j] === 0) {
        console.log([input[i], input[j]])
        return
      }
    }
  }
}

solution() // [-2, 2]

위와 같이 이중 for문을 사용하는 간단한 풀이를 생각해 볼 수 있습니다.

하지만 위와 같은 코드의 시간 복잡도는 O(n^2) 입니다.

문제의 input 배열의 길이가 길어지면 코드의 효율이 떨어지게 됩니다.

2-2. 투 포인터 알고리즘 사용하기 / O(n)

function solution() {
  let leftPointer = 0 // 왼쪽 끝
  let rightPointer = input.length - 1 // 오른쪽 끝

  while (leftPointer < rightPointer) {  
    let sum = input[leftPointer] + input[rightPointer]
    if (sum === 0) {
      console.log([input[leftPointer], input[rightPointer]])
      return
    }
    if (sum > 0) {
       rightPointer --
    }else{
       leftPointer++
    }    
  }
}

solution() // [-2, 2]

투 포인터 알고리즘을 활용한 풀이입니다.

배열의 서로 다른 원소를 탐색할 포인터 left, rightPointer를 만들었습니다.
반복문을 돌면서 로직을 수행합니다.

2-1. 두 수의 합이 0이면 두 수를 리턴합니다.
2-2. 두 수의 합이 0보다 크면 rightPointer를 1 감소 시킵니다.
(정렬된 배열이므로 오른쪽 포인터를 1 낮추면 합이 낮아집니다.)

2-3. 두 수의 합이 0보다 작으면 leftPointer를 1 증가 시킵니다.
(정렬된 배열이므로 왼쪽 포인터를 1 증가시키면 합이 높아집니다.)

위와 같은 풀이는

배열의 모든 요소를 한 번씩만 확인하면 되기 때문에 O(n)의 시간복잡도를 가집니다.

때문에 input 배열의 길이가 증가하여도 효율적인 탐색이 가능합니다!

3. 결론

모든 상황에서 투 포인터 알고리즘이 효율적인 것은 아니지만,

숙지하면 활용하기 상당히 좋은 알고리즘이다 !

재밌다 알고리즘!

6, 7, 8월 리뷰

Creative_Lee — Fri, 2 Sep 2022 12:56:12 +0900

어느새 여름이 다 지났다.

9월이 시작됐다!

저번 리뷰에서 목표로 했던 것들은 대부분 달성했다!

물론 반쪽짜리 완성이긴 하지만....

LOL 밴픽 프로젝트는 프로젝트 설계라는 과정이 거의 없다시피 시작해버린 바람에

내가 원하는 방향으로 계속 확장할수가 없어 종료했다.

처음에는 억울했는데, 내가 저지른 일이고, 내가 무지해서 생긴 일이니 억울할것도 없다는 생각으로 변했다.

적어도 다음 프로젝트에서는 이런 만행을 저지르지 않을테니 이것도 경험이라고 생각한다!

프로젝트 종료 이후 7월까지는 계획했던대로 TypeScript를 배웠다.

jsx를 기반으로 만들어진 강의를 내가 tsx로 따라해보면서 문법 기초를 다졌다.

8월부터 서버에 대한 기본적인 공부도 시작하며 현재 node.js 기초 강의를 완강했다.

이때부터 미뤄뒀던 알고리즘 공부도 시작했고 열심히 문제도 풀었다.

자 어쨋든, 나는 또 나아가야 하니 짧은 미래에 대한 계획을 세워본다!

1. 우테코 준비

10월 중순에 있을 우테코 5기 모집에 지원해 보려고 준비중이다.

나름의 방향을 가지고 홀로 공부해나가고 있지만, 그럼에도 동료가 있었으면 하는 바람이 항상 들었다.

내가 모르는 것을 배우고, 내가 아는 것을 나누는 환경이라면 훨씬 더 빠른 성장을 할 수 있지 않을까.

앞을 가로막는 장애물들을 어떻게든 부셔가며 같이 나아가는 협업 과정도 정말로 경험해 보고 싶다.

아 그래서 목표는요?

1차 코딩 테스트 통과할 수 있을 정도의 실력은 갖추어 놓기
자소서에 진심을 담아 작성하기
이전 기수 프리코스 과정 연습해 보기
지원하기!

10월 중순까지 또 미친 듯이 달려야 한다.

모든 것을 다 가질 수는 없다.

가지고 싶은 것이 있다면 다른 것은 포기해야 한다.

또 달려보자.

알고리즘 - DFS, BFS (JS 구현)

Creative_Lee — Wed, 3 Aug 2022 19:33:34 +0900

DFS와 BFS 모두 그래프를 탐색하는 방법중 하나입니다.

1. DFS(Depth-First-Search) 란?

루트 노드에서 시작해서 한 분기를 모두 방문하고 다음 분기로 넘어가는 방식입니다.

인접 노드를 깊이 우선으로 탐색하기 때문에 깊이 우선 탐색, DFS 라고 불립니다.

DFS의 예로 미로 찾기를 들 수 있습니다.

(최대한 한 방향으로 이동하고,

막다른 길에서는 이전 갈림길로 되돌아와

다시 한 방향으로 이동하기를 반복함)

위 예제 그래프를 DFS로 탐색하면

방문한 노드 순서는 1-2-4-5-3-6-7 입니다.

2. BFS(Breadth-First-Search) 란?

루트 노드에서 시작해서 인접한 노드들을 먼저 모두 탐색 하는 방식입니다.

인접 노드를 너비를 우선으로 탐색하기 때문에 너비 우선 탐색, BFS라고 불립니다.

위 예제 그래프를 BFS로 탐색하면

방문한 노드 순서는 1-2-3-4-5-6 입니다.

3. DFS, BFS 구현하기

DFS는 stack or 재귀함수

BFS는 queue로 구현 가능합니다.

1. Node 클래스

class Node {
  constructor(data) {
    this.data = data;
    this.adjacencyList = [];
    this.visited = false;
  }
}

2. Graph 클래스

class Graph {
  nodes = null;
  constructor(size) {
    this.nodes = new Array(size);
    for (let i = 0; i < size; i++) {
      this.nodes[i] = new Node(i);
    }
  }
  addEdge(idx1, idx2) { // 노드의 인접 관계 생성 메서드
    let node1 = this.nodes[idx1];
    let node2 = this.nodes[idx2];

    if (!node1.adjacencyList.includes(node2)) {
      node1.adjacencyList.push(node2);
    }
    if (!node2.adjacencyList.includes(node1)) {
      node2.adjacencyList.push(node1);
    }
  }

  dfs(idx) {
    let root = this.nodes[idx]; //idx를 받아 nodes 배열에서 루트노드를 정함
    let stack = []; // 스택 생성
    stack.push(root); // 스택에 루트 노드 푸시
    root.visited = true; // 루트 노드 스택에 들어갔으니 방문 체크

    while (stack.length !== 0) { // 스택이 비어있을 때 까지
      let popedNode = stack.pop(); // 스택에서 노드 하나 꺼냄

      for (let adjacencyNode of popedNode.adjacencyList) { // 꺼낸 노드의 인접 노드들
        if (adjacencyNode.visited === false) { // 인접노드에 방문 안했으면
          adjacencyNode.visited = true; // 방문처리
          stack.push(adjacencyNode); // 스택에 해당 인접노드 푸시
        } // 스택에는 루트의 인접노드들이 쌓이고 인접노드들이 또 쌓이고 반복하다가
      } //  인접노드가 없으면 반복문이 종료되고 종료 되고 종료되고 반복하다가
      this.visit(popedNode);
    } //  stack의 모든 노드들을 방문하면 dfs 함수 최종 종료
  }

  bfs(idx) {
    let root = this.nodes[idx];
    let queue = []; // 큐 생성
    queue.push(root); // 큐에 루트 노드 푸시
    root.visited = true; // 방문 처리
					// 이하 dfs스택과 설명 동일
 
    while (queue.length !== 0) {
      let deQueuedNode = queue.shift();

      for (let adjacencyNode of deQueuedNode.adjacencyList) {
        if (adjacencyNode.visited === false) {
          deQueuedNode.visited = true;
          queue.push(adjacencyNode);
        }
      }
      this.visit(deQueuedNode);
    }
  }

  visit(node) {
    console.log(`방문한 노드 데이터: ${node.data}`);
  }
}

3. 직접 구현한 함수 실행 결과

구현한 그래프 형태

DFS 결과는 다음과 같습니다.

BFS 결과는 다음과 같습니다.

자료구조 - 트리, 이진 트리, 이진 탐색 트리, 트리 순회, JS 트리 구현

Creative_Lee — Wed, 3 Aug 2022 14:52:46 +0900

1. 트리(tree) 란?

트리는 계층적인 자료를 표현하는 데 사용되는 자료구조입니다.

tree

1. Node

tree의 각 요소 ( A, B, C, D.... 와 같은) 를 노드 (Node) 라고 부릅니다.

B를 A의 자식 노드, A를 B의 부모 노드 라고 합니다.

각 Node는 자신의 데이터를 가지고 있으며, 자식 노드의 주소를 가지고 있을 수도 있습니다.

2. Root Node

A와 같이 부모 노드가 없고 최상단에 위치한 Node를 루트 노드( Root Node ) 라고 합니다.

3. Leaf Node

H, I, E, J, G 처럼 자식 노드가 없는 Node를 단말 노드( Leaf Node ) 라고 합니다.

4. size

모든 Node의 갯수를 크기(size) 라고 합니다. (ex. size: 10)

5. depth

Root Node로부터의 거리를 깊이(depth) 라고 합니다. (ex. B, C: 1 / D, E, F, G: 2)

2. 이진 트리(binary tree) 란?

자식 노드의 갯수가 최대 2개로 한정된 tree를 말합니다.

binary tree

최대 자식 노드 갯수가 2개인것 뿐이므로
위 그림에서 G 노드가 없어도 이진 트리입니다.

3. 이진 탐색 트리(binary search tree) 란?

이진 탐색이 동작할 수 있도록 고안된 자료구조의 일종입니다.

왼쪽 자식 노드가 부모 노드보다 작고

오른쪽 자식 노드가 부모 노드보다 큰 이진 트리를 말합니다.

왼쪽 자식 < 부모 < 오른쪽 자식

binary search tree

위와 같은 조건이 성립하면

원하는 값을 찾고 싶을 때 해당 값을 Root node의 값과 비교하여

왼쪽 혹은 오른쪽으로 탐색 해 나갈 수 있습니다.

(ex. Root node의 값인 10을 기준으로 11은 오른쪽에 있다는 것을 확신하고 검색할 수 있습니다.)

4. 트리 순회(Tree Travercal) 란?

트리 자료구조에 포함된 노드를 특정한 방법으로 한 번씩 방문하는 방법을 의미합니다.

보통 자신을 출력하는 방법과 같이 방문한 노드를 시각적으로 확인 가능합니다.

대표적인 트리 순회 방법은 3가지가 있습니다.

예제 tree

1. In order / 중위 순회 ( Left - Root - Right )

왼쪽 노드부터 출력합니다.

이후 Root 노드를 출력합니다.

이후 오른쪽 노드를 출력합니다.

예제를 중위 순회 하면 D-B-E-A-F-C-G 입니다.

2. pre order / 전위 순회 ( Root - Left - Right )

Root 노드를 먼저 출력합니다.

이후 왼쪽 오른쪽 순으로 출력합니다.

예제를 전위 순회 하면 A-B-D-E-C-F-G 입니다.

3. post order / 후위 순회 ( Left - Right - Root )

왼쪽 노드부터 출력합니다.

이후 오른쪽 노드를 출력합니다.

이후 Root 노드를 출력합니다.

예제를 후위 순회 하면 D-E-B-F-G-C-A 입니다.

4-1. 트리 순회 직접 구현

1. node 클래스

class Node {
  constructor() {
    this.left = null;
    this.value = null;
    this.right = null;
  }
}

2. tree 클래스

class Tree {
  contructor() {
    this.root = null;
  }

  setRoot(node) {
    this.root = node;
  }
  getRoot() {
    return this.root;
  }
  makeNode(left, value, right) {
    const node = new Node();
    node.left = left;
    node.value = value;
    node.right = right;
    return node;
  }

  inorder(node) {
    if (node !== null) {
      this.inorder(node.left);
      console.log(node.value);
      this.inorder(node.right);
    }
  }

  preorder(node) {
    if (node != null) {
      console.log(node.value);
      this.preorder(node.left);
      this.preorder(node.right);
    }
  }

  postorder(node) {
    if (node != null) {
      this.preorder(node.left);
      this.preorder(node.right);
      console.log(node.value);
    }
  }
}

3. 각 순회 함수 실행 결과

in oreder

pre order

post order

TS - Interface

Creative_Lee — Tue, 19 Jul 2022 16:22:45 +0900

타입스크립트에서 객체의 type을 지정해주는 방법에는 2가지가 있다.

하나는 type 키워드를 통한 기본적인 방법이고,

나머지 하나는 Interface 키워드를 통한 방법이다.

1. type의 쓰임새

type 키워드는 여러가지 방법으로 다양하게 사용 가능하다.

객체 외의 다른 자료형의 타입도 지정 가능하다.

1-1. 기본적인 타입 지정 ( ailas )

type Dmg = number
type Name = string

type Player = {
  name: Name,
  dmg : Dmg,
}

const bob : Player = {
  name: 'bob',
  dmg: 10
}

1-2. 타입이 특정 값을 가지도록 제한

type Team = 'red' | 'green' | 'yellow'
type Health = 10 | 20 | 30

type Player ={
  name: string
  team: Team
  health: Health
}

const bob : Player = {
  name: 'Bob',
  team: 'red',
  health: 10
}

2. interface의 쓰임새

interface는 TS에게 객체의 형태를 설명하고 싶을 때 사용하는 키워드이다.

type으로는 불가능한 타입 지정 방식이 interface로는 가능하다.

2-1. extends 키워드를 통한 상속

interface User {
  name: string
}

interface Player extends User{  
}

const bob : Player ={
  name: "Bob",
}

2-2. 동일한 이름의 여러개의 interface를 자동으로 병합

interface User {
  name: string;
}

interface User {
  healthBar: number;
}

interface User {
  isAdmin: boolean;
}

const bob: User = {
  name: "Bob",
  healthBar: 10,
  isAdmin: false,
};

3. interface사용법 ( feat. 추상 클래스 )

3-1. 추상 클래스의 단점

특정 클래스의 상속과 구현을 강제하려면 추상 클래스를 사용했다.

abstract class User{
  constructor(
    protected firstName:string,
    protected lastName:string
  ){}
  abstract sayHi(name:string):string;
  abstract fullName():string;
}

class Player extends User{
  sayHi(name:string){
    return `Hello ${name}!`;
  }

  fullName(){
    return `${this.firstName} ${this.lastName}`;
  }
}

하지만 추상클래스에 단점이 있다면,

자바스크립트에는 abstract 라는 개념이 없기 때문에

추상클래스도 일반적인 클래스로 변환된다.

상속받는 다른 클래스들이 표준화된 프로퍼티, 메소드를 가지도록 청사진 역할을 할 뿐이고

직접적인 인스턴스 생성이 불가함에도...

JS로 변환된 코드에는 일반 클래스로 변환되어 남아있다.

위와 같은 상황에 interface 사용을 고려할 수 있다.

3-2. interface 사용법

interface User {
  firstName: string
  lastName: string 
  sayHi(name: string): string
  fullName(): string
}

class Player implements User{
  constructor(
    public firstName: string,
    public lastName: string
  ){}
  
  sayHi(name: string){
    return `Hello ${name}!`;
  }

  fullName(){
    return `${this.firstName} ${this.lastName}`;
  }
}

interface를 정의한 후(메소드의 경우 abstract 키워드는 사용하지 않는다.)

해당 interface를 구현할 class에서 implements 키워드를 사용한다.

ex) class Player implements User

말 그대로 Player 클래스는 User 인터페이스를 구현한다.

*주의해야할 점

interface 상속을 통해 구현하는 class에서 프로퍼티는 항상 public 이어야 한다.

4. interface VS type ( 차이점 )

Type Alias는 새로운 프로퍼티 추가를 위해 같은 이름으로 선언할 수 없지만,
interface는 항상 선언적 확장이 가능하다.
Type Alias는 computed property 사용이 가능하지만,
interface는 불가능하다.

TS - Class

Creative_Lee — Mon, 18 Jul 2022 17:26:08 +0900

1. constructor - 프로퍼티 초기화

자바스크립트에서 처럼 this.X = X 형태의 문법은 더이상 사용하지 않는다.

타입스크립트에서는 constructor에서 한 번에 선언할 수 있다.

접근 제한자도 붙여줄 수 있다.

class Player {
  constructor(
    private firstName: string,
    protected lastName: string,
    public nickName: string
  ){}
}

1-1. 프로퍼티 메뉴얼 초기화

클래스의 프로퍼티가 constructor에 의해 바로 초기화 되지 않도록 할 수 있다.

type Words = {
  [key: string]: string;
};

class Dict {
  private words: Words;
  constructor() {
    this.words = {};
  }
}

위 코드에서는 word 프로퍼티를 수동으로 초기화 시켜주었다.

2. 접근 제한자

* 접근 제한자 - 메서드, 프로퍼티의 접근 범위를 지정할 때 사용한다.

private : 해당 클래스에서만 접근 가능
protected : 해당 클래스, 자식 클래스 에서 접근 가능.
public : 어디에서나 접근 가능하며 생략 가능한 default 값.

* 제한자 접근 가능 범위

	클래스 내부	자식 클래스	외부
private	O	X	X
protected	O	O	X
public	O	O	O

class Parents {
  constructor(
    private firstName: string,
    protected lastName: string,
    public nickName: string
  ) {}
}

class Child extends Parents {
  privateTest(){
    return this.firstName // error
  }

  protectedTest(){
    return this.lastName
  }
  publicTest(){
    return this.nickName
  }
}

const test = new Child('t','e','st')

test.firstName // private --> error
test.lastName // lastName --> error
test.nickName // public 프로퍼티만 어디서든 접근 가능합니다.

3. Abstract class( 추상 클래스 )

추상 클래스는 자식 클래스에게 상속을 강제하기 위한 클래스이다.

추상 클래스는 자신의 인스턴스 생성이 불가능하다.

abstract class Abstract {
  constructor(
    private firstName: string,
    protected lastName: string,
    public nickName: string
  ) {}
}

class Test extends Abstract {}

new Abstract // cannot create an instance of an abstract class.

3-1. Abstract Method (추상 메소드)

추상 메소드는 추상 클래스 안에서만 생성 가능하다.

이 역시 자식 클래스에게 메소드의 구현을 강제하기 위해 사용한다.

추상 메소드에는 call signature만 정의하고,

상속 받는 자식 클래스에서 추상 메소드를 구현한다.

abstract class Abstract {
  constructor(
    protected firstName: string,
    protected lastName: string,
  ) {}

  abstract speak():string
}

class Test extends Abstract {
  speak(){
    return `${this.firstName} ${this.lastName}`
  }
}

TS - 제네릭(generic)

Creative_Lee — Fri, 15 Jul 2022 18:21:09 +0900

제네릭이란?

선언 시점이 아닌 생성 시점에 타입을 명시하여

하나의 타입만이 아닌 다양한 타입을 사용할 수 있도록 하는 기법이다.

한번의 선언으로 다양한 타입에 재사용이 가능하다는 장점이 있다.

<T>는 제네릭을 선언할 때 관용적으로 사용되는 식별자이며, 타입 파라미터(Type parameter)라 한다.

( 'T' 외의 값을 사용해도 된다고 하는데 대부분 'T' 를 쓰는것 같다.)

함수에서의 제네릭

type SuperPrint = {
  <T>(arr: T[]): void;
};

const superPrint: SuperPrint = (arr) => {
  arr.forEach((item) => console.log(item));
};

superPrint([1, 2, 3]); // superPrint <number>(arr: number[]) => void
superPrint(["1", "2", "3"]); // superPrint <string>(arr: string[]) => void
superPrint([true, true, false]); // superPrint <boolean>(arr: boolean[]) => void
superPrint([1, "2", true]);
// superPrint <number|string|boolean>(arr: (number|string|boolean)[]) => void

위 코드의 SuperPrint type에는 제네릭이 사용되었다.

때문에 superPrint 함수의 파라미터 타입은 인수의 타입에 의해 결정된다. (* 코드 하단 4줄 참고)

// 의 내용에서 알 수 있듯 각 함수 호출마다 전달되는 인수의 타입을 통해 타입 파라미터를 추론하여 정한다.

* superPrint<number>( [1,2,3] )의 형태로 직접 명시도 가능하다.

코드 제일 하단에는 3가지 타입의 인수를 전달했는데,

제네릭이 없었다면 모든 타입의 경우의 수를 전부 명시해 줘야 했을 것이다.

위 코드에서 제네릭 대신 any를 사용해도 에러 없이 동작하지만,
코드가 조금만 추가되면 언제나 터질수 있는 시한폭탄을 설치한 것과 같다.

type checker의 도움을 받을 수 있도록 제네릭을 사용하도록 하자.

함수를 생성하기 전,

함수의 매개변수, 리턴 값의 타입을 Call Signature로 먼저 정해보고

그 과정에서 다양한 타입을 명시해줘야 하는 경우에는

제네릭 사용을 고려해 보도록 하자!

TS - Function Overloading

Creative_Lee — Fri, 15 Jul 2022 16:01:17 +0900

함수 오버로딩이란?

타입스크립트 에서는

여러 개의 Call signature를 갖는 함수를 하나의 이름으로 정의하는 것,

즉 여러 타입의 매개변수를 받지만

그에 의한 함수의 동작은 같아 하나의 함수 명으로 표현하고 싶을 때

사용할 수 있는 함수 정의 기술입니다.

* 객체 지향 프로그래밍의 특징 중 다형성( polymorphism ) 의 구현입니다.

call signature의 파라미터 수가 같을 때

type Add = {
  (a: number, b: number): number;
  (a: number, b: string): number;
};

const add: Add = (a, b) => {
  if (typeof b === "string") return a; 
  return a + b;
};

console.log(add(1,'문자열'))

위 코드에서 add 함수는 파라미터 수가 같은 2종류의 call signature를 가지고 있습니다.

때문에 add 함수 내부에서 타입이 number | string인 b에 대해 type 체크를 진행해서

각자 다른 값을 return 하도록 했습니다.

call signature의 파라미터 수가 다를 때

type Add = {
  (a: number, b: number): number;
  (a: number, b: number, c:number): number;
};

const add: Add = (a, b, c? :number)=> {
    if(c) return a + b + c
    return a + b
};

console.log(add(1,2)) // 3
console.log(add(1,2,3)) // 6

위 코드의 경우

위 코드에서 add 함수는 파라미터 수가 다른 2종류의 call signature를 가지고 있습니다.

때문에 type checker가 알수 있도록 '파라미터 c는 옵션이고 number일 수 있다' 라고 명시하였습니다.

TS - Call Signatures

Creative_Lee — Thu, 14 Jul 2022 19:32:32 +0900

Call Signatures란?

함수 매개변수와 return값의 Type을 미리 정하는 문법입니다.

함수선언 안에서 타입을 명시한 코드

function hello(name: string): void {
  console.log(`hello ${name}`);
}

Call Signatures를 사용한 코드

type Hello = (name: string) => void;

const hello: Hello = (name) => {
  console.log(`hello ${name}`)
}

hello('bob') //"hello bob"

Call Signatures를 사용하면

함수의 구현과 타입선언을 분리하여 구현할 수 있습니다.

타입 체커는 hello 함수의 타입을 이미 알기 때문에 에러없이 실행됩니다.

TS - 새로운 타입과 기본 문법

Creative_Lee — Thu, 14 Jul 2022 18:32:57 +0900

1. 타입 추론과 타입 표기

1-1. 타입 추론

타입스크립트의 타입 체커는 추론을 통해 타입을 정한다.

let a = 'hello'
let b = false
let c = 1
let d = [1,2,3]

위 코드에서 각 변수의 타입은 타입 체커에 의해 추론되어 정해진다.

a - string

b - boolean

c - number

d - number[ ]

1-2. 타입 표기(Type Annotation)

개발자가 직접 타입을 명시할 수 있다.

: type 을 사용한다.

let a : string = 'hello'
let b : boolean = false
let c : number = 1
let d : number[] = [1,2,3]

가능하다면 타입 체커가 추론을 통해 타입을 지정하도록 하는게 좋다.

코드의 길이나 가독성이 좋아진다.

타입 체커가 추론할 수 없는 상황이거나 명확한 이유가 있다면

명시적으로 타입을 표기한다.

2. Optional Parameter ( ? )

선택적인 프로퍼티, 파라미터를 만들어야 한다면 '?' 를 사용할 수 있습니다.

const player : {
  name: string,
  age?: number
} = {
  name: 'bob'
}

위 코드에서

age 프로퍼티의 type은 number, undefined 입니다.

때문에 age 프로퍼티의 값을 전달하지 않아도 에러가 발생하지 않습니다.

3. Type alias

자주 사용되는 타입을 변수의 형태로 지정할 수 있습니다.

type 변수명 = 타입 의 형태로 사용합니다.

type Player = {
  name: string,
  age?: number
}

const player1 : Player = {
  name: 'bob'
}

4. 함수의 arguments, return type

함수 코드에서는 인자의 타입과, 반환되는 값의 타입을 명시할 수 있습니다.

함수의 return type은 파라미터 다음에 명시합니다.

ex) function xxx ( ) : type { }

type Player = {
  name: string,
  age?: number
}

function playerMaker(name: string) : Player{
  return {
    name
  }
}

const bob = playerMaker('Bob')
bob.age = 27

위 코드에서

playerMaker 함수는 Player type을 return 하므로

함수의 실행으로 생성된 객체 bob에서

optional property인 age 프로퍼티를 추가할 수 있습니다.

화살표 함수의 경우 다음과 같이 명시합니다.

const playerMaker = (name: string) : Player =>{
  return {
    name
  }
}

const bob = playerMaker('Bob')
bob.age = 27

5. readonly 속성

readonly 속성은 type 정의나 interface 정의에서 사용할 수 있습니다.

해당 값을 읽기전용으로 만들 수 있습니다.

type Player = {
  readonly name: string,   // --> readonly 적용
  age?: number
}

const playerMaker = (name: string) : Player =>{
  return {
    name
  }
}

const bob = playerMaker('Bob')
bob.name = 'god' // Cannot assign to 'name' because it is a read-only property.

6. Tuple

타입스크립트에서 고정된 길이와 각 요소의 타입이 지정된 배열을 Tuple이라 부릅니다.

const player: [string, number, boolean] = ['bob', 27, false]

7. any

모든 타입을 허용하는 타입을 의미합니다.

떄문에 JS 프로젝트를 TS프로젝트로 점진적 마이그레이션 할때 유용합니다.

하지만

TypeScript의 타입 체커로 부터 자유로워지는 것은 반대로 보호를 받지 못하는 것과 같습니다.

const a : any[] = [1,'2',true]
const b : any = false

console.log(a + b) // "1,2,truefalse"

위 코드처럼 의도한 바가 아닐수도 있는 코드가 에러없이 실행 될 수 있습니다.

때문에 명확한 이유로 any를 사용해야 합니다.

8. unknown

해당 값이 어떤 type인지 알수 없는 경우 unknown 타입을 사용합니다.

let a : unknown = 'hello'

a.toUpperCase() // error : object is of type unknown

unknown의 경우 타입체커는 해당 값의 타입을 알지 못하므로

타입을 체크하는 코드로 타입 확인 후 사용가능합니다.

let a : unknown = 'hello'

if(typeof a === 'string'){
  console.log(a.toUpperCase())
} 

// HELLO

9. void

void는 아무것도 return하지 않는 함수를 대상으로 사용합니다.

function hello(){
  console.log("Hello!")
}

// function hello() : void

10. never

never는 모든 타입의 하위타입 입니다.

때문에 어떤값도 never타입에 할당할 수 없습니다.

함수가 절대 return하지 않을 때

function error(text: string): never{
  throw new Error(text) 
}

특정 타입 값을 할당받지 않도록 할 때 사용합니다.

type NonString<T> = T extends string ? never : T;

운동하고 싶다

TS - TypeScript란 ?

Creative_Lee — Thu, 14 Jul 2022 14:35:53 +0900

1. TypeScript란?

동적 타입 언어인 JavaScript의 단점을 보완하기 위해

JavaScript 기반으로 만들어진 정적 타입 언어이다! (자바스크립트의 슈퍼셋)

1-1. JavaScript의 단점

자바스크립트는 런타임에서 타입이 결정되는 동적 타입 언어이다.

개발자는 값의 종류, 즉 타입을 선언하지 않아도 되고

컴파일 과정이 없기 때문에 이런 부분이 장점이 되기도 한다.

하지만 이런 특징 때문에

개발자가 예상치 못한 에러가 발생하면 런타임에서야 오류를 발견할 수 있기 때문에

최악의 경우, 이미 프로그램이 멈춘 뒤일 것이다.

프로그램 사용자는 에러를 마주치고 이미 떠났다.

타입 안정성이 보장되지 않기 때문에 (프로그램에서 타입이 잘못 전달되어 발생되는 에러를 잡기 어려움)

프로젝트가 커질수록 디버깅이 어렵다.

이렇게 자바스크립트의 단점을 보완하기 위해

타입스크립트가 탄생하게 되었다.

2. TypeScript의 특징

타입 스크립트는 정적 타입 언어이다.

코드 작성 단계에서 부터 타입을 체크하고 오류를 확인할 수 있다.

ES6의 문법을 포함하고 있고 클래스, 인터페이스, 상속, 모듈 같은 객체지향 프로그래밍 패턴을 제공한다.

3. TypeScript의 장점

1. 변수나 함수에서 개발자의 목적에 맞지 않는 타입에 대한 에러를 발생시켜 버그를 미연에 방지합니다!

2. 코드 자동 완성, 피드백 제공을 통해 작업과 동시에 디버깅이 가능합니다!

3. 대부분의 라이브러리들이 타입스크립트를 지원하고, VSC 같은 에디터에서 타입스크립트 관련 플러그인을 제공합니다.

4. 자바스크립트 프로젝트에 대한 점진적 마이그레이션을 지원합니다!

4. TypeScript의 단점

1. 개발의 규모가 커질수록 타입을 설정하는 시간이 오래걸립니다.

2. 코드의 가독성이 떨어질 수 있습니다.

5. TypeScript의 컴파일 과정

타입스크립트 코드 --> 타입스크립트 AST --> 타입 체커가 AST 체크 --> 자바스크립트 코드로 변경

-------------------------- 여기까지 타입스크립트 컴파일러(tsc)에 의해 수행 ---------------------------------

자바스크립트 코드 --> 자바스크립트 AST --> 바이트 코드 --> 런타임이 바이트코드 평가 후 결과 반환

------------------------- 여기까지 자바스크립트 런타임(V8, node.js)에 의해 수행 -------------------------

* 자바스크립트 컴파일러와 런타임(node.js)은 엔진(V8)이라는 하나의 프로그램으로 합쳐진다.
현대 모던 엔진은 자바스크립트를 인터프리터 방식으로 실행하고,

필요하다면 컴파일도 한다.

이렇게 인터프리팅과 컴파일을 혼합하여 사용하는 것을

JIT( Just-In-Time ) 컴파일러 라고 한다.

때문에 현 시점에서의 JS는 컴파일되지만, 문맥상 인터프리터 언어로 분류된다.

5-1. 컴파일 vs 인터프리터

* 컴파일 언어 ( C, C++, Java 등)

- 코드 실행에 앞서 코드를 기계 언어로 미리 바꿔둔다. 때문에 런타임에서 빠르게 동작한다.

- 컴파일 시간은 소요되지만, 그 과정에서 Syntax, Type error를 감지한다.

* 인터프리터 언어 ( JavaScript, Python 등)

- 실행과 동시에 한 줄씩 중간 언어로 해석한뒤 실행한다.

- 컴파일 과정 없이 고수준 프로그래밍 언어를 바로 실행시킬 수 있다.

- 변경사항을 빠르게 테스트 하기에 용이.

5-2. 용어 설명

*AST( Abstract Syntax Tree )

- 프로그래밍 언어로 작성된 소스 코드의 추상 구문 구조 트리이다.

- 트리의 각 노드는 소스 코드에서 발생되는 구조를 나타낸다.

* 컴파일( compile )

- 큰 의미로 한 언어로 작성된 코드를 다른 언어의 코드로 변환하는 것

- 일반적으로 소스 코드를 바이트 코드로 변환하는 것

* 트랜스파일 ( transpile )

- 한 언어로 작성된 코드를 비슷한 수준의 추상화를 가진 다른 언어로 변환하는 것.

- 컴파일의 하위 개념

- ex) Babel - es6+ 코드를 es5로 트랜스 파일

6. tsc는 컴파일러지만 트랜스 파일을 한다...?

말이 조금씩 다르기는 하지만 주류가 되는 의견은 다음과 같다.

컴파일은 일반적으로 소스 코드를 바이트 코드로 변환하는 작업을 의미하므로,
.ts 파일을 .js 파일로 변환 시키는 타입스크립트 컴파일러는
실질적으로 트랜스 파일 하는 것이다.

(컴파일의 큰 의미에 속하기 때문에 TS의 컴파일 과정이라 부르면서도, '세부적으로 나누면 트랜스 파일이 맞지 않느냐'

라는 의견인 듯 합니다.)

운동하고 싶다

단 1명의 유저를 위한 서비스 개발을 마치면서...

Creative_Lee — Tue, 12 Jul 2022 19:59:59 +0900

제목 그대로 무려 1명의 유저가 사용하는 서비스 개발을 마쳤다

성공했지만 실패했다.

작은 것을 만들고 큰 것을 얻었다.

LOL은 인생이다.

무슨 미친 소리인가 생각했다면?

정상이다.

하지만 읽고 나면 이해가 될 것이다!

꼭 전부 읽어주면 좋겠다.

1. LOL 밴픽 시뮬레이터 프로젝트의 시작

평화로운 오후.

LOL 프로팀 코치를 하고 있는 친구와의 대화 내용이다.

- 나 : 요즘엔 일하는 거 어떻냐?

- 친구 : "아 맞다 너 뭐 좀 만들 수 있냐? 일하는데 개 답답함 ‍♂️ ‍♂️ ‍♂️"

- 나 : "으음..? ㅇ..예에?? 뭘요? "

이어서 심도 있는 대화가 오고 갔고,

친구는 곧바로 업무지시를 하기 시작했다.

노빠꾸 당일 업무시작

이렇게 정말 갑자기, 상당히 즉흥적으로

친구의 업무 환경 개선을 위한 프로젝트가 시작됐다!!

2. 고객의 불만사항 파악

코치는 선수들의 모든 경기를 모니터링하고, 분석하고, 전략을 짜야한다.

이를 위해 항상 필요한 정보는 양 팀의 밴픽 데이터이다.

친구는 (이하 고객이라 부르겠다 )

양 팀의 밴픽 데이터를 자료화하는 방식과 구조가 불만이었다.

일단 해결을 위해 여러 불만 사항들과 그로 인한 문제점을 정리했다.

문제점 1. 대회 클라이언트와 일반 클라이언트의 UI 일관성이 없다❌

스트레스는 만병의 근원

프로팀에서는 경기의 종류에 따라 사용되는 클라이언트가 다르다.

고객은 밴픽 데이터를 화면 캡처를 통해 정리하고 있었는데,

문제는 각 클라이언트가 관전자에게 제공하는 UI가 다르다는 것이었다.

캡처마다 화면구성이 달라 일관적이지 못했고

캡처물을 가지고 회의를 하거나 자료 통계를 낼 때 불편했다고 한다.

문제점 2. 캡쳐를 위해 항상 대기하고 있어야 한다❌

코치들은 관전자 권한으로 게임에 참여하게 된다.

LOL을 해본 사람은 알겠지만

밴픽 과정은 상황에 따라 길어질 수도 혹은 빠르게 끝날 수도 있다.

이론상 짧으면 6분 정도. 길면 12분까지도 소요된다.

양 팀의 밴픽이 끝나고 게임 시작 전까지 대략 30초~ 1분의 시간이 주어진다. ( 클라이언트, 게임 모드에 따라 상이하다. )

이 짧은 시간이 문제가 되었는데,

30초~ 1분이라는 주어진 시간 내에 화면 캡쳐를 하지 못하면 그대로 게임이 시작되어 버린다는 것이다.

상황에 따라 평균 10분 정도 자리를 지키고 있어야 했다.

선수들의 밴픽과정을 지켜보면서 코칭 할 때에는 겸사겸사 같이 해결하면 됐지만

그렇지 않은 때에도 자리를 지켜야 한다는 강제적인 상황은 당연히 스트레스일 것이다.

~~을 참은 적도 있다고 한ㄷ...~~

만약 혹시나 캡쳐 타임을 놓치고 나면...

우리 고객님은 엉엉 울며, 기존 캡처본에 짜깁기하여 직접 만들었다고 한다.

구글 검색을 통해 나오는 여러 밴픽 툴을 사용 해봤지만

모두 토너먼트 드래프트 모드 룰대로 시뮬레이션하는 방식이라 불편했고,

이 역시 UI가 달라, 불만사항 1에 해당하는 문제가 또 발생했다.

이에 포기하고 직접 만드는 걸 택했다고 한다.

시간이 배로 들었다.

문제점 3. 즉각적으로 변경되는 상황에 대응하기 어렵다❌

스크림은 팀 간의 연습 경기이기 때문에 실제 대회 경기와는 달리 룰에 있어서 비교적 자유롭다.

예를 들면, 스크림에서는

탑-정글-미드-원딜-서폿 포지션 순서를 맞추지 않고 게임을 시작할 때도 있고,

밴픽 진행 중 혹은 밴픽이 모두 끝난 후에도 양 팀 합의하에 리방을 해서

기존과 다른 밴픽으로 진행하는 경우도 있다고 한다.

또 스펠 같은 경우 빈번하게 변경되기 마련이다.

이런 즉각적으로 데이터가 변경되는 상황에서의 대응이 어려웠다고 한다.

예를 들면

1. 미처 캡쳐하지 못했는데 리방을 해버린다거나...

2. 이미 캡쳐했는데 스펠만 띵 하고 바뀐다거나...

3. 선수 한 명의 픽만 바꾸려고 리방 했을 때
암묵적으로 아무 챔피언으로 밴카드를 채워 빨리 진행시킨다거나...

3. 문제의 해결과 개발 시작!

모든 불만을 해결할 수 있는 방법은 아주 간단했다.

[시간제한 없고, 순서 상관없이 자유롭게 선택, 수정이 가능한 밴픽툴] 을 만드는 것.

항상 일관된 UI로 자료 저장이 가능할 것이고,

경기 전, 경기 중, 경기 후 언제든지 캡쳐가 가능하니 캡쳐를 위해 자리를 지킬 필요도 없을 것이고,

선택 수정이 항상 자유롭다면, 즉각적인 변화에도 대처가 가능할 것이다.

개발 시작 전 크게 2가지 정도만 생각했던 것 같다.

구현해야 할 기능들은 어떤 게 있지?
개발이 끝난 이후에 새로운 챔피언이 나오거나 하면 어떻게 하지 ??

(어떠한 준비 없이 개발을 시작한 것이 훗날 엄청난 재앙과 함께 깨달음을 주는 계기가 되었다 )

그리 많은 생각을 하지 않고 바로 CRA로 개발을 시작했는데,

대략적인 화면의 레이아웃을 만들고 생각했던 기능을 하나씩 붙여나가는 방식으로 개발했다.

우선 필수 기능을 우선적으로 구현했다. (밴, 픽, 스펠 선택 기능)

패치 버전 업데이트마다 코드를 직접 수정해야 하는 일을 만들지 않기 위해

라이엇이 제공하는 API를 사용했고, 이를 통해

서비스는 항상 최신 버전의 챔피언, 스펠 이미지를 사용할 수 있게 되었다.

이후 고객이 원하는 부가적인 기능들을 추가해 나갔다.

고객이 원하는 기능을 구현하고 난 뒤에는

더 편리하게 사용할 수 있도록 기능의 동작을 수정하는 식으로 발전시켰다.

ex) 검색 기능 사용 후 챔피언 선택을 확정하면, 검색 창이 자동 초기화 되도록 수정 -> 추가 검색이 편해졌다!

누군가 사용한다고 생각하니 사용자 경험을 계속 생각하게 됐다.

위의 과정을 계속 반복하면서 필요한 기능들이 모두 구현되었고,

한 달 정도의 개발 끝에 배포를 하게 되었다.

(훔쳐보기)

완성된 서비스의 한 화면... 이것은 복선이오

4. 프로젝트 성공!?

배포를 끝내자마자 바로 고객님께 사용을 요청했다. ( 뒤지게 설렜다... )

그리고 실제 사용을 마친 고객님께선 극찬을 아끼지 않으셨다

고객의 입에서 욕이 나왔다는 건, 극찬이 아닐까?

배포 후 고객이 실 사용하는 3주 정도의 시간 동안 추가 기능 요청이나, 불만사항이 없었고

어제 마지막 PR 후 개발을 마무리했다.

5. 서비스로 인해 개선된 업무효율

이 부분은 개인적으로 궁금해서 대화를 통해 단순 계산해 보았다.

관리하는 평균 경기 수
= 월 130경기 (1일 6경기 기준)
밴픽 과정 평균 소요 시간
= 10분
여러 변수로 인해 직접 자료를 만드는 평균 횟수
= 월 65회 (1일 3경기 이상)
직접 자료를 만들 때 평균 소요 시간
= 8분
서비스 사용시 평균 소요 시간
= 1분

절약된 시간

1번 X 2번 = 21시간 30분 ( 밴픽이 끝나길 기다리며 다른 업무 못하는 시간 )

3번 X 4번 = 8시간 40분 (직접 자료 만드는 시간)

합 = 월 평균 30시간 10분

기존보다 더 소요된 시간

1번 X 5번 = 월 평균 2시간 10분 (내 서비스로 자료 만드는 시간)

고객님은 월 평균 28시간을 아끼게 되었다.

물론 여러 조건들을 생각하지 않고 해본 단순 계산이지만

1달에 하루가 넘는 시간과, 스트레스까지 줄였으니 대 성공이다!

~~똥을 참지 않아도 되는 것까지 하면 이건... 그야말로..~~

6. 정말 성공일까...? ( feat. 시뮬레이션 없는 시뮬레이터 ‍♂️)

고객은 상당히 만족했고 실제로도 엄청난 시간을 절약하며, 스트레스까지 줄였다.

자 여기까지만 본다면 이토록 성공적일 수가 없다.

하지만... 이 서비스에는 옥의 티가 있다.

바로 시뮬레이션 기능이 없는 시뮬레이터 프로젝트라는 것이다.

사실 처음 프로젝트를 시작할 때에는
'내 친구에게 필요한 기능을 만들어 주는 것' 이 목표였다.
그렇게 개발하던 중 '모든 사람들이 사용할 수 있는 롤 밴픽 시뮬레이터의 구현'으로 목표를 확장시켰었다.

친구에게 필요한 빠른 밴픽 모드와
일반적인 lol 유저들이 사용할 수 있는 토너먼트 드래프트 모드로 나누어 개발하려고 했고,

빠른 밴픽 모드의 개발이 끝난 후 1차 배포까지만 하더라도
각 모드의 기능은 비슷하니 금방 만들 수 있겠다 생각했었다.

내 처참한 코드를 되돌아보기 전까지만 해도 말이다.

6-1. 빠른 개발, 정말 나쁜 코드, 그리고 멸망

LCK 프로 팀들은 시즌이 시작되기 몇 주 전부터 본격적으로 스크림(연습경기) 도 많아지곤 하는데,
최대한의 효율을 위해 시즌 전까지 빠르게 개발하려고 노력했다.

그러다 어느 순간부터는 점점 코드가 더러워지고 구려지는 걸 느낄 수가 있었는데..

그때마다 남은 시간을 생각하며 코드보다 기능 구현에 초점을 맞추게 되었다..

한 달이라는 시간 동안 개발에만 몰두한 덕분에 나름대로 정해놓은 제작 기간 내에 완성할 수 있었고
친구에게 좋은 업무용 툴을 선물할 수 있었다.

급한 일은 끝냈으니, 충분한 시간을 통해 천천히 드래프트 모드를 구현하려 했는데 그럴 수 없었다.

생산성을 위한 컴포넌트 분리도 되어있지 않았고,

디렉터리 구조도 분리되어 있지 않았다.

.scss 파일 하나에 모든 스타일이 들어있었다.

이미 내 코드는 엉망이 되어있었다.

내가 싸지른 똥을 치우려

급하게 컴포넌트, 디렉터리, 스타일을 모두 나누고 정리했지만, 이미 늦었다.

분리하고 나니 15개 정도의 컴포넌트로 나뉘었는데,

전역에서 엄청난 개수의 props를 각 depth의 컴포넌트로 전부 전달해야 했다.

이미 하나의 파일에서 엄청난 수의 state와 함수로 동작하도록 구현했기 때문이다.

각 컴포넌트끼리의 결합도가 엄청나게 높아져서 어떻게 손을 댈 수가 없었다.

며칠간 코드를 정리하기 위해 노력했지만,

지금의 내 능력으로는 도저히 진전이 없었고 개발을 중단하기로 했다.

그렇게 토너먼트 드래프트 모드는 개발하지 못했고,

시뮬 없는 시뮬레이터 프로젝트가 완성되었다.

6-2. 초기 설계의 중요성

나는 초기 설계라는 개념 자체가 없었다.

프로젝트 초기 단계에서 해야 할 컴포넌트, 디렉터리 구조 설계 등을 하지 못했고 바로 개발을 시작했다.

흘러가는 대로 개발했고, 결국 프로젝트 미완성으로 이어졌다.

7. 프로젝트를 통해 얻은 것들

7-1. 개발 필수 규칙

1. 꼭 충분한 초기 설계를 하고 개발할 것.

2. 사용하는 기술의 본질을 이해하고 사용할 것.

3. 내가 적은 코드에 발목 잡히는 일이 없도록 노력할 것.

앞으로의 또 다른 개발에 있어서 내가 꼭 지켜야 할 규칙을 정할 수 있었다.

만약 조금이라도 생각하며 개발했다면, 지금쯤 드래프트 모드 개발이 끝나지 않았을까 싶다.

아쉽지만 내 업보라고 생각하면서 앞으로는 위의 철칙들을 꼭 지켜보려 한다.

7-2. 소통의 중요성

개발 과정중에 고객의 기습 기능 추가 요청이 있었다.

노밴 기능 추가 요청

애초에 깊은 설계를 한 건 아니지만,

기존에 생각해놓은 틀에서 벗어난 요청이 들어오니 당황스러웠다.

하지만 고객은 처음부터 내가 고려할 줄 알았다고 한다.

서로 충분했다고 생각한 소통이

충분하지 않았다는 것으로 결론지었다.

앞으로 수없이 많은 개발을 할 테고, 수없이 많은 소통을 할 것이다.

대상은 이번처럼 고객이 될 수도 있고, 디자이너가 될 수도 있고, 개발자가 될 수도 있다.

조금 더 구체적으로 계획하고 소통해야

서로 띠용~? 하는 상황이 최대한 줄어들지 않을까 하는 생각을 했다.

7-3. 마무리

닥치는 대로 적다 보니,

며칠 머리통 깨지며 포스팅했던 실행 컨텍스트 포스트만큼 길어졌다.

실제로 유저가 사용할 서비스를 개발해 보는 것도,

요구하는 대로 개발하는 것도,

피드백을 주고받으며 서비스를 수정하는 것도,

그리고 그 프로젝트가 실제로 사용되는 것도

전부 처음이었다.

'내 개발 실력이 누군가에게 도움은 될 수 있는 정도구나'라는 기쁨도 있었지만,

'갈 길이 한참 남았구나'라는 좌절도 있었다.

그럼에도 멈추고 싶기보다는 더 빨리 가고 싶은 생각만 든다.

이번 프로젝트는

성공했지만, 실패했다.

작은 것을 만들고 큰 것을 얻었다.

LOL은 인생이다.

기본이 중요하다!

class - mixin

Creative_Lee — Mon, 27 Jun 2022 13:33:05 +0900

1. mixin

자바스크립트는 단일상속만을 허용합니다.

객체에는 단 하나의 [[ Prototype ]] 만 존재할 수 있고,

클래스는 단 하나의 클래스만 상속 받을 수 있습니다.

이런 제약에서 벗어나기 위해 mixin 을 사용할 수 있습니다.

mixin이란 특정 행동을 실행해주는 메서드를 제공하는 객체입니다.

이 객체를 다른 클래스에 병합해 사용합니다.

let helloMixin = {
  sayHello(){
    console.log(`Hello ${this.name}`)
  }
}

class User {
  constructor(name){
    this.name = name;
  }
}

Object.assign(User.prototype, helloMixin);

new User('Bob').sayHello(); // 'Hello Bob'

상속 없이 메서드를 복사하여 인스턴스에서 메소드를 사용할 수 있습니다.

믹스인에서 믹스인을 상속받아 사용할 수 있습니다.

let say ={
  say(msg){
    console.log(msg)
  }
}

let sayHelloMixin = {
  __proto__: say,

  sayHello(){
    super.say(`hello ${this.name}`)
  }
}

class User {
  constructor(name){
    this.name = name;
  }
}

Object.assign(User.prototype, sayHelloMixin);

new User('Bob').sayHello(); // 'Hello Bob'

sayHelloMixin은 say객체를 상속 받았습니다.

이때, 생성된 인스턴스에서 호출한 sayHello()을 주목해 봅시다.

sayHelloMixin에서 부모메서드 super.say를 호출하면,

클래스의 프로토타입이 아닌 sayHelloMixin의 프로토타입에서 메서드를 찾게되는데,

위와 같은 동작은

[[ HomeObject ]] 라는 함수 전용 특수 내부 프로퍼티와

super() 의 동작방식 때문에 발생합니다.

클래스이거나 객체 메서드인 함수의 [[ HomeObject ]] 라는 프로퍼티에는 해당 객체가 저장됩니다.

super는 [[ HomeObject ]] 를 통해 부모 프로토타입과 메서드를 찾습니다.

위 그림처럼

User.prototype 의 프로퍼티인 sayHello와 같은 메서드에서 사용된 super는

[[ HomeObject ]] 를 통해 메소드의 생성 근원지인 sayHelloMixin 객체를 알 수 있고,

이를 통해 부모 프로토타입과 해당 메서드를 찾습니다.

요약

1. mixin은 다른 클래스들의 메서드 조합을 포함하는 클래스를 의미합니다.

2. 자바스크립트에서는 다중 상속을 지원하지 않으므로

믹스인을 사용하여 메서드 복사를 통해 프로토타입에 구현할 수 있습니다.

3. mixin이 기존 클래스 메서드를 덮어쓸 수 있으므로 충돌이 발생하지 않도록 이름을 신중하게 정해야 합니다.

어렵구나

class - 내장 class의 특성

Creative_Lee — Fri, 24 Jun 2022 15:53:26 +0900

1. 내장 클래스 확장하기

class PowerArray extends Array {
  isEmpty() {
    return this.length === 0;
  }
}

let arr = new PowerArray(1, 2, 5, 10, 50);
console.log(arr.isEmpty()); // false

let filteredArr = arr.filter(item => item >= 10)
 //filter 내장 메소드로 새로운 배열 리턴

console.log(filteredArr); // [10, 50]  새로운 배열의 값
console.log(filteredArr.isEmpty()); // false 
// 새롭게 리턴된 배열에서도 PowerArray의 메소드를 사용할 수 있다.

PowerArray 클래스로 생성한 arr 인스턴스의 내장 메서드를 사용했는데,

그에 대한 반환값도 PowerArray의 인스턴스인 모습입니다.

새로운 배열을 리턴해주는 메소드의 내부에서 객체의 constructor 프로퍼티를 사용하기 때문입니다.

console.log(arr.constructor === PowerArray); // true

위와 같은 동작 방식으로 PowerArray에 구현된 메서드를 사용할 수 있다는 장점이 생깁니다.

특수 정적 getter인 Symbol.species를 클래스에 추가하여

map, filter 등의 메소드 호출시 리턴되는 개체의 생성자를 직접 지정할 수 있습니다.

class PowerArray extends Array {
  isEmpty() {
    return this.length === 0;
  }

  static get [Symbol.species](){
    return Array
  }
}

let arr = new PowerArray(1, 2, 5, 10, 50);
console.log(arr.isEmpty()); // false

let filteredArr = arr.filter(item => item >= 10)

console.log(filteredArr.isEmpty()); // TypeError: filteredArr.isEmpty is not a function

더이상 filteredArr에는 isEmpty() 가 없습니다.

2. 내장 객체와 정적 메서드 상속

일반적으로 클래스가 다른 클래스를 상속받으면

정적 메서드는 Class 상속을 통해, 일반 메서드는 Class.prototype 객체 상속을 통해

모두 상속 받아 사용 가능했습니다.

하지만 내장 클래스는 다릅니다.

내장 클래스는 정적 메서드는 상속받지 못합니다.

그 이유는 간단합니다.

내장 객체끼리는 Class 상속이 이뤄지지 않습니다.

console.log(Array.prototype.__proto__ === Object.prototype) // true
console.log(Array.__proto__ === Object) // false

위와 같은 구조 때문에

인스턴스에서 Array.keys() 나 Date.keys() 같은 정적 메서드를 사용할 수 없는 것입니다.

쉬어가는 단계

class - private, protected

Creative_Lee — Wed, 22 Jun 2022 20:28:25 +0900

1. 객체 지향의 캡슐화

객체 지향 프로그래밍의 중요한 원리 중 하나는

내부 인터페이스와 외부 인터페이스를 구분 짓는 것,

즉 캡슐화 입니다.

객체 지향 프로그래밍에서 프로퍼티와 메서드는 2개의 그룹으로 분류됩니다.

내부 인터페이스 - 동일한 클래스 내의 다른 메서드에서는 접근할 수 있지만,
클래스 밖에서는 접근 할 수 없는 프로퍼티와 메서드
외부 인터페이스 - 클래스 밖에서도 접근 가능한 프로퍼티와 메서드

커피 머신으로 예를 들자면

외형에는 커피를 뽑는 버튼 몇 개, 구멍 몇 개, 화면 하나 정도가 있습니다.

내부에는 디테일한 장치들과 부품들이 전부 들어있습니다.

하지만 내부의 것을 알지 못해도 사용자는 간단한 조작으로 커피 머신을 사용할 수 있습니다.

커피 머신의 내부를 가려주는 보호 커버를 제거하면

사용법이 복잡해지고 감전 같은 위험한 상황이 발생하기도 합니다.

머신 안쪽에 숨어있는 디테일한 장치와 부품들이 내부 인터페이스가 될 수 있습니다.

내부 인터페이스의 세부사항들은 서로의 정보를 이용해서 객체를 동작시킵니다.

커피 머신은 보호 커버에 쌓여 있기 때문에 벗기지 않고는 커피머신 외부에서 내부로 접근할 수 없습니다.

밖에서는 내부를 알 수 없고, 접근할 수 없습니다.

내부 인터페이스의 기능은 외부 인터페이스를 통해야만 사용할 수 있습니다.

이런 특징 덕분에 외부 인터페이스만 알아도 객체를 가지고 무언가를 할 수 있습니다.

객체 내부 동작이 어떤지 몰라도 괜찮다는 점은 큰 장점으로 작용합니다.

자바스크립트에는 두 가지 타입의 객체 필드가 있습니다.

public : 어디서든지 접근할 수 있으며 외부 인터페이스를 구성합니다.
private : 클래스 내부에서만 접근할 수 있으며 내부 인터페이스를 구성할 때 사용됩니다.

2. protected 필드

자바스크립트에서는 프로퍼티명 앞에 밑줄 _ ( under score )을 붙여

클래스 자신과 자손 클래스에서만 접근을 허용하는 'protected' 필드를 모방해서 사용할 수 있습니다.

(정식으로 지원하지 않습니다.)

protected 필드는

private와 비슷하지만, 자손 클래스에서도 접근이 가능하다는 차이점이 있습니다.

class CoffeeMachine {
  waterAmount = 0; // 물통에 차 있는 물의 양

  constructor(power) {
    this.power = power;
    console.log( `전력량이 ${power}인 커피머신을 만듭니다.` );
  }

}

// 커피 머신 생성
let coffeeMachine = new CoffeeMachine(100);

// 물 추가
coffeeMachine.waterAmount = 200;

위 코드에서 waterAmount 와 power는 public입니다.

원하는 값으로 쉽게 변경 할 수 있는 상태입니다.

waterAmount를 protected 프로퍼티로 바꿔서 통제해보겠습니다.

class CoffeeMachine {
  _waterAmount = 0;

  set waterAmount(value) {
    if (value < 0){
      console.log("물의 양은 음수가 될 수 없습니다.")
      return 
    }

    this._waterAmount = value;
  }

  get waterAmount() {
    return this._waterAmount;
  }

  constructor(power) {
    this._power = power;
  }
}

// 커피 머신 생성
let coffeeMachine = new CoffeeMachine(100);

// 물 추가
coffeeMachine.waterAmount = -10 // 물의 양은 음수가 될 수 없습니다.

getter와 setter를 활용해서 waterAmount 프로퍼티를 protected 프로퍼티로 바꿨습니다.

코드에 따라 waterAmount 프로퍼티는 조건에 부합할 때에만 수정할 수 있습니다.

읽기 전용 프로퍼티

power 프로퍼티는 인스턴스 생성시에만 값을 할당할 수 있어야 합니다.

커피 머신의 전력량은 항상 같아야 겠죠.

이런 경우에 읽기 전용 프로퍼티를 활용할 수 있습니다.

읽기 전용 프로퍼티는 setter를 구현하지 않고, getter만 구현하면 됩니다.

class CoffeeMachine {
  constructor(power) {
    this._power = power;
  }

  get power() {
    return this._power;
  }
}

let coffeeMachine = new CoffeeMachine(100);

console.log(`전력량이 ${coffeeMachine.power}인 커피머신을 만듭니다.`); 

coffeeMachine.power = 25 // 코드가 동작 하지 않습니다.

console.log(coffeeMachine.power) // 100

getter만 구현했으므로

인스턴스 생성시를 제외하고 power 프로퍼티를 수정할 수 없습니다.

대부분의 코드에서는 get, set 문법보다 다음과 같이

get.... set.....식의 함수가 선호됩니다.

다수의 인자를 받을 수 있다는 장점이 있습니다.

class CoffeeMachine {
  _waterAmount = 0;

  setWaterAmount(value) {
    if (value < 0){
      console.log('물의 양은 음수가 될 수 없습니다.')
      return
    }

    this._waterAmount = value;
  }

  getWaterAmount() {
    return this._waterAmount;
  }
}

let coffeeMachine = new CoffeeMachine()
coffeeMachine.setWaterAmount(-1); // '물의 양은 음수가 될 수 없습니다.'
console.log(coffeeMachine.getWaterAmount()) // 0

protected 필드는 상속됩니다.

위 예제를 예로 들어

CoffeeMachine 클래스를 상속 받는 자식 클래스가 있다면

자식 클래스의 메서드에서 this._waterAmount, this.power 를 사용해 프로퍼티에 접근 할 수 있습니다.

protected 필드는 private 필드와는 다르게 상속이 가능하므로 ,

자손 클래스에서도 접근이 가능합니다!!

3. private 필드

프로퍼티나 메소드의 앞에 # 을 붙여 private 필드로 만들 수 있습니다.

class CoffeeMachine {
  _waterAmount = 0
  #waterLimit = 200;

  #checkWater() {
    if (this._waterAmount < 0) throw new Error("물의 양은 음수가 될 수 없습니다.");
    if (this._waterAmount > this.#waterLimit) throw new Error("물이 용량을 초과합니다.");
  }

}

let coffeeMachine = new CoffeeMachine();

coffeeMachine.#checkWater(); // Private field '#checkWater' must be declared in an enclosing class
coffeeMachine.#waterLimit = 1000; // Private field '#checkWater' must be declared in an enclosing class

private 필드는 해당 클래스 안에서만 접근 가능하고,

클래스 외부나 자손 클래스에서 접근 할 수 없습니다.

private 프로퍼티와 public 프로퍼티를 동시에 가질 수 있습니다.

class CoffeeMachine {
  #waterAmount = 0;

  get waterAmount() {
    return this.#waterAmount; // 해당 클래스 내에서만 private 프로퍼티에 접근 가능합니다.
  }

  set waterAmount(value) {
    if (value < 0) throw new Error("물의 양은 음수가 될 수 없습니다.");
    this.#waterAmount = value; // 해당 클래스 내에서만 private 프로퍼티에 접근 가능합니다.
  }
}

let machine = new CoffeeMachine();

machine.waterAmount = 100; // --> setter호출
console.log(machine.waterAmount); // 100 --> getter호출
console.log(machine.#waterAmount) // Error: Private field '#waterAmount' must be declared in an enclosing class

waterAmount 는 public 프로퍼티이고,

private 프로퍼티인 #waterAmount 의 접근자 입니다.

class MegaCoffeeMachine extends CoffeeMachine {
  test(){
    return this.#waterAmount // SyntaxError: Private field '#waterAmount' must be declared in an enclosing class
  }
}

자식 클래스에서는 private 프로퍼티에 직접 접근 할 수 없습니다.

class MegaCoffeeMachine extends CoffeeMachine {}

let megaMachine = new MegaCoffeeMachine();

megaMachine.setWaterAmount(100);
console.log(megaMachine.getWaterAmount()); // 100

자식 클래스에서 private 프로퍼티에 접근하려면

getter, setter를 사용하면 됩니다.

private 필드는 this[name]로 사용할 수 없습니다.

private 필드는 computed property를 사용할 수 없습니다.

class User {
  field = 'Bob'

  sayHi() {
    let fieldName = 'field'
    console.log(`Hello, ${this[fieldName]}`);
  }

  #private = 'God'

  test(){
    let fieldName = 'private'
    console.log(`Hello, ${this[fieldName]}`);
  }
}

let user = new User();
user.sayHi() // Hello, Bob
user.test() // Hello, undefined

다양한 시나리오에서 위와 같은 private의 제약사항은 너무 엄격합니다.

자식 클래스에서 부모 클래스의 내부에 접근해야 하는 상황이 있을 수 있기 때문입니다.

언어차원에서 지원하지 않는 protected 필드를 더 자주 사용하는 이유입니다.

요약

1. OOP에서 내부 인터페이스와 외부 인터페이스를 구분하는 것을 캡슐화 (encapsulation) 이라고 한다.

2. 캡슐화의 이점은 다음과 같다.

외부 사용자의 내부 로직 조작으로 인한 에러를 방지함
외부 사용자에게 알리지 않고도 자유롭게 내부 프로퍼티와 매서드 수정 가능 , 업그레이드 용이
(사용자는 외부 인터페이스만 똑같다면 내부 로직이 바뀐걸 알지 못함)
구현 세부 사항을 숨길 수 있어 편리해지고, 외부 인터페이스에 대한 문서화가 쉬워짐.

3. 내부 인터페이스를 숨기려면 protected( 모방 가능 ) , private ( 지원 ) 필드를 사용하면 된다.

protected는 _ 로 시작하며, 정의된 클래스와 자손 클래스에서 접근 가능하다.
private는 # 으로 시작하며, 정의된 클래스 에서만 접근 가능하다.

많다 많아!

class - static method, property

Creative_Lee — Wed, 22 Jun 2022 14:27:38 +0900

1. static method

prototype 프로퍼티가 아닌

클래스 함수 자체에 메서드를 설정할 수 있습니다.

이런 메서드를 static method ( 정적 메서드 ) 라고 부릅니다.

class Animal {
  static staticMethod(){
    console.log(this === Animal)
  }
}

class Animal {}
Animal.staticMethod = function(){
  console.log(this === Animal)
}


Animal.staticMethod() // true

class 내에서 static 메소드를 선언 하는 것은

메서드를 프로퍼티 형태로 직접 할당하는 것과 같습니다.

static 메소드는 호출시 class명.method( ) 의 형태로 사용하게 되며,

이때 static 메소드의 this는 'class' 가 됩니다.

2. static method 의 쓰임새

static 메소드는 각각의 인스턴스 객체가 아닌,

클래스 전체에 필요한 기능을 구현하고자 할때 사용할 수 있습니다.

class Summoner {
  constructor({name, power = 10}){
    this.name = name;    
    this.power = power;    
  }

  static createDummySummoner(){
    return new Summoner({name: 'dummy', power: 0})
  }
}

let summoner = new Summoner({name : 'Bob'})
let dummy = Summoner.createDummySummoner()

console.log(summoner) // {name: 'Bob', power: 10}
console.log(dummy) // {name: 'dummy', power: 0}

위 코드에선

클래스에 static 메서드 createDummySummoner를 선언했습니다.

더미 소환사가 필요할 때마다 Summoner.createDummySummoner( ) 를 호출하면 됩니다.

위 static 메서드는 전체 클래스의 메서드입니다.

3. static property

정적 프로퍼티도 만들 수 있습니다.

class Summoner {
  static dummyName = 'dummy';
]

Summoner.dummyName = 'dummy'

정적 메소드와 동일하게

class 내에서 static property를 선언 하는 것은

프로퍼티를 직접 할당하는 것과 같습니다.

4. static property 의 쓰임새

class Summoner {
  constructor({name, power = 10}){
    this.name = name;    
    this.power = power;    
  }

  static dummyName = 'dummy';

  static createDummySummoner(){
    return new Summoner({name: this.dummyName , power: 0})
  }

  static setDummyName(name){
    this.dummyName = name
  }

}

let summoner = new Summoner({name : 'Bob'})
let dummy = Summoner.createDummySummoner()

console.log(summoner) // {name: 'Bob', power: 10}
console.log(dummy) // {name: 'dummy', power: 0}

Summoner.setDummyName('poop')
let dummy2 = Summoner.createDummySummoner()

console.log(dummy2); // {name: 'poop', power: 0}

console.log(summoner.dummyName) // undefined
console.log(Summoner.dummyName) // dummy

정적 프로퍼티는 데이터를 클래스 수준에 저장하고 싶을 때 사용합니다.

위 코드의 맨 아랫줄과 같이 정적 프로퍼티는 인스턴스가 아닌 클래스에 저장됩니다.

5. static 의 상속

정적 프로퍼티와 메소드는 상속됩니다.

class Summoner {
  constructor({name, power = 10}){
    this.name = name;    
    this.power = power;    
  }

  static dummyName = 'dummy';

  static createDummySummoner(){
    return new Summoner({name: this.dummyName , power: 0})
  }

  static setDummyName(name){
    this.dummyName = name
  }
}

class SubSummoner extends Summoner{}

let dummy = SubSummoner.createDummySummoner()
console.log(dummy) // {name: 'dummy', power: 0}
console.log(SubSummoner.dummyName) // dummy

위 코드를 보면

부모 클래스 Summoner에 선언된 static 메소드와 프로퍼티가

자식 클래스 SubSumonner에서 사용 가능한 것을 알 수 있습니다.

위와 같은 동작이 가능한 이유는 prototype 상속 때문입니다.

extends 키워드로 상속을 사용할 때 다음과 같은 일이 일어납니다.

1. 자식 클래스는 [[Prototype]] 을 통해 부모클래스를 상속받습니다.

2. 자식 클래스.prototype 은 [[Prototype]] 을 통해 부모클래스.prototype을 상속받습니다.

1번을 통해

자식 클래스에서

부모클래스에 저장된 static 메소드와 프로퍼티를 상속받고 사용할 수 있고,

2번을 통해

자식 클래스의 인스턴스에서

자식 클래스와 부모 클래스의 메소드를 사용할 수 있습니다.

요약

1. static method는 클래스의 인스턴스가 아닌 클래스 전체에 필요한 기능을 만들 떄 사용하다.

2. static property는 데이터를 클래스 수준에 저장하고 싶을 때 사용한다.

3. 1,2번은 기술적으로 클래스 자체에 직접 할당하는 것과 동일하다.

4. static은 자식 클래스의 [[ Prototype ]] 을 통해 부모 클래스에게 상속 받아 사용할 수 있다.

gogo

class - class extends (상속)

Creative_Lee — Tue, 21 Jun 2022 17:38:04 +0900

1. 클래스 상속 ( extends )

클래스 상속을 사용하면 클래스를 다른 클래스로 확장할 수 있습니다.

extends 키워드로 상속을 구현할 수 있습니다.

class Animal {
  constructor(name){
    this.name = name;
    this.speed = 0;
  }

  run(speed){
    this.speed = speed;
    console.log(`${this.name} 달리는 중 속도 : ${this.speed}`)
  }  
}

class Human extends Animal {
  think(){
    console.log(`${this.name} 생각하는 중`)
  }
}

let human = new Human('Bob')

human.run(100) // Bob 달리는 중 속도 : 100
human.think() // Bob 생각하는 중


console.log(human.__proto__ === Human.prototype) // true
console.log(Human.prototype.__proto__ === Animal.prototype) // true

human 인스턴스는 Human.prototype을 상속 받았고,

Human.prototype은 Animal prototype를 상속 받았습니다.

위와 같은 prototype chain 덕분에

Human class 로 생성된 인스턴스에서

Animal class에 정의된 메소드를 사용할 수 있습니다.

extends 뒤에는 표현식이 올 수도 있습니다.

function func(msg) {
  return class {
    sayHi() { 
      console.log(msg)
    }
  }
}

class User extends func("Hello") {}

new User().sayHi(); // Hello

위와 같은 방법은 조건에 따라 다른 class를 상속 받게 할때 유용합니다.

2. super를 통한 메서드 오버라이딩

상속을 구현 함에 있어서 특별한 행동을 하지 않으면,

부모 class의 메소드를 그대로 상속 받습니다.

만약 부모 class의 메소드와 같은 이름의 메서드를 정의하면, 자식 class의 메소드가 사용됩니다.

또한 부모 메소드의 일부 기능만 수정하고 싶을땐

super 키워드를 사용하면 됩니다.

super.method( ) 는 부모class에 정의 된 메서드, method 를 호출합니다.

class Animal {
  constructor(name){
    this.name = name;
    this.speed = 0;
  }

  run(speed){
    this.speed = speed;
    console.log(`${this.name} 달리는 중 속도 : ${this.speed}`)
  }  
}

class Human extends Animal {
  think(){
    console.log('생각도 하는 중')
  }

  run(){
    super.run()
    this.think()
  }
}

let human = new Human('Bob')

human.run()
// Bob 달리는 중 속도 : undefined
// 생각도 하는 중

화살표 함수에는 super 가 없습니다.

class Human extends Animal {
  run(speed){
    setTimeout(() => super.run(speed), 1000)
  }
}

let human = new Human('Bob')

human.run(10) // Bob 달리는 중 속도 : 10

화살표 함수에서 super 키워드를 사용하면 외부 함수에서 super 를 가져옵니다.

위 코드의 동작은 run( ) 메소드의 컨텍스트에서 사용한 super와 같습니다.

class Human extends Animal {
  run(speed){
    setTimeout(function(){super.run(speed)}, 1000)
  }
}

let human = new Human('Bob')

human.run(10) // error

일반 함수를 사용하면 error가 발생합니다.

3. super를 통한 생성자 오버라이딩

부모 클래스를 상속 받을 때 자식 클래스에서 constructor 생성자를 명시하지 않으면,

다음과 같이 비어있는 constructor가 생성됩니다.

class Human extends Animal {
  // 보이지 않지만 생성됩니다.
  constructor(...args){
    super(...args);
  }
}

super( ... ) 는 자식 클래스의 constructor 내에서만 사용할 수 있는데,

부모 클래스의 constructor를 호출합니다.

위와 같은 동작 방식 덕분에

자식 생성자를 명시하지 않으면 모든 인수를 자동으로 부모 생성자에게 전달합니다.

이를 바탕으로 생성자를 오버라이딩 할 수 있습니다.

class Animal {
  constructor(name){
    this.name = name;
    this.speed = 0;
  }
}

class Human extends Animal { 
  constructor(name, sex){
    super(name);
    this.sex = sex 
  }
}

let human = new Human('Bob', 'male')

console.log(human) // Human {name: 'Bob', speed: 0, sex: 'male'}

super 키워드를 사용하지 않고 오버라이딩 하면 어떻게 될까요 ?

class Human extends Animal { 
  constructor(name, sex){
    this.name = name;
    this.sex = sex 
  }
} 

let human = new Human('Bob', 'male')

// Uncaught ReferenceError: 
// Must call super constructor in derived class before accessing 'this'  
// or returning from derived constructor

"상속 클래스의 생성자에서 this를 사용하기 전에 반드시 super( ) 를 호출해야 합니다."

라는 에러가 발생합니다.

에러의 발생 원인은 다음과 같은 자바스크립트의 동작방식 때문입니다.

1. 자바스크립트는 상속 클래스의 생성자 함수와 일반 클래스의 생성자 함수를 구분합니다.

2. 일반 클래스가 new와 함께 실행되면 빈 객체를 만들고 this에 빈 객체를 할당합니다.

이후 constructor에 정의한 프로퍼티를 추가하고 리턴 합니다.

3. 상속 클래스의 동작에선 2번과 같은 동작이 일어나지 않습니다.

상속 클래스의 constructor는 2번과 같은 동작을 부모 클래스에 위임합니다

정리하면, 상속 클래스의 this가 될 객체가 만들어지지 않아서 발생하는 에러입니다.

이러한 이유로

상속 클래스의 constructor 에서 super( ) 를 통해

부모 클래스의 constructor 를 실행해 주어야 합니다.

4. 클래스 필드 오버라이딩

코드부터 보겠습니다.

class Animal {
  name = 'Animal'
  constructor(){
    console.log(this.name)
  }
}

class Human extends Animal { 
  name = 'Human'
} 

let animal = new Animal() // Animal
let human = new Human() // Animal

자식 클래스 Human에서 constructor를 명시 하지 않았으므로

부모 클래스 Animal의 constructor가 호출됩니다.

자식 클래스에서 클래스 필드를 오버라이딩 했음에도 log에는 둘 다 Animal이 출력됐습니다.

부모 생성자는 항상 부모 클래스 필드 값을 사용하기 때문입니다.

왜 그럴까요 ?

클래스 필드의 초기화 규칙이 정해져 있기 때문입니다.

자바스크립트 클래스 필드의 초기화 순서는 다음과 같이 규칙에 따라 달라집니다.

아무것도 상속 받지 않는 베이스 클래스는 constructor 실행 이전에 초기화 됩니다.
부모 클래스가 존재하는 경우, super( ) 실행 직후에 초기화 됩니다.

위 규칙에 따라

부모 클래스 Animal은 생성자 함수 실행 이전에 name = 'Animal' 클래스 필드가 초기화 됩니다.

자식 클래스 Human은 부모 클래스 Animal의 생성자 함수 실행 직후에 name = 'Human' 클래스 필드가 초기화 됩니다.

즉 자식 클래스의 클래스 필드에 name 은 아직 존재 하지 않기 때문에, ( 초기화 x )

부모 클래스의 클래스 필드에 이미 존재하는 name이 사용되는 것입니다. ( 초기화 o )

이러한 문제는 오버라이딩한 클래스 필드를 부모 생성자에서 사용할 때만 발생합니다.

위와 같은 문제들은 클래스 필드 대신 메서드를 사용하거나 getter, setter를 통해 해결할 수 있습니다.

OOP의 세계로