멤버십 2주차를 마쳤다.
배우고 느낀 것들
방법을 바꿔보기
2주차는 방법을 바꿔보는 한 주였던것 같다.
기존 클래스 위주로 관리하던 프로젝트를 개편하며 클래스를 최소화하고, 함수형으로 변경하되 함수별 역할은 기존보다 명확하게 하려고 노력했다.
객체지향에서 함수형으로 완전히 새로운 접근을 시도했기에 새로운 지식들을 너무나도 많이 학습할 수 있었다.
A라는 방법으로 해결하려고 할때는 필요없던 지식들이 B라는 방법을 사용할때는 필요하다.
덕분에 자연스럽게 새로운 지식을 익히고, 이를 활용해서 문제를 해결할 수 있었다.
그리고 기존의 방법에 고착되어, 더이상 발전이 없던 부분들에 대해 새로운 방법을 도입하며, 기존의 방법을 통해 진행했을때보다 더 좋은 퀄리티의 코드를 작성할 수 있었다.
라이브러리의 등장 배경 이해
라이브러리가 왜 나왔는지, 이해할 수 있었다. 그냥 코드를 작성하다보니 중구난방이었고, 역할과 책임이 명확하지 않은 문제들이 너무나도 많았다.
또 코드분리를 하다보니 겪는여러가지 문제들도 생겼는데, 이걸 하나씩 하나씩 개선하다보니 어느새 내가 아는 그 라이브러리와 굉장히 비슷하게 되었다. 물론 내가 무의식적으로, 혹은 아는게 그것밖에 없어서 그럴수도 있다.
내가 겪은 문제들을 해결하기 위해서, 라이브러리가 등장했음을, 그리고 왜 우리가 그런 라이브러리를 사용하는지를 크게 느낄 수 있었던 한주였다.
블로그 글보단 공식문서와 코드를 읽어서 제대로 학습하기
이전주의 블로킹, 논블로킹을 이해하기위해 정말 많은 시간을 투자했다.
아래의 글을 쓰는데 정말 과장없이 20시간은 투자했다.
항상 공식문서를 읽어야한다는 생각은 하고 있었지만, 실천에 옮기기가 매우 힘들었다.
검색하면 항상 먼저 나오는게 블로그 글이었고, 요즘은 chatGPT도 있기때문에 더욱 읽지 않게 됐었다.
그런데 블로킹-논블로킹은 인터넷에 잘못된 정보가 너무 많았고, 블로그마다 말이 달랐다.
심지어 eventEmitter가 동기인지 비동기인지를 물어봤을 때, chatGPT와 Bard의 말이 달랐다.
이때 가장 큰 도움이 된 것이 Nodejs의 공식문서와 Nodejs의 깃허브 코드였다.
Nodejs의 공식문서는 참 잘되어있다. 내가 본 공식문서 중에 가장 잘 설명되어있다.
하지만 그럼에도 불구하고, 분명 설명이 부족하다고 느끼는 부분들도 많았다.
그래서 정말 헤매고 있었는데, 마스터분께서 nodejs의 코드를 한번 확인해 보는게 좋다고 하셔서 실행에 옮겻다.
NodeJS의 코드? 뭔가 무의식적으로 공포감을 느껴서 읽을 엄두도 못냈었는데, 생각보다 읽을만 했고, 잘 이해할 수 있었다. 지금까지 프로젝트를 진행하며 수행한 코드리뷰, 그리고 부스트캠프를 진행하며 피어들의 코드를 읽는 연습을 한 덕분이다.
개념과 코드 결합하기
이벤트 버블링? 이벤트위임? DOM렌더링?
이런 키워드들은 개념상으로는 알고 있는 것이었지만, 지금까지 한번도 코드로 작성해본 적이 없었다.
그래서 자꾸자꾸 까먹었고, 일정주기로 복습할 필요성을 느끼고 있었다.
그런데 이번주에 이 개념을 활용해 문제를 해결해나가면서, 왜 필요한지를 절실히 느꼈다.
지금와서 되돌아보니 매번 학습만하고 경험은 해본적이 한번도 없었다.
그래서 자꾸만 휘발되고, 온전한 나의 지식이 될 수 없었구나 느꼈다.
학습, 경험, 정리가 이뤄져야 나의 지식이 된다.
학습에 대한 정리보다는 경험에 대한 정리를 해보자.
일단 시작하기
객체지향을 겨우 이해하고 있던 나는 함수형 프로그래밍이 뭔지 정확하게 이해하지 못했다.
클로저가 뭔지.. 순수함수가 뭔지.. 개념은 알기는하는데 코드로 작성하기가 매우 어려웠다. 그래서 뭔가 막연한 공포감을 갖고 있었던 것 같다.
하지만 이번주에 함수형 프로그래밍을 과감하게 도입하면서, 이론이 아니라 경험으로 이를 학습하고, 덕분에 이것이 무엇인지 조금이나마 이해할 수 있게 되었다.
이건 객체지향 프로그래밍을 처음 배울때도 마찬가지였다. SOLID가 어쩌고.. 다형성과 상속이 어쩌고...
이런 개념을 읽고, 쓰기만 하니 객체지향 프로그래밍을 적용한 프로젝트 코드를 쓸때는 뭘 어떻게 해야하는지 몰라서 도저히 시작조차 할 수가 없었다.
하지만, 일단 코드를 작성하기 시작하자, 이건 어떻게 처리하지? 저건 어떻게 구현하지? 이건 좀 많이 구린데? 와 같은 여러 고민들이 생겼고 고민들을 해결하는 과정에서 자연스럽게 객체지향이 무엇인지, 어떻게 해야 좋은 구조를 짤 수 있는지 조금이나마 이해할 수 있었다.
이번에도 마찬가지로 순수함수로 작성하려고 최대한 노력하고, 클로저를 활용해서 custom Hook(렌더링에 관여하지는 않지만...비슷한 문법으로 사용해서 이렇게 이름붙였다.)들을 만들고, 함수 체이닝을 하며 약간의 뽕맛을 느껴보면서 완벽하지는 않지만 조금이나마 함수형프로그래밍을 이해할 수 있었다.
심지어 이번에는 주변의 여러 캠퍼들, 마스터분들이 있었기에 고민들을 나누며, 더욱더 잘 개선해나갈 수 있었다고 생각한다.
무엇보다 클로저를 활용하는 방법을 제대로 알지 못했는데, 이 부분은 확실하게 학습할 수 있었다.
지금와서 되돌아보니 이걸 두렵다는 이유로 망설이고, 도전해보지 않았더라면 아무것도 발전을 이룰 수 없었을거라는 생각이 들었다.
일단 시작하고, 개선해나가다보면 지식은 어느새 나의 것이 될 것이라는 것을 느낀 한주였다.
그러니 두려워말고 일단 시작하자.
운동하러 가는것 보다는 밖으로 나가는 것이 쉽고, 밖으로 나가는 것보다는 신발을 신는게 쉽다.
신발을 신으려먼 일단 일어나야한다. 일단 일어나자.
(운동이라곤 안가고, 앉아서 글을쓰며)
나는 프론트엔드를 재밌어하는구나
이전주까지만 해도 프론트엔드를 할지, 백엔드를 할지 정말정말 고민했다.
nodejs로 서버를 경험해보고 react나 next도 경험해봤지만, 둘다 재미가 있어서 쉽게 결정하지 못하고 있었다.
그런데 이번주 미션을 진행하면서 대부분의 고민들을 프론트엔드 측면에서 하게되고, 백엔드 코드는 정말 최소한의 정도만 작성하게됐다. 의식적으로 백엔드를 개선하려고 했지만, 뭔가 자꾸 손이 프론트엔드 코드를 만지게 되더라.
무엇보다 프론트엔드 코드를 쓸때 가장 즐거움을 느꼈던 것 같다.
그래서 더 즐거운 학습을 해보기로 결정했다.
아쉬운점, 개선할 점
저번주에 클라이언트측 테스트코드가 없어서, 이번주에 그 방법을 조사하고 실제 테스트 코드를 하나 적어보긴 했지만....
이번 주차에는 시간이 없어서 테스트코드를 아예 적지 못했다.
구조 개선을 열심히 하긴했지만,,, 핑계에 불과할지도..
열심히 모듈화 했으니 이를 바탕으로 차주부터는 테스트코드를 한줄이라도 적자..
3주차도 화이팅!