🔍 클래스의 독립성
1주차에서 코드 리뷰를 했었을때 Validator 자체를 클래스로 만들고, 그 안에서 공과 게임에 대한 유효성 검사를 진행 하셨던 참가자분들이 많았다.
나도 그분들의 코드를 보고 이번 주차 미션에서 Validator 클래스를 따로 만들어서 각각 모델에 대한 유효성 검사를 진행하려 했었다.
하지만 유효성 검사를 담당하는 클래스를 생성하고 다른 클래스들에서 해당 메서드를 사용해보니, 클래스의 독립성이 헤쳐진다는 생각이 들었다.
가령 이번 미션에서 각각 독립된 자동차 이름을 다루는 Car 클래스를 만들었었는데, 이 안에서도 유효성 검사를 Validator 클래스에서 주입받아서 사용한다면 이 클래스 자체의 의미가 없어지는 문제가 발생했.
또한 이렇게 된다면 그 상위 클래스인 모든 자동차들을 다루는 AllNamesOfCars 클래스에서 독립된 자동차 값들까지 다뤄주면 됐었다.
물론 이러한 방법이 한 곳에서 다 관리를 해주니 간편해보일 순 있으나, 규모가 커지면 커질수록 각각 인스턴스 값의 독립성을 보장해주지는 못할 것이라고 생각이 들었다.
이를 통해 어떠한 기준으로 클래스를 나누는 것인 좋은 설계인가? 에 대해서 고민해 볼수 있었다.
🔍 예외 처리
이번 주차 미션에서 자동차 이름을 입력 받을때 조건이 "자동차 이름은 쉼표(,)를 기준으로 구분하며 이름은 5자 이하만 가능하다." 라는 조건이 있었다.
이 입력값이 영어만 허용하는건지, 아니면 공백 5개를 이어서 자동차 이름을 입력해준다면 어떡할것인지 등 이 입력값에 대한 유효성에 대해서 최대한 고민 해보았다.
만약 이대로 미션이 공개된다면 우테코는 지원자들의 엄청난 질문을 받게 될텐데 왜 이렇게 범용성이 넓도록 입력값에 대한 조건을 두었을까 ? 라는 기준으로 한번 생각해보았다.
우테코 입장에서도 확실한 기준점을 제시해주는것이 프리코스 참여자들의 질문을 덜 받을 것이고, 더 확실한 채점 기준을 갖는 것 아닌가? 라는 생각이 들었는데, 미션을 진행하면서 우테코의 지향점인 '스스로 몰입하여 하는 학습 방식'에 대해서 체감 해볼 수 있었.
우테코는 이러한 넓은 범위의 조건을 참가자들에게 알림으로써 이 또한 본인이 스스로 '몰입'해서 학습 해볼수 있는 경험을 제공해주는 것이라고 생각했고, 내가 만약 실제로 자동차 경주 게임을 만드는 사람이라면?의 입장에서 판단했다.
그래서 숫자, 영문, 한글이 아닌 이외의 문자는 아이디 값으로 입력할수 없다! 라는 저만의 기준점을 세울 수 있었다.
🔍 EOL 설정
이번 미션 메일에서 제공해주신 1주차 공통 피드백 중에서
"최종 제출하는 코드에서 EOL을 확인한다. 환경에 따라 의도한 바와 다르게 개행 문자 처리가 되지 않도록 EOL 설정을 확인한다." 라는 내용이 있었다.
이 내용은 문의 메일까지 보낼 정도로 확실히 이해가 가지 않았다.
내가 이해한 eol 에러는, 각 운영체제마다 개행 처리가 되는 문자열이 다르기 때문에 만약 mac 운영체제에서 windows 운영체제에서 만든 코드를 열어본다면 에러가 발생한다는 것이었.
"내 컴퓨터 운영체제는 맥 os 인데, 만약 맥에 맞는 eol 설정을 해놓았다가 우테코 채점환경은 windows면 0점 처리가 되는것이 아닌가?" 라는 걱정이 들었다.
1주차에는 auto로 설정을 해주었다가 이번엔 확실히 맥 운영체제에 맞는 lf 값으로 설정을 했는데, 이것이 맞는건지 아직 잘 모르겠다..
🔍 jest 코드 파악
1주차부터 우테코측에서 제공해주었던 테스트 코드가 정확히 무엇을 의미하는 것인지 파악해 보았다.
1주차때는 원래 ApplicationTest.js 에 있던 파일을 복사 붙여넣기 해서 사용했지만, 이번에는 아예 해당 테스트 코드들의 의미 파악이 필요하다고 생각했.
제스트 공식 문서 와 구글링, gpt 를 통해서 테스트 파일 내에 있던 코드들을 해석해보았으며, 테스트는 어떤 흐름으로 이루어지는것인지 파악해보았습니다.
특히나 jest.fn() 과 jest.spyOn()의 차이점이 이해가 안갔었다.
하지만 더 공부해보며 jest.fn()은 새로운 가짜 함수를 생성하고 (원본 함수는 실행이 되지 않는다.), jest.spyOn()은 기존 객체의 메서드에 대한 인자 호출이나, 호출 횟수 등을 감시한다(원본 함수 동작은 그대로 유지하면서 테스트할때 사용한다.) 등 테스트 코드를 해석하는 법을 배울 수 있었다.
🔍 프론트엔드에서 클래스는 언제 사용해야하는가?
디스코드에서 어떤 분이 프론트엔드에서 클래스는 언제 사용해야하는가? 에 대해서 글을 작성해주셨었다.
나 또한 클래스를 능동적으로 사용해본것은 이번이 처음이지만, 예전에 리액트에서 라이브러리 컴포넌트를 직접 만들어볼때 겪었던 경험을 토대로 댓글을 남겨보았다.
이 기회로 다른 분들의 댓글을 보며 클래스의 용도에 대해서 한번 더 생각해 볼수 있었다.
⬇️ 밑에는 디스코드에 제가 작성한 댓글입니다. ⬇️
클래스에 대해서 잘 알기 때문에 구현해본것은 아니지만
리액트에서 토스트 컴포넌트를 라이브러리 사용이 아닌 직접 구현해보고 싶어서 미리 만들어진 소스코드를 레퍼런스 삼아 따라서 만들어본적이 있는데요.
이때 컴포넌트가 아니라, 클래스로 큰 뼈대를 만들고 그걸 불러오고 싶은 컴포넌트에서 임포트 해와서 사용했었습니다.
이때 컴포넌트화 해서 만드는게 바로 렌더링도 할수 있고 더 직관적일텐데, 왜 클래스로 만들까? 라는 의문점이 들었었어요.
만들어보면서 느낀 이점은 '더 확실한 추상화' 였던것 같습니다.
... 중략
저도 프론트엔드 한해서는 클래스를 사용한 방법이 아니더라도 충분히 데이터를 은닉화 하거나, 구조화 시킬수 있지 않나? 라고 생각했는데
클래스를 이용한 컴포넌트를 직접 만들어보시는것도 클래스의 장점을 확실히 체감하실 수 있다고 생각해서 한번 괜찮으시다면 권해봅니다!
🔍 코드리뷰 문화 체험
이번 1주차가 끝난 후에 처음으로 코드 리뷰 문화를 경험해보았다.
사실 독학, 비전공이다보니 혼자서만 계속 코드를 짰었는데 이번에 제대로 저의 코드도 다른 분들에게 보여드리고, 저도 다른 분들이 만든 코드를 보면서 '함께의 가치'를 다시 한번 여실히 느낄 수 있었다.
1주차 과제였던 야구게임은 일단 완성 시키는 것이 목표였기에 다른 사람들의 코드는 어떨까? 라는 궁굼증을 가져본적은 없었다.
하지만 이번에 다른 분들의 pr 을 보며 똑같은 과제인데도 이렇게 코드들이 다 다를수가 있구나, 사소한 함수를 하나 만드는 것임에도 각각의 코드 스타일이라는 것이 존재하는구나 라는 것을 느꼈다.
기분이 좋다는 감정을 누군가는 기분이 좋다 라고 언어화 하지만 또 다른 누군가는 오늘 기분이 저 새파란 하늘 같다 라고 다르게 표현하듯이
결국엔 코딩도 직접 만들어보는 컴퓨터 언어이기 때문에 제각각의 언어 습관이 존재하는 것임을 깨달았다.
코드리뷰를 경험하며 저와 남들의 코드를 비교하며 평가하기보다, 2주차 코수타에서 "경쟁자는 남이 아닌 바로 자신"라고 말씀하셨던 것처럼 다른 분들의 코드를 '나만의 것으로 언어화' 할 수 있었다.
현재도 다른 분들의 pr을 구경하며 나만의 것으로 만들어 보며 공부를 하는 재미가 쏠쏠하여 간헐적으로 진행 중에 있다.
