3월 회고, 코드 리뷰 스터디와 멘탈 케어의 흔적들
어느덧 3월이 끝나간다.
오미크론 확진으로 3월 첫 주는 회복에만 힘쓰느라 일주일을 약에 취해 살았다.. (누가 경미한 감기 증세라 했나요.. 목에 칼춤을 추는 기분이였다..!) 그렇게 일상에 복귀한 지 보름 째.
그동안 커밋 잔디를 심지못해 부채감을 느끼며 VanillaJS 코드 리뷰 스터디와 Next.js 프로젝트 등 계획했던 일정들이 부메랑처럼 돌아와 매우 바쁜 일상을 보내게 되었다. 맘 같아서는 일주일에 한 번씩 회고록을 작성하려 했으나.. 😂 각 잡고 포스팅을 쓸 여유가 나지 않아 개인 notion에만 조금씩 정리했던 내용들과 개인적인 멘탈이 흔들렸을 때 극복했던 방법들을 톺아보고자 한다.
🖍 3월에 진행한 것들
1. 출근 전 10분 TIL 저널 작성
2. React 공식문서 정독
3. VanillaJS 클린 코드 리뷰 스터디 활동
- Github, 디스코드, 개더타운 활용
- OOP 구현 (함수형 컴포넌트 vs 클래스형 컴포넌트)
- MV* 패턴과 flux 패턴 정리
- 함수형 프로그래밍 개념 정리
- 1급 객체와 고차함수 개념 정리
- 코딩 컨벤션 정리
- TDD cypress 문법 개선 항목 공유
4. 격리 후유증 극복을 위한 주 3회 러닝 30분
5. [코드 스피츠 ES6+ 함수와 OOP] 재수강
6. Next.js 트위터 클론코딩 프로젝트 FE 완성 (40%)
7. 기술 서적 읽기 : 클린 코드(100%) , You Don't Know JS(60%), 딥다이브 정독(30%), 프로그래밍은 상상이다 (30%)
8. 효율적 TDD를 위한 고민, Cypress DSL 적용
9. 설계 산출물을 위한 Figma 입문
10. [테오의 프론트엔드] 디스코드 참여
💭 3월에 느낀 것들
2. React 공식문서 정독
리액트는 요즘의 추세가 hook을 사용하기 위해 function구문을 애용하는 것일 뿐 패러다임에 집착할 필요는 없다.
결론은,, 적재적소에 클래스와 함수를 적용하는 것이 가장 좋다.. 특정 패러다임에 매몰되지 말자
3. VanillaJS 클린 코드 리뷰 스터디 활동
1~8주차동안 매 주 새로운 미니 프로젝트 일정이었으나 팀원들과 논의하던 중 시간에 치여 코드를 작성하고 있지 않나 돌아보게 되었다.
인풋(지식)과 아웃풋(코딩)의 적절한 밸런스가 중요한데, 아웃풋 일정에 급급해 인풋 적용이 부족했던 것 같다.
정말 유의미한 코드 리뷰와 리팩토링을 진행했는가에 대해서는 계속 의문이였고 스터디원 분들도 공감하는 부분이였다.
매번 30개 가량 달려있는 PR comment들을 Todo-list 하나하나를 지워가듯이 수정해나가는 게 정말 의미가 있나?
내 코드에서 이게 정말 필요한 수정일까? 등
고민하는 시간이 부족하다고 느껴졌다.
따라서 4주차에 이른 지금, 여태 작성한 코드를 기반으로 리팩터링에 초점을 맞춰 학습하도록 일정을 변경했다.
- 매 주 코드리뷰 전, 계획한 분량의 [리팩터링 2판]을 읽는다
- 각자 읽으면서 적용해보고싶었던 부분이 뭐였는지 중간 공유
- 정식 세션에서 디스코드 스크린 쉐어를 통해 각자의 리팩토링한 코드를 설명 (*단 한줄도 무의미한 코드가 없게끔 한다)
새로운 일정이 기대되기도 하고, 이로서 얻어지는 아웃풋이 굉장히 궁금하다! 🎯
vanillaJS class 구조에서의 상태 관리는 새로운 인스턴스 생성보다는 재렌더링이 알맞지 않을까?
어떻게 효율적으로 재렌더링을 구현할 수 있을까? 반복적 객체 재생성이 불가피한걸까?
불필요한 메모리 할당을 줄이고 싶은데, 리액트처럼 부분 재렌더링 하는 방법이 어떤 것이 있을까?
cypress 테스트 코드 작성도 유지보수 생산성을 위해 실제 코드만큼이나 시간을 들여야 한다.
하지만 완벽한 커버리지에 집착하면 재사용성이 떨어진다. 이 중간점을 잘 조절해봐야겠다.
6. Next.js 트위터 클린코딩 프로젝트 진행 (40%)
Next.js 프로젝트를 진행하면서 함수형 컴포넌트를 추구하는 리액트와 vanillaJS와의 구조적 차이점에 자꾸 의문점을 가졌던 것 같다.
클래스와 함수의 차이가 궁금하다보니 모던JS, MDN, You Don't Know JS(특히 좋았다!)에서 필요한 부분을 파고들었다.
원론적인 개념을 이해하면 모든 것이 자연스럽게 받아들여진다. 외워야 할 부분과 외우지 말아야 할 부분을 구분하자.
🕵️♀️ VanillaJS 코드 리뷰 스터디 회고
작성한 코드를 Pull Request하면 merge하기 전 코멘트 리뷰를 진행한다. 이 과정을 통해 매 주 새로운 부분들을 깨닫는다.
서로 질문하면서 더 좋은 방안을 떠올리기도 하고, 어떤 코드가 조금 더 성능적으로 효율적인 코드인지, 조금 더 클린한지, 조금 더 유지보수가 용이한지 느끼게 된다. 다른 분들의 코드를 보면서 같은 주제를 기반으로 한 VanillaJS 코드여도 그 자유도에 따라 형태와 성능이 천차만별로 달라진다는 것을 알게 된다.
리뷰어님으로부터 변수명이 명시적이고 코드가 읽기 편하다는 칭찬을 들었는데, 매 주 미션을 진행하면서 새로운 패러다임을 적용하는 데 수동적으로 했기 때문에 읽기 좋은 것이 아닐까 하는 생각이 들었다.
지적해주신 대로 일주일 내내 MV* 패턴과 도메인, UI 분리에 대해 고민했지만 실제 코드에 반영하기가 여간 쉽지 않았다. 그게 오롯이 코드에 나타났나보다 😰 세션을 통해 서로의 구조화 과정을 설명해보면서 내가 발전하지 않는 기존 코드 구조에 고여있었던 것은 아닌지 생각해보게 되었다.
반복적으로 instance를 생성해야 하는 객체는 클래스로 생성하고, 나머지는 함수로 바꾸는 리팩토링을 진행하려 했으나 OOP 개념이 부족한 탓일까.. 구현 전 설계 단계에서 도메인 영역과 UI 영역을 완벽하게 분리하고 MV*를 고려한 디렉토리 구조를 짜는 것이 너무 어렵다. 어떤 이유일까?
주 1회 세션을 진행하며 느낀 점
모던 JS에서의 클래스는 함수의 method.prototype.func 형태를 간단하게 나타낸것일 뿐 동일하다. 클래스는 이를 간단하게 나타낸 구조형태라고 생각.. 하지만 constructor나 불필요한 메서드를 모두 적어줘야하는 단점이 있다.
클래스형 컴포넌트를 작성하면 extends를 통한 부모 객체 메소드 접근이 매우 유용하다.
리액트는 요즘의 추세가 hook을 사용하기 위해 function구문을 애용하는 것일 뿐 패러다임에 집착할 필요는 없다.결론은, 적재적소에 클래스와 함수를 적용하는 것이 가장 좋다! 특정 패러다임에 매몰되지 말자. (개인적으로는 절차지향적 언어인 JS에서 클래스를 사용하는 건 다른 클래스 지향적 언어들을 쓰던 사람들의 마지막 집착?이 아닐까..싶었다ㅎㅎ)
구현은 항상 기능 구현에 초점을 맞춰 시작한다. 모듈화는 리팩토링 시 고려한다. 처음부터 완벽한 코드는 없다. TDD를 활용해 점진적인 개선에 집중하자.
방향성 정립
클린코드의 목적은 결국 유지보수이다.
도메인이 복잡한 미션은 View(그리는 부분)와 Domain(연산하는 부분) 의 변화율이 다르기 때문에 정확한 구분이 필요하다.
내가 계속 틀리고, 두려워하는 부분에 집중하고 익숙해지자.
하루종일 모든 시간을 할애하지 말고 시간을 정해서 집중적으로 몰입하자. 코딩도 공부도 데드라인을 정해 하는 연습
함께 자라기 책에 나온 그레이 존(Grey-zone)을 항상 생각하자. 알 듯 말듯한 개념을 파고들어 직접 활용해보는 경험은 기억에 오래 남는다. 개발 지식을 쌓는 일은 쉽게 느껴져선 안된다. 내 견문에서 조금씩 어려운 부분들을 적용하고 개념을 확장시켜나가야 의미있게 점진적으로 발전할 수 있다.
🚀 4월에 해보고싶은 것들
Next.js 트위터 클론코딩 프로젝트 BE 파트 완성
디자인 시스템에 대한 이해와 Storybook 입문
functional CSS의 이해
구글 스프린트 협업 진행
리팩터링-2판, You Don't Know JS, 딥다이브, 프로그래밍은 상상이다 완독
React boilerplate 만들기
기존에 Cypress로 구현했던 프로젝트 Jest 적용
React-query 리팩토링
♻️ 인사이드 아웃 방식 학습법
가끔 하루종일 책상에 앉아 있었는데도 온전히 집중이 안되고 돌이켜 생각해보면 어느 하나 몰입한 순간이 없는 날이 있다 😢 공부를 진행하면서 때때로 지금 양질의 공부를 하고 있는가? 의문이 들고는 한다. 그 전에는 기능 구현이 기대되고 재밌었는데, 갑자기 부담감으로 크게 다가온다던가.. 도메인과 UI, MV* 패턴.. 무언가 정답이 있을것만 같은 이 형식을 자꾸 완벽하게 이해하려고 하다 보니까 내가 구현해온 것이 오답이라는 생각에 자괴감이 들었던 것 같다.
사실 이번 달은 코드를 짜면서 나름 클린 코드 인사이트를 적용하고, 가독성에 신경을 많이 썼기에 자신감이 있었다. 다른 분들 코드를 읽으면서 느낀 것은 그저 기본에 충실할 것. 코드는 각자 나름의 스타일이 있고 정답은 없기 때문에 흔들리지 않고 나만의 페이스로 가야 한다는 것이다.
...아웃사이드 인 방식으로 학습하지 말아야 합니다. 이는 주변에서 TDD가 좋다, OOP가 좋다, 디자인 패턴 알아야 한다, 누구 누구는 스터디를 한다더라하면서 남들에 의해 공부를 하게 되는 것을 말합니다. 이것은 자칫하면 번아웃으로 가는 지름길이 될 수 있습니다. 왜냐하면, 현재 자기 자신보다 잘하는 사람들과 비교하게 되어 금방 지칠 수 있기 때문이죠.
따라서, 반란군 기질을 가짐으로써 남들의 의견을 어느 정도 무시할 줄 알아야 합니다. 즉, 본인만의 기준을 세우고 묵묵하게 학습을 하라는 것이죠. 그리고 이것을 인사이드 아웃 방식이라고 합니다. 인사이드 아웃 방식을 잘하기 위해서는 개인 회고나 학습 로그를 작성한 뒤, 한 가지에 일에 집중하는 습관을 만들어서 작은 성공의 맛을 보아야 합니다. 또한, 한 번에 여러 가지를 하는 것이 아니라 한 가지 일에 집중을 하는 것이 중요합니다.
- 우아한 테크코스 [포비]
🗞 아티클에서 얻은 멘탈 솔루션
실제 개발 쪽에서 일하시는 분들 중 **‘임포스터 신드롬(imposter syndrome)’**이라는 가면 증후군(스스로를 과소평가하는 경향)이 있는데, 저도 초반에 많이 겪었던 부분이에요. 특히 엔지니어 직군 중에서도 여성분들이 더 많이 겪는다고 하더라고요. 지속적으로 성장하기 위해서 마인드 컨트롤이 정말 중요하다고 생각합니다.
- 원티드+ 아티클 중
나는 개인적으로 조금 필요 이상으로 나에게 혹독한 면이 있다. 세바시 강연에서 '임포스터 증후군'이라는 가면 증후군을 알게 된 적이 있다. 증상이 나와 꽤나 비슷해서 관심있게 강연을 들었는데, 이러한 가면 증후군을 극복하기 위해선 소속감을 되찾기, 자신의 성취를 시각적으로 정리하기(포스팅), 목표를 위해 끝없이 도전하고 노력하기 등이 해결법으로 조언된다고 한다.
특히 겸손하되 당당하고, 비교 대상을 ‘나’에 둘 것. 공부를 하면서 겸손함과 자만함 두 사이에서 균형을 맞추는 게 너무 어렵다고 생각한다. 스스로 누구와 비교하는가에 따라 엄청 자신감이 생기기도 하고, 떨어지기도 한다. 특히 개발 쪽은 실력/나이/연차에 비례하지 않기 때문에, 주위의 영향을 받기 쉽다.
나보다 좋은 실력을 가진 분을 볼 때는 ‘좌절하지 말고 그냥 저분처럼 되어야겠다’고 생각하자. 다른 사람으로 인해 내가 스트레스 받으려 하기보다는 어떤 점을 배우고, 공유해 줄 수 있는지를 생각하자. 이 둘 사이에 균형을 잘 맞추면서 나의 실력을 쌓는 방향으로 의식적으로 마인드 셋을 정립해 보는 것이 중요하다.
결국, 스스로의 기준을 세워서 남들과 비교하지 않고 꾸준히 자기가 할 일을 지속하는 사람이 프로그래밍 뿐만 아니라 인생을 살아가는 데 있어서 좋은 태도라고 생각한다.
마지막으로 어제 FE 단톡방에서 받은 구문 중 기억에 남는 구문을 적으며 포스팅을 마무리해본다 ✍🏻 4월도 화이팅..!
작성한 결과물은 어떠한 방식으로는 꼭 외부에 주위에 공유를 하세요. 남들에게 보여주겠다는 생각으로 하셔야 퀄리티를 적당히 타협하지 않는 습관이 만들어집니다!
- teo