스터디원들과 함께하는 미니 크래프톤 정글

들어가기에 앞서

혹시 6기 지원자 분들께서 이 글을 보신다면, 정글 관련 오픈채팅방에 꼭들어가시라고 권유 해드리고 싶다.
먼저 면접을 보신 분들이 보안 유지를 지키는 선에서 어땠다 라는 후기를 공유해주시기도 하고, 미리 합격자가 발표난 것도 여기 분들 덕분에 알게 되었다.
또한 면접을 볼 때에 혹시 털리더라도 아는 사람과 함께 털리게되면 심리적인 압박감이 조금은 덜해진다(정글은 다대일 면접이어서 그런 것 같다. 예대 면접은 학생 한명을 교수님 5명이서 터시는 방식이어서 그런 게 소용 없었지만)

토이 프로젝트 개요

물리적 시간 2주, 그리고 현실적으로 코딩에 가능한 시간은 약 1주였으므로 재미와 기존의 api를 활용가능한 방향으로 프로젝트가 논의 되었다.
나는 풀스택이 되고자하는 마음도 컸으며, 이사로 인하여 첫번째 역할분담 회의에 빠지게되었기 때문에 비는 자리면 아무곳이나 괜찮다는 말을 하여 리액트 팀으로 들어가게 되었다.

결과물

아직 백엔드팀의 오류가 덜 잡혀서 백엔드와 프론트엔드의 뷰를 연결하는 작업은 끝내지 못한 상황이다.
사실 저 네이버 블로그의 css에서 좀 더 변화한 부분도 있으나 아주 미세한 css조정 정도이기에 새 게시물은 업로드하지 않았다.
완성본 이미지 보러가기

흥미로운 오류

리액트에서는 동적으로 엘리먼트를 렌더링 할 때(내 프로젝트에서는 카드뷰를 무한스크롤)아이디 값이 중복되면 에러를 일으킨다.
여기에서 신기한 것은 무조건적으로 작동을 하지 않는 것이 아니라 c++의 undefined behavior처럼 예기치 못한 결과를 초래하는 것이어서 운빨(?)에 따라 작동여부가 결정된다는 것이다.
우리 프로젝트에서는 아직 백이 완성되지 않아 id를 고유하게 주지 못해 일어난 것이지만 개인적으로는 오류가 무조건적으로는 뜨지 않는다는 게 좀 흥미로웠다.

꿀팁1

혹시 나와 같이 프로젝트가 처음이라면, 그리고 프론트 엔드든 백엔드든 동일한 역할을 하는 사람이 여럿이라면 서로 의존성 버전을 맞추는 것이 좋을 것 같다.
예를 들어서 가장 최신버전으로 하자든지 안정화된 버전중 가장 최신을 채택한다든지 하는 식으로 말이다.
우리는 그런 부분에 대한 상의를 생각하지 못한 채로(프론트 둘다 리액트가 처음이어서)진행해서 거의 조장과 같았던 분이 main1 내 꺼를 main2로 두개의 최종본을 만들었는데 그 과정에서 main1을 바탕소스로 main2를 만드니 의존성이나 barble에서 문제가 생겼었다.
나는 단체로 하는 프로젝트가 처음이어서 전혀 예상도 하지못한 문제였다.

꿀팁2

개인적으로 새로운 언어나 환경에서 코딩을 한다면, 또 시간이 있다면 그 언어의 탄생 배경 및 채택배경 그리고 디렉토리 구조 등을 미리 찾아보는 것이 좋다.
사실 디렉토리 구조만 찾아봐도 되지만 나의 경우 내가 하던 언어는 안 이랬는데라는 생각이 먼저 들어서 그 언어의 탄생 배경 등을 함께 보면서 얘는 이래서 이렇게 해야하는구나라고 내 자신을 납득시키는 시간을 가졌다.
그리고 그런 식으로 미리 디렉토리 구조를 나눠두면 어차피 그에 맞추어서 구조적인 코딩을 하게 되고 자연스럽게 그 언어의 환경에 맞는 최종 결과물이 탄생하는 경우가 많다.
나도 우테코 전에는 main에 모두 집어넣었지만 그 이후로 생긴 버릇 같은 것이니 꼭 이렇게 하라는 게 아니라 이런 방식도 있다는 것 정도로 이해하면 좋을 것 같다.

꿀팁3

이번에는 프론트엔드를 하게 되어 딱히 유용하지 않았으나, 오류가 뭔가 논리적인 부분에서 문제가 일어난 것 같다면 중단점을 찍어보거나 콘솔로 하나하나 찍어보는 것이 의외로 빠를 때도 있다.
내가 어디서 무엇을 잘못했는지 생각을 할 때에, 어디서가 풀리면 무엇을은 저절로 풀리는 경우도 많기 때문이다.
그리고 백엔드라면 TDD라는 방식으로 테스트 코드를 미리 만드는 것도 유용하다.

TDD

사실 나도 잘 모르지만, 얼마전에 이와 관련한 강의를 듣고 조금 감이 잡혀서 이렇게 따로 서술을 하게 되었다.
아래에 나올 내용들은 이미 TDD에 대해 공부해본 사람에겐 딱히 의미가 없을 것 같고, 이 개념을 처음 듣는다거나 나처럼 테스트코드를 짜본 경험이 거의 없는 사람에게만 도움이 될 것 같다.

나쁜 예시1

전체로직을 한번에 체크하는 경우 문제지점을 알기 어렵다.
따라서 입력을 체크123이 있다면 이 123을 각각 따로따로 체크하도록 단위별로 테스트코드를 짜는 것이 좋다.

나쁜예시2

이것은 테스트코드의 나쁜 예시라기보다는, 습관의 문제인데 코드를 고쳤다면 꼭 이전에 통과한 테스트코드까지 전체를 확인하는 습관을 들여야한다.
그렇지 않으면 나처럼 갑자기 뒷부분 테스트는 통과하는데 다시 앞부분을 통과하지 못하는 코드를 만들 수도 있다.

테스트 코드 짜기

레드단계

처음에는 의사코드로 짜거나 간단하게 한글로 스케치를 하는 등 실제 Junit에서는 돌아가지 않는 나의 생각을 정리하는 코드를 작성한다.

그린

돌아가는 테스트코드를 작성하고, 그에 맞는 코드를 작성한다.
예를 들어보자면 id는 5글자를 초과하지 않게한다는 조건을 테스트 하기위해, id.length를 사용하여 길이를 점검하는 과정이다.

옐로우

중복로직 제거 및 일반화 그리고 좀 더 가독성 좋은 코드등을 작성하기 위한 리팩토링을 거친다.

좋은 예시-경계값 테스트

위의 테스트 코드짜기 단계에서의 한가지 팁을 주자면, 경계값에 대한 테스트를 꼭 해보는 것이 좋다.
예를 들어 5글자를 초과하지 않는 조건을 테스트 한다면 6글자를 입력해보는 것이다.
이때 통과가 된다면 7글자에 대한 테스트는 해보지 않아도 될 확률이 높다.

좋은 예시2

테스트코드도 코드이다.
따라서 객체지향적에서 그렇게 노래하듯 강조하는 분담이 잘 이루어져 있어야한다.
이 분담은 함수 단위 일 수도 함수 안에 있는 메서드에 대한 테스트일 수도 있다.
한가지 분명한 것은 나처럼 클래스 단위만 테스트를 한다면 어떤 함수에서 에러가 났는지 파악이 어렵다는 것이다.

프로젝트 관련 꿀팁

우선 나처럼 겁을 먹지 말고, 매도 먼저 맞는 게 낫다.
나의 경우 회사까지 다니다가 학교로 오신 분께 프로젝트 제의를 두번이나 받았으나 첫번째 제의를 받을 때에는 내 실력이 부족하다는 생각에 거절, 두번째 제의 때에는 우테코와 도무지 함께 할 자신이 없어서 거절을 했다.
그러나 스터디원들과 미니 프로젝트를 하면서 느낀 것은 어차피 개발자에겐 협업이 필수라는 것이다.
아마 그때 저분과 프로젝트를 했으면 단순 코딩 말고 일머리나 교통정리도 배워서 이번 프로젝트에서 팀원분들께 코딩 외의 도움도 드릴 수 있었을 것 같아서 너무 아쉬웠다.
특히 비전공자라면 일머리까지 배울 수 있는 사람들이 프로젝트를 제의할 때에는 그냥 자신의 깃허브와 실력을 까고 그래도 그쪽에서 괜찮다고 해주면 꼭 협업을 진행해보도록 하자.
그런 기회는 정말 귀하다