Facts(사실, 객관)

• 리액트 강의와 과제가 주어지는 8주 과정이 끝났다.
• 리뷰할 때 짤방을 사용하는데 좋은 짤방을 받았다고 기뻐하는 피드백이 있었다.

Feelings(느낌, 주관)

• 재미 삼아 리뷰에 짤방을 사용했는데 리뷰 받는 사람 입장에서는 의미부여를 내 생각 보다 크게 하는 것 같았다. 앞으로는 짤방 사용도 신경써야겠다.

Findings(배운점)

• 컴포넌트를 기계적으로 분리하려는 시도가 많았다. 항상 '왜'를 생각하게 하는게 중요하다.
• 글로 전달할 때에는 말투, 짤방 등이 내 뉘앙스를 결정한다.

Affirmation(자기선언)

• 좋은 프로 짤방 리뷰어가 되자!

Facts(사실, 객관)

• 수강생 분들이 점진적으로 구조를 잡아갈 수 있도록 리뷰도 작게 나누어 진행해 보았다.
• 테스트 코드를 작성할 때 describe ~ context - it 구조를 헷갈리시는 분들이 많았다.
• mock functions 를 모아놓은 파일을 생성할 때 의외로 함수를 jest.fn() 으로 선언하지 않는 경우가 많았다.

Feelings(느낌, 주관)

• 공통적으로 하는 리뷰들이 많은데 자주하는 리뷰 같은 걸 만들면 좋겠다는 생각이 들었다.
• 나조차도 습관적으로 작성하던 코드들이 '왜' 그렇게 하면 좋은지 리뷰를 하면서 고민할 수 있어서 좋았다.
• '굳이' 라는 생각으로 그냥그냥 넘어가는 것들이 있다. 어디까지가 적정선인지 고민이 된다.

Findings(배운점)

• 코드는 해당하는 부분만 봐서는 문제를 해결하기 어려운 경우가 있는데 높은 확률로 구조 자체에 대한 개선이 필요한 경우가 많다.
• 리뷰를 할 때 '우연히' 통과되었기 때문에 넘어가는 것들이 없는지 잘 살펴야한다.
• 사람들이 습관적으로 문제를 해결하기 위해 임시방편으로 코드를 작성하는 경우가 많다. 때로는 코드의 순서만 봐도 임시방편 코드인지 알 수 있다.

Affirmatino(자기선언)

• 간단한 것도 '왜' 를 고민해보자!

Facts (사실, 객관)

• 주간회고가 점점 적게 올라오고 있다.
• 가끔은 에디터가 문제일 때도 있다.
• 리뷰 시간이 늦어진 날들이 있었다.
• 수강생분들 중에 지난 과제를 하느라 이번주 과제를 못하는 경우가 있었다.

Feelings (느낌, 주관)

• 개인적으로 힘든 한주였는데 리뷰 퀄리티에 영향을 줄까 봐 신경쓰다 보니 더 힘든 한주였다.
• mock 개념을 어려워하시는 분들이 많은 것 같았다.
• 리뷰 시간이 늦어질 때는 미리 리뷰드려야할 수강생분들께 알려드릴 수 있는 방법을 찾아야겠다.

Findings (배운점)

• PR을 알맞은 브랜치에 보냈는지 항상 먼저 체크해야 한다.
• PR이 늦을 때는 혹시 지난 과제를 하고있어서 인지 체크해보자.
• 힘든건 힘들다고 인정해야한다.

Affirmation (자기 선언)

• 멘탈을 회복하자!

Facts (사실, 객관)

• 수강생 분들이 PR을 보내는 속도가 느려졌다.
• 직접 알려주기 보다 방향을 스스로 찾아 갈 수 있도록 리뷰를 많이 했다.
• beforeEach 사용에 대한 리뷰가 많았다.
• Redux 를 mock 했는데 왜 실제로 작동이 안하는지 이해하지 못하는 경우가 많았다.

Feelings (느낌, 주관)

• 4주차 정도에 사람들의 텐션이 많이 떨어지는 것 같다.(테스트 코드에 대한 압박과 Redux 사용에 대한 어려움 때문일까?)
• 리뷰를 할 때 직접 알려주지 않아도 방향만 알려줘도 사람들은 대부분은 스스로 잘 찾는다.
• 리뷰어의 컨디션도 리뷰에 영향을 많이 끼친다.
• 코칭을 위해서는 단순히 공부 뿐만 아니라 그 사람에 대해 더 많은 것들을 알려고 하고 공유하고 있어야 하는 것 같다.

Findings (배운점)

• 리뷰할 때 파일 경로도 잘 확인해 보고, 프로젝트 폴더 구조를 어떻게 구성하고 있는지도 살펴봐야한다.
• 리뷰 퀄리티를 위해 컨디션 관리도 잘해야한다.

Affirmation (자기 선언)

• 좋은 리뷰를 위해 좋은 컨디션을 유지하자!

인구의 20%가 이탈리아 전체 부의 80%를 가지고 있다는 파레토 법칙이 있다.
리뷰에서도 마찬가지다. 수강생의 20%가 전체 리뷰 시간의 80%를 가져간다.

Facts (사실, 객관)

• 역대급 리뷰수를 달성했다. 주고 받은 리뷰수가 94개였다.
• 코드를 리뷰할 때 동일한 내용은 중복해서 코멘트를 달지 않는다.(항상 리뷰를 반영하실 때 적용되는 부분이 또 있는지 확인해주세요!)
• 리뷰 퀄리티는 모두에게 동일하게 하려고 하지만 리뷰 시간은 동일 할 수 없다.

Feelings (느낌, 주관)

• 수강생분들이 읽을거리를 찾아와 질문을 하시면 나는 그 읽을거리를 모두 읽다보니 더 많은 걸 알아가게 되는 것 같다.
• 테스트 코드가 낯선 분들에게는 어떻게 더 조언을 드리면 좋을지 고민을 많이 해봐야겠다.
• 가끔 리뷰를 하다가 미리 알려줘 버리는 느낌을 받을 때가 있다. 스스로 찾을 수 있도록 완급 조절도 잘 해야겠다.

Findings (배운점)

• 테스트 코드를 작성할 때 React Testing Library 에서 screen 을 사용하는 것 보다 그냥 render 를 사용하는게 왜 더 나은지 개인적으로 생각해볼 기회가 있었다. screen 이 더 최신이지만 인터페이스적인 측면에서 오히려 더 별로인 것 같다는 생각이 들었다.
• 최신이라고 무조건 좋은게 아니다. 새로운 것을 도입할 때는 고민을 많이 해봐야한다.
• React Testing Library 에 user-event 라는게 있다. 테스트에서 이벤트를 발생시키고 싶을 때 fireEvent 를 대체해서 사용할 수 있는데 조금 더 사용자의 관점에서 이벤트를 표현하는 점이 좋은 것 같다.
• 리뷰를 하다보면 다양하고 깊게 공부하는 분들이 있는데 공부하는 태도를 배우게 된다.

Affirmation (자기 선언)

• 나도 20%의 사람이 되어야겠다!

지난 기수에서 회고를 작성할 때 트레이너로서 함께 주간 회고를 작성하면서 진행하기로 했는데 회사 일정에 밀려서 1주차는 회고를 작성하지 못했다.

Facts (사실, 객관)

• PR을 보내지 않은 수강생 분이 2명이나 있었다.
• setState 등으로 (객체)상태를 바꿔줄 때 기존 상태를 넣어줘야 한다는 걸 놓치는 분들이 많다. (...state 를 넣어주세요!)
• 컴포넌트를 분리할 때 '왜'를 고민하지 않고, 기계적으로 분리하는 경우가 많았다.

Feelings (느낌, 주관)

• 코드를 읽다보면 피드백이 잘 반영되었는지 알 수 있다. 피드백을 잘 반영해주는 것도 좋지만, 리뷰어도 사람이기 때문에 어떻게 반영했다는 코맨트를 달아주거나 배운점, 감사한 점 등의 코맨트를 달아주면 더 기분이 좋다.
• '우연히'에 대한 논의를 주고 받을 수 있어서 좋았다.(컴포넌트 간에 props 를 전달할 때 변수나 함수 이름이 같은 건 '우연히'도 그 이름이 적절했기 때문이다.)
• Guard clause 에 대한 리뷰를 달아드린게 있는데 배운 것을 실제로 적용해볼 수 있었다는 피드백을 받아 뿌듯했다.

오... 예전 책으로만 봤었던 Guard clause 을 리액트에서도 적용해볼수가 있군요...!
Java에서만 사용해본 패턴이었는데.. 정말 좋은 점을 알아갑니다!!
해당 출처에서 자세히 설명되어 있네용 ㅎㅎ

Findings (배운 점)

• '우연히'에 대해 설명을 하다보니 스스로도 많이 정리가 되었다.
• 코드리뷰를 할 때 한번에 피드백을 쏟아 내기 보단 순차적으로 개선해 나갈 수 있도록 방향을 잡아야겠다.

Affirmation (자기 선언)

• 주간 회고를 꾸준히 쓰도록 노력해야겠다.