2023년 7월 회고 (프론트엔드 데브코스 회고)

데브코스를 시작하고 2달이 흘러버렸다. 지금까지 주요했던 것들을 위주로 회고를 작성해보려 한다.

유효성 검사(validation)

과제 내용들 중 validation을 구현해보라는 내용이 있었다. 평소 코딩을 할 때 유효성 검증에 대한 생각은 한 번도 해본적이 없었고, 실제로 해본적도 없었다. 과제를 하면서 그리고 한 후 유효성 검증을 어떤 식으로 해야하는지 알아보는 좋은 기회가 되었다. 멘토님의 하신 말씀을 정리하여 짧게 정리하고 복기하려고 한다.

유효성 검사, 얼마나, 어떻게 해야하는 것인가?

완벽과 잘 하는 것

유효성 검사를 완벽하게 하면 너무 좋지만 그럴 수 없기에 현실과 타협해서 우선순위를 정하고 하나씩 해결하는 방식을 추구하자 즉 하나씩 잘 해결해나가면서 자연스럽게 완벽을 추구하는 그림을 그리면 될 것 같다.

예를 들어 1년에 장애를 99프로 이하로 나게 하는 것은 비교적 쉬울 수 있으나 99.999프로로 나게 하는 것은 많은 비용과 시간이 들어간다. 99프로는 1년에 3일이지만 99.999프로는 1년에 5.2분이다.

누구를 위한 검사인가?

과제를 진행하면서 한 유효성 검사는 api로 들어가거나 들어오는 state에 대한 유효성 검사를 진행했었다. 이런 방식의 검사는 개발자들을 위한 검사이고, 유저는 어떻게 행해야하는지 모를 것이다. 개발자들을 위한 유효성 검사는 서버 API의 유효성 검사의 경우 프론트가 서버 응답 데이터를 가지고 재가공을 할 때에는 검사를 하는 것이 의미가 있을 수 있으나 서버에서 내려줄 때 이미 이루어졌어야한다. 서버나 프론트나 검사를 할 수 있지만 프론트에서는 쉽지 않기 때문이다. 유저를 유한 유효성 검사는 어떤 방식이 있을까? 검사 결과 에러가 발생했을 경우 간단한 try catch를 통해 에러 페이지를 띄우거나 재시도를 할 수 있도록 유도하는 정도로 하면 좋을 것 같다.

어떻게 해야하는가?

데이터를 사용하는 경우보다는 데이터가 새로 넣어질 때 하는 것이 좋다.(setState를 호출하는 쪽) (API를 호출하는 상황이라면 API가 데이터를 사용하는 쪽이고 API를 호출하는 상황은 데이터를 넣어주는 쪽이다.)

데이터를 넣어주는 곳은 한 곳일 수 있지만 데이터를 사용하는 곳은 여러 곳일 수 있기 때문이다. 데이터의 어떤 부분이 바뀌는 상황일 때 넣어주는 쪽에서 미리 검사를 해둔다면 미리 대비를 해두고 통과를 했기 때문에 사용하는 곳에서는 검사를 하는 작업을 더 할 필요가 없기 때문이다. 즉 한 번만 하면 되기 때문에 개발 용이성, 복잡도 모두 좋아진다.

스터디

새로운 사람을 만나는 것을 좋아하는 나에게 무리가 없는 스터디를 모집하고 진행하는 것은 자신이 있었다. 어떻게 운영할 것인지도 계획이 있었으니 말이다. 하지만 주변 지인들이 스터디를 진행하는 것을 보면서 효율적이지 못하고 서로가 서로에 대한 신뢰가 없이 시작하다보니 금방 깨지는 경우를 많이 보았다. 그리하여 스터디를 진행하더라도 서로 신뢰가 쌓여있는 환경만 조성된다면 바로 "진행시켜" 하고 싶었다.

그 때가 지금이라는 것을 인지하고 7월 초에 미루다가 흐지부지 되기 전에 바로 "진행시켜" 해버렸다. FEDC4_JSAlgorithm_study 이름과 같이 알고리즘 스터디이다. 스터디의 목적과 방식을 정리하면 아래와 같다.

스터디 구조

• 목적
  • 알고리즘 문제들을 양으로 뿌수는 것이 아닌 하루하루 팀원들과 정한 문제(3 ~ 4)들을 푼다.
• 방식
  • 리뷰어를 1:1로 지정한다.
    • 정해진 기간안에 코드리뷰를 해주어 서로가 놓친 부분은 수정해준다.
    • 자신보다 더 나은 코드가 있다면 억지로 보게 함으로써 효율적인 코드 풀이법을 뇌에 넣는다.

결과

다행히 팀원 모두가 위와 같은 시스템에 만족을 한다고 하였다. 이런 시스템을 제안한 나 또한 뿌듯해서 성공적으로 스터디가 진행이 되고 있다고 판단하였고, 정말 뿌듯하다. 본래 8월 전까지만 해보자라는 생각을 했는데, 이 기세를 몰아 12월 수료까지 혹은 그 이후에도 계속 이어가려고한다.

1차 팀 활동을 마무리하며

1차 팀 홛동에 대한 회고는 KPT(keep, Try, Problem) 회고론을 활용하여 정리해본다.
목적은 팀 활동을 통한 개인의 역량이다.

Keep

팀원과 함께

데브코스에 들어와 팀 활동을 하기 전, 1년동안 혼자서 공부해보자는 생각을 했다. 공부를 하는 동안 이런 생각이 들었다.

• 지금 이렇게 하는 것이 맞는건지 아닌건지 혼란스럽다.
• 너무 외롭다는 감정(공허함)에 휘둘려 공부에 집중이 안된다.

그 결과, 혼자 공부하는 것보다는 함께 공부하는 것이 나에게 효과적이라는 것을 깨달았다. 데브코스에 들어와 팀 활동을 한 후, 이런 생각들이 들었다.

• 로드맵(무조건 신뢰하는 것이 아닌)이 심리적으로 안정감을 준다.
• 함께하는 팀원들을 만나면서 외로움이 사라졌다!
• 혼자 고민을 하는 것이 아닌 팀원과 함께 고민하면서 혼자서 얻는 결과보다 함께하며 얻는 결과가 더 가치가 크고 스트레스를 덜 받는다.

위와 같은 생각을 유지한채로 다음 2차 팀 3차 팀에서도 꾸준히 이행해야겠다는 생각이 들었다. 너무 만족스럽다.

코드 리뷰

매주 과제가 주어지면 과제를 수행하고 팀원들끼리 서로에 대한 코드리뷰를 해주고, 후 멘토님이 각 멘티(팀원)들의 코드를 리뷰해주는 시스템을 가지고 있다. 코드리뷰라는 것이 어떤건지는 알고 있었지만 오픈소스 PR를 할 때 코드리뷰 아닌 코드리뷰(?)를 했던 기억이 있다. 이번 팀원들 간의 코드리뷰를 통해 다음과 같은 것들을 행했다.

• 팀원들의 코드리뷰를 통한 잘못된 나의 코드 습관을 수정했다.
• 팀원들을 코드리뷰를 해주기 위한 공부를 통한 나의 성장.

코드 리뷰를 왜 하는지 이유를 알았다. 조금 귀찮을 수 있지만 함께 성장할 수 밖에 없는 구조이기 때문이다.

Problem

목적 없는 스크럼

팀 프로젝트를 하지 않고 팀 단위 활동에서 스크럼을 진행하니 매일 회고를 진행한 결과가 같은 패턴을 가지는 것이 보여졌다. 각자 강의를 듣는 것이 주된 활동이고 과제들이 나오면 팀원들의 코드리뷰를 해주는 과정이었다보니 스크럼 형식이 따분해질 수 밖에 없다는 생각이 들면서 어쩔 수 없다는 식으로 방관하는 나의 모습을 보게 되었다.

Try

목적 없는 스크럼을 극복하기

분명히 더 나은 방식으로 할 수 있었는데 말이다. 같은 반복되는 내용이더라도 아 다르고 어 다르다는 말이 있는 것처럼 살을 더 붙여서 "무엇을 할 예정이다"라기 보다는 "무엇을 어떻게 할 예정이다"처럼 말을 했으면 어땟을까라는 생각을 해본다.