지킬로 만든 깃허브 블로그의 테마가 마음에 안 들기도 하고 매번 깃허브에 푸쉬하기도 귀찮고 해서, 다시 벨로그로 돌아갔었다. 근데 벨로그를 보니 임시저장이나 모바일 작성 이미지 업로드 등 편리한 면이 아주 많은 건 좋은데, 또 디자인이 마음에 안들어서 이런 저런 테마를 보다가 갯츠비의 이 라벤더 테마를 보게되어 다시 깃허브로 돌아왔다. 최근 트렌디한 디자인은 갯츠비로 만든 프로젝트에 많은 것 같다 :)

입사 후 블로그를 근 3달 간 못 쓰다가, 코드숨 교육에 참여하게 되면서 다시 시작하게 되었다. (코드숨 교육과정에선 주간회고가 필수이다) 이전에 쓰던 깃헙 블로그의 콘텐츠들을 옮겨오는 건 천천히 하는 걸로 하고, 우선 아주 잠깐 머물렀던 벨로그에 작성했던 코드숨 주간회고들을 먼저 옮겨왔다.

1주차

주간회고의 양식은 코드숨 아샬님의 https://dal-lab.com/2019/09/18/today-i-learned/ 를 참고했습니다.

Facts (사실, 객관)

• 걱정 반 설렘 반으로 시작한 코드숨 리액트 과정의 1주차가 마무리 되었다.
• 2개의 과제 중 첫 번째 과제는 완전히 완료하였고, 두 번째 과제는 제출 후 코드리뷰까지는 받았으나 아직 피드백을 반영하지는 못했다. 결론은 완전히 과제를 마무리하지는 못함.
• jsx가 리액트 외에서도 사용할 수 있다는 것을 알았다.
• jsx의 원리에 대해 배웠다.

Feelings (느낌, 주관)

• 인상적이었다
  • No 회고, No merge : 회고 문화가 개발 세계에 있어 언제나 핫한 주제인 것은 알지만, 회고를 작성하지 않으면 과제를 머지해주지 않는 (= 최종 완료가 되지 않는) 곳은 처음이었다.
  • 짤방의 활용 : 얼마 전 되게 유명한 시니어 개발자분이 회사에 강연을 해주러 오셨었다. 그 때 해주신 말씀 중 코드리뷰는 즐거워야 한다가 있었다…(맞나?) 내게 리뷰를 해주신 트레이너 분이 짤을 적극 활용하시는데, 저 말이 생각났다. 원래 짤 활용을 굉장히 좋아하는 편이지만 새 맥북이라 짤이 하나도 없어 쓰지 않았는데, 2주차 때부터는 나도 적극적으로 써야겠다.
• 신기했다
  • 사실 jsx 문법에 대해 그렇게 깊이 탐구하고 사용하지 않고 있었다. 그냥 pug같은 템플릿 엔진 뭐 그런 거. 그런 거랑 비슷한 결이 아닐까 하는 생각만 얕게 있었을 뿐이다. 그랬던 jsx에 대해 1주차를 진행하면서 자세히 알아볼 수 있어서 신기하고 재미있었다.
  • jsx 얘기와 결을 같이 하는데, 1주차 과제를 진행하다보니 아직 리액트를 사용하는 것은 아니지만 리액트의 함수형 컴포넌트의 기본 원리(?)에 대해 바닐라로 짚고 시작하는 듯한 느낌을 받았다.

Findings (배운 점)

• jsx의 재발견(?)
• 최대한 상태 없이 함수의 매개변수 만으로 업데이트하기
• 점진적 개선
  • 과제 안내에 코드리뷰 후 머지가 되면 다음 과제를 수행하면 된다고 해서, 두 번째 과제 진행에 있어 안일했다 ㅠㅠ 상관없이 진행해도 된다고 하니 교육 목표에 맞게 작게 조금씩 계속 리뷰-개선 핑퐁이 오갈 수 있도록 2주차 부터는 신경써야겠다.

2주차

Facts (사실, 객관)

• 지난주 첫 코드숨 과정을 경험해보고 다짐했던 다음의 내용들을 실천했다
  • 미완성이어도 좋으니 작게라도 pr을 자주, 일찍 보내기 : 비록 미완성이나 작게는 아니었지만 과제 두 개를 빠르게 pr을 보내 리뷰 핑퐁을 위한 시간을 확보할 수 있었다.
  • 그렇게 해서 트레이너분과 리뷰 핑퐁을 최대한 많이 주고받기 : 리뷰 핑퐁을 통해 일단 완성한 과제에서 점진적 개선을 진행할 수 있었다.
• 2주차 과제를 모두 마쳤다 (휴…).
• 개인적으로 가지고 있던 코딩 습관을 되돌아보게 되었다.
• 과제가 요구사항이 간단하고 규모가 작다 생각하고 네이밍 등에 있어서 상세하게 작성하지 않는 등 놓치는 부분들이 많았다.

Feelings (느낌, 주관)

1주차, 2주차 과정의 경우 리액트에 대한 기본적인 이해도를 다지는 과정이란 생각이 든다. 또는 리액트에 대해 잘못 알고 있던 부분이나 잘못된 습관을 교정하는 시간이란 생각도 든다. 그리고 이것들은 앞으로의 과정에서 (개인적으로 코드숨 교육의 핵심이라 생각하는) 좋은 테스트를 작성하기 위한 초석이라고 생각했다. 최대한 각 과제의 의도를 먼저 잘 생각해보고 과제를 수행해야겠다.

관심사 분리

뜬금없지만 개발을 처음 배울 당시 관심사 분리라는 말을 처음 들었을 때 굉장히 번역투 느낌 물씬 풍기는 용어라고 생각했다ㅋㅋ

2주차 과정에서 리액트에서의 관심사 분리에 대해 흥미로웠던 부분은, 상태관리와 ui관리를 나눈단 점에서 Container-Presenter 패턴과 유사해보였다는 것이다. 해당 패턴은 리액트 진영에선 class 컴포넌트 시절에 자주 사용되던 것으로 훅의 등장 이후에는 거의 사용되지 않는 것으로 알고 있다. (참고글)

따라서 코드숨의 2주차 과정에서도 훅을 이용해 관심사 분리를 하되, 상태를 최상단 컴포넌트에서 관리하고 각 하위 컴포넌트에서는 상태든 상태를 업데이트 하는 함수든 하여튼 상태와 관련된 모든 것을 Prop으로 전달받아 ui를 그려내는 구조를 보여준다.

이 부분이 완전 새롭다거나 크게 이해가 어렵다거나 하는 부분은 아니었지만, 스스로를 되돌아보게 만들었다. 평소 리액트 개발을 할 때 해당 부분을 완전히 꼼꼼하게 챙겼는가 하면…🤔 회사에서 지금 진행하는 프로젝트의 코드들을 다시 점검해봐야겠단 생각을 젤 많이 했다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

Findings (배운 점)

리액트의 비제어/제어 컴포넌트, useRef

바닐라 자바스크립트로 코딩하는 것과 달리 리액트는 개발자가 돔에 직접 접근하지 않고도 ui를 다시 그려낼 수 있게 도와준다. 하지만 때로는 돔에 직접 접근해야할 때가 있고 그 때에는 useRef를 이용한다.

여기까진 원래 알던 사실이고, 리액트에서 form 요소를 다룰 때 비제어 컴포넌트 / 제어 컴포넌트로 나누고 일반적으로 제어 컴포넌트를 사용하는 것을 권장하고 있다는 것을 코드리뷰를 통해 배웠다.

나는 원래 공식문서에서도 링크 되어 있는 이런글처럼 필요할 경우 비제어 컴포넌트로 작성해오곤 했다. 이번 과제에서도 마찬가지였다.

• 실시간으로 싱크가 맞아야 할 필요가 없고
• 실시간 유효성 검사등의 기능이 요구되지 않고
• 즉 꼭 상태로 관리하지 않아도 될 때
• 상태로 관리함으로써 렌더링 성능 이슈가 걱정될 때 (사실 이게 젤 컸다. 요즘 회사에서 하는 프로젝트랑 관련이 있다,,,ㅋㅋㅋㅋ)

뭐 이런 이유로 input, button 만 만들고 ref를 이용해 input의 값을 직접 가져왔다. 과제의 규모가 작기도 하고 크게 문제 없을 것이라는 안일한 생각이었다.

리액트에서 DOM에 직접 접근하고 수정하는 것은 리액트의 가상돔 비교나 렌더링 과정을 해칠(?) 수 있기 때문에 권장되지 않는다.

코드리뷰 과정에서 리액트에서 DOM을 직접 접근하고 수정하는 것보다 form을 활용해보라는 피드백을 받아 form태그를 이용하고 form 요소들을 제어 컴포넌트로 만드는 수정을 거쳤다.

사실 요즘 약간 상태혐오자처럼 된 감이 없지 않아 있는데 (ㅋㅋ), 코드리뷰를 통해 다시 생각해보니 결국 상태를 잘 활용하는 게 리액트스럽다는 생각이 들었다. 특히 상태관리로 인해 나타날 수 있는 부작용은 useMemo / useCallback / 관심사 분리 등 다양한 방법을 통해 해결할 수 있기에 DOM에 직접 접근하는 것을 지양하는 게 우선순위가 더 높겠단 판단이었다.

코드리뷰 과정에서 무지성적으로 피드백을 approve 하는 게 아닌, 확실하게 납득하고 넘어가고 싶어 트레이너분께 질문을 많이 드렸는데 그런 내가 답답하셨을 수 있을 것 같다.😅

명시적인 것과 코드 가독성의 관계

코딩 습관이나 컨벤션 취향은 개개인마다 너무 다르다. 그렇지만 단 하나 공통적인 것은, 코딩 습관을 잡을때 가장 중요한 기준이 ‘다른 사람이 읽기 좋은 코드’라는 목표를 충족시킬 수 있냐는 것이다. 가령 누군가는 다음과 같이 {}를 생략하고 바로 리턴하는 것이 훨씬 깔끔하여 읽기 좋은 코드라 생각하기도 하고

if (foo) return false;

누군가는 다음과 같이 {}를 명시적으로 나타내는 것이 scope를 헷갈릴 일을 줄이므로 더 읽기 좋은 코드라 생각하기도 한다.

if (foo) {
  return false;
}

개인적으로는 지금까지 리턴문이 짧게 단독으로 있을 경우 {}을 생략한다거나, count === 0대신 !!count를 쓴다거나의 방식을 택해왔었지만 코드가 좀 더 길어지더라도 명시적으로 드러내는 것이 더 좋은 가독성을 보여준다는 것을 배웠다. 요즘 변수명이 길어지더라도 축약형으로 사용하지 않는 것도 같은 이유에서인데, 다만 엄청나게 길어질 경우 이게 정말 가독성에 도움이 되나? 하는 생각이 가끔 들긴한다.

아 그리고, 사소한 앎이지만 이름 지을 때 field를 많이 쓴다는 것도 알게됐다!!