현재 노트: KR-410.00 c 우아한테크코스 프리코스 7기 3주차 - 목표 수정과 Jest
상위 분류: KR-410.00 우아한테크코스 프리코스 7기 회고록 1개월 기록

#성장경험 #개인학습과회고 #우아한테크코스프리코스

우아한테크코스 프리코스 7기 3주차 - 목표 수정과 Jest

설정 목표는 완료하였는가? 시작전과 무엇이 달라졌는가?
생각해보기

우아한테크코스 프리코스도 3주차를 넘어 마지막 1주가남은 시점에서 회고를 통해 다음 2가지의 질문에 답변해보려고 합니다.

설정 목표는 완료하였는가?

결론부터 말하자면 처음에 설정한 목표는 완수하지 못했습니다. 다만 그 이유는 우아한 테크코스의 주차가 넘어가면서 설정 목표가 계속 수정됐기 때문입니다.

우아한 테크코스 프리코스 시작 전 목표 2가지였습니다.

• 커밋 리뷰의 수와 긍정적인 피드백 증가
• 회고록 방문자 블로그 방문 수의 증가

먼저 지표로 측정이 가능해야한다! 라는 조건을 기준으로 측정가능한 것이 뭐가 있었을까 했을 때 위와같은 커밋 리뷰의 수와 회고록 작성시 블로그 방문 수가 측정이 가능하고 두 가지 행위의 목표는 우아한테크코스를 통해 성장하고자 하는 부분도 맞기에 위와같은 목표를 설정하였습니다.

1주차 후 우아한 프리코스 목표

• 커밋 리뷰의 수와 긍정적인 피드백 정도 -> 커밋 리뷰 항목을 목록화하고 처리하기
• 회고록 방문자 블로그 방문 수 -> 디스코드 포스트 추천 봇 만들기

커밋 리뷰의 경우 많은 피드백이 있었습니다. 먼저 공통 피드백이라는 형태로 많은 양의 피드백과 한 분에 3~4개를 생각한 리뷰수와는 달리 보통 5개이상의 피드백을 주시면서 커밋 리뷰 및 전반적인 피드백의 수는 충분했습니다. 하지만 생각해 보았을때 단순히 숫자가 많다거나 긍정적인게 많다는 부분은 애매한 목표라 생각했습니다. 그래서 오히려 피드백 항목을 목록화 한 후, 그 리스트가 다음 주차에 나오지 않게 하는 방식이라면 나의 커밋 방식이 발전했구나를 느낄 수 있기에 목표의 형태를 바꿨습니다.

우아한테크코스 1주차 회고록 블로그 방문자의 수가 6으로 집계됐습니다! 그래서 처음에 느낀 것은 성장한다고 느끼기에는 어려운 데이터다 라는 느낌이었습니다. 그래서 수정한 목표가 우아한테크코스 프리코스 포스트 추천 디스코드 봇을 만들자! 였습니다. 이런 생각을 하게된 배경은 프리코스의 모두가 열정적으로 공유하고 토의하는 데이터가 아깝다는 생각이 먼저였습니다. 그 생각을 곰곰히 생각하면서 변경하는 목표는 프리코스 기간중에만 가능한 특별한 것을 해보고 싶은 마음이었습니다. 그 결과 위에서 언급한 것처럼 프리코스만의 데이터를 활용하여 포스트를 추천해주는 사서와 같은 봇을 프리코스 끝나기전까지 만들어보자는 목표로 바꾸었습니다.

2주차 후 우아한테크코스 프리코스 목표

• 커밋 리뷰 항목을 목록화하고 처리하기
• 디스코드 포스트 추천 봇 만들기 -> 디스코드 포스트 추천 봇 실제 서비스 하기

커밋 리뷰 항목을 목록화하고 처리하기 목표는 수행해보니 꽤 좋은 성과를 내어서 지속하기에 좋다고 생각했습니다. 먼저 해당 항목들을 목록화하는 과정에서 내가 놓치거나 한 부분을 일목요연하게 볼 수 있었습니다. "아 저번에 피드백에서 이런걸 받았었지, 이번엔 그럼 이렇게 해보자"라는 더 의식하며 코드를 작성하게 됐습니다. 그 결과 저번 주차에 언급됐던 항목이 언급되지 않게 되면서 한층 스스로 성장했다는 것을 느낄 수 있었습니다. 주차가 계속되면서 새로운 피드백, 새로운 관점 추가적으로 오프라인 스터디를 통한 피드백 항목들이 계속 발생했지만, 이를 처리함으로서 스스로 성장을 직접적으로 느낄 수 있기에 지속하기로 했습니다

이번 주차 커밋 리뷰 피드백 목록 일부

• index.js로 상수 한 파일에 통일하기
• trim을 통한 입력검증
• 테스트케이스 요구사항, 성공, 실패케이스 나누기
• 동작기능처럼 모호한 표현 사용하지말기
• docs의 지속적인 업데이트
• 유닛 단위의 테스트

디스코 포스트 추천 봇의 경우 로컬 서버에서 단순 동작하는 기능을 만들었습니다. 디스코드 봇을 처음 쓰다보니 프리코스기간동안 일단 돌아가는 것을 목표로 하자고 정했지만 의외로 구현 자체는 이번주에 될정도 빠르게 성공했습니다!. 권한 관리를 익히고 개인서버에서 테스트하면서 실제로 원하는 데이터를 읽고 저장하는 단계까지 구현했습니다. 기본 로직인 각 포스트에서 쓰레드 데이터를 가져와 이모지 리액션 + 서브 메시지 수의 합계를 기준으로 가장 숫자가 높은 5가지를 추출하여 json파일 형태로 저장이 되는 것이 확인 됐습니다.
해당 목표는 더 나아가 이제 개인 서버가 아닌 우아한테크코스 프리코스 커뮤니티 서버에서 해당 동작을 수행하기. 추가적으로 커맨드 입력을 받기, 현재의 1주단위가 아닌 하루 단위의 best추천 등의 기능 추가등 실제로 서비스하기를 다음 목표로 변경하게됐습니다,

3주차 후 우아한테크코스 프리코스 목표

• 커밋 리뷰 항목을 목록화하고 처리하기
• 디스코드 포스트 추천 봇 실제 서비스 하기 -> 디스코드 포스트 추천 봇 실제 유저에게 피드백 받기

이번 주차 커밋 리뷰 피드백 목록 일부

• Lotto 데이터 구조가 명확히 알기 힘듬
• 순수함수 사용하는 것이 좋음
• style만 변경하는 부분을 따로 메소드 처리한 것은 과도한 메소드 분리가 아닌지
• Object.key를 활용하여 값을 얻을 수 있는데 따로 배열로 관리하는 이유가?
• 결과값을 if문에 활용한다면 flag라는 변수를 사용하지 않아도 될것
• 구조분해 할당을 한 이유가? 안했을때의 sort와의 차이가?
• 공백도 라인수로 고려해야한다
• 객체 답게 private와 static활용

분명 저번주차의 피드백을 수정했는데도 정말 많은 피드백이 많이 나왔다!
다른 프로그램과 다른 요구사항, 다른 구현을 하면서 당연하게도 다른 피드백도 계속 나오는것같다... 즉 정말 같은 것을 하지 않는 이상, 정확히는 같은 것을 같은 방법으로 하지 않는이상은 피드백은 계속 나올것이다...! 자신의 성장의 징표로 생각하고 긍정적으로 받아드리기로 하자... 프리코스 끝날때까지 최대한 해당 항목을 제거하는 것으로!

디스코드 포스트 추천 봇 실제 서비스 하기
정말 많은 일이 있었다. 생각보다 실제로 서비스하는 것은 내 개인 서버에서 단순히 테스트할 때 보다 한 15배 어려운것 같다 자세한 사항은 다음의 글 참고 330.20 a...
어찌됐던 실제 서비스까지 동작하는 상황까지 구현하였다. 처음에는 프리코스 끝날 때까지 단순히 내 개인서버에서 어떻게든 동작만 해라!가 목표였는데 욕심을 내고 계속 계속 몰입해서 만들다보니 어느새 실제 24시간 서비스하며 정보를 제공할 수 있는 훌륭한 봇구현이라는 목표를 달성하였다. 물론 그 과정에서 언급한 글처럼 정말 많은 일이 있었다... 여기서 목표를 좀 더 수정하자면 마지막으로 유저 피드백을 얻으면 좋겠다고 생각했다. 1주 정도밖에 안남았지만 실제 내 프로그램의 후기를 듣는 것만으로 정말 큰 도움이 되지 않을까 싶어 목표를 다시 올렸다.

시작전과 무엇이 달라졌는가?

프로젝트를 하면서 무의식적으로커밋단위처럼 기록을 하게 됐다!

처음 디스코드 봇의 단순 저장 기능 자체는 로컬에서 잠깐씩만하는 것은 3일 정도만에 돼서 이를 실제로 서비스하는 데는 얼마 안 걸릴것이라 생각.
하지만 실제로는 매우 많은 난관이 있었고...
자세한 프로젝트 구현 후기는 다음의 글을 참조 330.20 a

프로덕션 서비스전 약 10번 전후의 커밋이었는데, 서비스 후 약 80번 정도 커밋이 발생함.
그리고 특정 문제가 생길때마다 기록을 하였는데 돌이켜보니 마치 코밋단위로 작성 한 것임을 깨달음.

트러블 슈팅 단위이긴 하지만 어찌보면 feat, fix, test 1개또는 2~3개가 뭉친 느낌의 단위임
재미있게도 공통 피드백에서 나왔던 살아있는 문서를 위한 행위인 문서 업데이트 커밋행위가
우테코전에는 한 번더 안 해봤었는데 프로젝트 진행 중 자주 나왔다는 점!

예를들어 하다가 필요한 기능인 배치로 데이터 일부저장 채널별 저장 같은 기능을 추가하거나 아예 새로운 기능인 커맨다입력형태로 봇 실행하기, 클라우드로 24시간 호스팅하기등 업데이트 할 게 많았다. 추가적으로 봇의 권한을 기록도 이번에 docs에 했는데 그 결과 최소권한원칙도 생각해보며 기능 구현할 수 있었다. 이전에는 일단 돌아가게 하기위해 좋아보이는 기능들을 기록하지 않고 최대한 넣다보니 어떤기능이 부족했을 때 문제가 발생해도 파악이 어려웠었음.

유닛 단위로 테스트해보기

Jest라는 도구를 듣기만하고 사용해본적은 없었는데 이번에 처음으로 사용해보았습니다, 단순히 사용하는 것을 넘어 왜 사용하는지, 어떻게 해야 잘 사용할지, 유닛 테스트란 자주 반복 하는 것이 핵심이라는 점 등 깊이있게 배울 수 있었습니다. 특히 점점 잘게 쪼개지는 테스트 단위를 다음과 같이 느낄 수 있었습니다,
0. Jest 문법에 익숙해지면 describe 블록, test블록, 매쳐등 Jest를 사용하기 위한 문법에 익숙해졌습니다

1. 단계이후 테스트 수행시에는 처음에 모든 파일을 테스트 했습니다. 한 번 돌릴 때마다 __test__ 안의 모든 파일들이 수행되면서 너무 많이 실행되는 것 아닌가? 어떻게 고치지 라는 생각을 하게됐습니다.

2. 단계 특정 파일만 테스트. Jest 파일 옵션을 통해 특정 파일만 테스트가 가능하다는 것을 알고 좀 더 잘개 쪼갤 수 있었습니다. 이게 좋았던점이 기존의 모든 통합 테스트의 경우 거의 실패가 나오는데, 그러다보니 내가 원하는 파일만 테스트했을 때 빨간색인 failed가 나오는지 가시성이 떨어졌기 때문입니다. 그래서 테스트단위가 모든 파일에서 단일 파일로 쪼개졌습니다.

3. 단계 이 후 한 파일내에서도 -t 옵션으로 특정 describe 단위로 수행하게됐습니다. 테스트파일을 클래스 단위로 describe블럭을 메소드 단위로 설정하다보니 원하는 메소드만 테스트하고 싶어졌습니다. 그래서 jest의 옵션을 통해 특정 키워드를 통해 테스트 블록지정이 가능하다는 것을 알고 이를 통해 테스트 단위가 단일 파일 단위에서 블럭단위로 더 잘개 쪼개졌습니다.

4. 단계(현재) vscode 확장 프로그램으로 저장시마다 테스트. 우테코 프리코스의 피드백을 보고 직접 찾아본 프로그램이었습니다. 이는 특정 파일의 변화에대해 빠르게 그리고 시각적으로 잘 버여주는 형태로 테스트를 수행하게 됩니다. 매번 파일이름 -t 키워드같이 입력할 필요도없으며 설정에따라 저장할 때마다 라인별로 수행이 가능하게됩니다! 즉 한번 더 테스트 단위가 쪼개지면서 블럭단위에서 라인 단위로 테스트를 수행할 수 있게 됐습니다.