우아한테크코스 프리코스 7기 회고록 1개월 기록
Description: 약 1달간의 우아한테크코스 프리코스 후기를 다룹니다. 처음설정했던 목표의 변경이나 각 주차마다 조금식 어떤면에서는 많이 바뀐 프로그래밍 하는 법을 다룹니다. 클래스, Jest, static, 커밋 컨벤션, 코드 리뷰 등등... 많은 것을 배웠습니다
현재 노트: KR-410.00 우아한테크코스 프리코스 7기 회고록 1개월 기록
상위 분류: KR-410 개인 학습과 회고
1주차 ~ 4주차 까지의 회고록
- KR-410.00 a 우아한테크코스 프리코스 7기 1주차 - 기능 단위 목록과 커밋 메시지
- KR-410.00 b 우아한테크코스 프리코스 7기 2주차 - 목표 수정과 depth 및 eslint
- KR-410.00 c 우아한테크코스 프리코스 7기 3주차 - 목표 수정과 Jest
- KR-410.00 d 우아한테크코스 프리코스 7기 4주차 - 어려운 난이도 일단 구현하기 및 테스트케이스 분석하기
우아한테크코스 프리코스 7기 회고록 1개월 기록
프리코스 제공 코드
https://github.com/woowacourse-precourse
약 1달간 프리코스를 지원하면 누구나 할 수 있는 프로그램이며 1주에 1개씩 미션을 수행하게 됩니다.
해당 프리코스를 진행하면서 많이 배운것들이 있다보니 일종의 정리 회고록을 작성하게됐습니다.
크게 다음과 같은 3가지 위주로 소개해볼까합니다.
- 목표 설정과 변화
- 하드스킬, 소프트 스킬 배운 것
- 프리코스 이전과 가장 바뀐 점
목표 설정과 변화
목표라는 것을 비유하자면 요트를 타고 목적지로 가는 느낌입니다. 가다가 풍랑을 만날 수도 있고, 목표가 달라질 수도 있고, 연료가 부족할 수도 있고 이렇게 계속 가면서 상황에 따라 키를 잡고 목표를 현실에 맞게 수정해야하죠. 제가 이번에 배운 것이 이런 목표를 달성하기 위해서 현재 상태를 최신화하고 현실성 있는 목표로 수정하는 방법입니다.
예전에는 좀더 딲딱한 느낌으로 목표를 정하면 무조건 이루기위해 노력하는 편이었습니다. 그러다보니 아예 실패하거나 아예 성공하는 케이스로 나뉜느낌이었는데, 이번에는 목표를 현실에맞게 좀더 바꿔봄으로서 목표가 이전보다 자주 바뀌지만 그래서 성공할 확률은 좀 더 높이게 된 느낌입니다.
이번 프리코스의 처음 목표는 커밋 리뷰수와 회고록 방문 수였습니다. 지표로 확인 가능한 것
이라는 목표로 만들었습니다.
1주차 후
-
커밋 리뷰 수 -> 커밋 리스트
커밋 리뷰 수의 경우 단순히 많다고 좋은게 아니라는 생각이 들었습니다. 오히려 리뷰를 했는데 잘만들어서 리뷰할 게 없어야 좋아지는 것아닌가? 근데 목표를 피드백 수가 많아지는 것으로 잡으면 방향성이 다르다는 느낌이 들었습니다. 그래서 목표 변경 -
방문자 회고록 -> 디스코드 추천 봇 만들기
방문자 회고록의 경우 구글 아날리틱스로 확인이 가능한데 총 방문수 6! 이 정도면 방문글의 내용이좋아서라기보다는 태그 키워드 차이로 바뀔정도로 데이터가 너무 쉽게 흔들리기에 이건 취소해야겠다 생각했습니다. 그리고 고민한 결과가 해당 기간동안만 가능하면서도, 지표와 같은 결과물이 나오게하기위해 프리코스 커뮤니티 채널의 좋은 글을 추천해주는 디스코드 봇정도면 괜찮다고 생각해서 변경 했습니다.
2주차 후
-
커밋 리스트 (유지)
한 주 동안 수행해본 결과 괜찮다고 느꼈습니다. 리스트화해서 피드백 요소들을 정리한 후, 이를 하나 하나 제거하거나 신경쓰면서 하다보니 코드 작성시 이전보다 좀 더 발전한? 남들이 보기 좀 더 편안하게 짤 수 있게된 것 같은 느낌이었습니다. 또 리스트가 미션이 바뀔수록, 공통 피드백으로 인해 점점 많아져 전부 수행하기 힘들다는게 단점 -
디스코드 포스트 추천 봇 만들기 -> 디스코드 포스트 추천 봇 실제 서비스 하기
처음 목표는돌아가는 디스코드 봇을 프리코스 끝날때 까지 구현
이었습니다. 한 번도 안 해본 분야이기에 넉넉하게 일단 돌아가는 걸 만들자고 생각했는데. 생각보다 너무 빨리 완성해버렸습니다... 즉 로컬에서 간단하게 채널의데이터를 읽고 json형태로 저장하는 기능이 완성되버렸습니다. 그래서 목표를 좀더 상향 수정해서 실제로 프리코스 커뮤니티 사람들에게 서비스하는 것으로 바꾸었습니다.
3주차 후
-
커밋 리스트 (유지) 단, 쌓이는 피드백이 점점 많아짐
해당 목표를 통해 커밋 리스트를 점점 수정하는 방향이 옳은 방향이긴한데 피드백 포인트가 점점 어려워지고 양도 많아지다보니 이를 다 수행하는 것은 무리라고 생각했습니다. 처음 Jest배워서 기본을 어느정도 하겠네 수준인데 피드백은 심화인경우 일부는 포기하자라는 그런 마인드의 느낌으로 피드백을 적절히 줄이자라고 생각하는 목표 수정이었습니다. -
디스코드 포스트 추천 봇 실제 서비스 하기-> 디스코드 포스트 추천 봇 실제 유저에게 피드백 받기
실제 채널에 서비스까지 확인을 하였습니다. 정말 많은일이 있어서 실제 서비스를 하는데 많은 우여곡절이 있었기에... 여기서는 설명하기에는 길고 해당 글에 정리해놓았습니다.
KR-110.00
좀더 욕심이 생겨서 해당 프로젝트를 유저들에게 사용하고 피드백맞아서 발전하기라는 목표를 세워봤습니다.
4주차 후
목표 평가 점수
- 커밋 리스트: 60점
- 디스코드 봇: 90점
커밋리스트 자체는 괜찮은 방향성이었다고봅니다. 일단 매주 미션의 공통피드백리스트 + 개인 코드리뷰 + 오프라인스터디 리뷰 까지 합쳐서 다양한 코드리뷰포인트들을 정리화하고, 다음 미션에서는 해당 사항을 유의하며 작성하니 리스트 항목을 줄이는 재미도있고, 실제 코드 실력이 올라가는 느낌이기 떄문입니다. 다만 생각보다 피드백 포인트가 너무많고 다양하다보니 이를 다 수용하기 힘들었다는점. 나중에 우선순위 피드백리스트 형태로 다음주에는 꼭 반영해볼 것, 선택적으로 반영해 볼 것 나누면 어떨까 생각이드네요. 그렇다면 모든 피드백을 못해도 목표자체는 좀더 성공한느김이라
디스코드 봇은 초기목표자체가 끝날때까지 구현이었던 것을 생각하면 매우 성공적인 목표였습니다. 일단 프리코스 기간에만 가능한 데이터를 가지고, 구체적인 결과물을 내는 형태인점이 좋았습니다. 다만 아쉬운 것은 홍보가 부족해서 사람들이 사용하고 피드백 후 발전했었으면 더좋았을텐데, 사용하는 분들이 적었던점... 그래서 홍보 형태로 채널에 자주 글을 작성하시는 분들에게 댓글형태로 달았더니 몇분이 써주셨습니다! 홍보는 실제 사용하는 사람에게 사용하면 효과적이라는 것을 깨달은 경험이네요
하드스킬, 소프트 스킬 배운 것
많은 스킬들을 배우긴 하였지만 그중에서 인상깊은 것들을 정리해봤습니다.
하드 스킬
- eslint
- prettier와 함께 사용하여 3항연산자 금지, 최대 depth 2, indent 기본값 2등과 같은 시각적으로 보기 좋은 코드 자동 포맷 툴
- Jest
- 이전부터 써보고 싶던 툴이며 기본적이 매쳐와 mock등의 기능 뿐만아니라 특정 상황 예를들어 랜덤으로 나오는 숫자를 테스트해볼떄 라던가 매일 바뀌는 날짜를 테스트하는 경우 같은 특수 상황에서의 테스트 해보기도 배웠습니다. 추가적으로 TDD로 이어지는 테스트시 어떤 목적으로 어떤 값을 테스트할지에 대한 고찰 - TDD 일부
- TDD를 프리코스 시작하며 거의 처음들었는데 기존과는 많이 다른 코드 작성 방식임을 깨달았습니다. 그래서 TDD의 일부 테스트를 먼저생각한후 실패와 피드백을 통해 원하는 테스트 구현후 코드 작성이라는 것이 어떤 느낌인지를 조금 배웠습니다.
- private, static
- 메소드나 프로퍼티에서 private와 static을 거의 안 썼는데 어떻게 왜 어디에 사용하는지를 잘몰라서... 하지만 조금 이번 기번기회를 통해 알게된거 같습니다. 특히 static의 경우 vaildator 내부에 구현하여 바로 테스트 한다던가, 캡슐화를 통해 사용자는 내부의 동작을 모르게 하는 것이 좋다라는 것이 어떤 것인지를 깨닫게 된 느낌입니다.
- class 활용
- 지금가지의 경우 대부분 함수로 구현해도 가능하다보니 class를 별로 활용하지 않았었는데 이번 기회에 많이 사용해봤습니다. 그 덕에 class라는 파일형태로 나눌때 좋은점, class내부의 프로퍼티와 메소드 구현시 단일 책인원칙을 지키기 쉬운점등 class를 이래서 쓰는 구나라는 것을 조금 배울 수 있었습니다.
소프트 스킬
- 기능 목록 나누기
- 기능을 나눌 때의 기준, 어떤 형태로 기준을 나눠야하는가? 클래스 단위? MVC패턴 단위? 오류 처리시 어떤 형태로 기록할 것인가? 등등... 구현을 하기 위해 어떤 기준으로 어떻게 기능을 나눌 것인가를 배운 사레입니다. 이를 통해 같은 팀의 개발자 뿐만 아니라 다른 팀의 부서과도 협력시 기능을 어떻게 표기할까도 생각해봤습니다.
즉 비전공자가 보기에도 문제가 없고 나중에도 문제가 생기지 않겠끔 기능 표기하기 (ex출력 표기 문구는 변수를 사용합니다-> 출력 표기 문구는 나중에도 변경이 간으해야합니다)
- 기능을 나눌 때의 기준, 어떤 형태로 기준을 나눠야하는가? 클래스 단위? MVC패턴 단위? 오류 처리시 어떤 형태로 기록할 것인가? 등등... 구현을 하기 위해 어떤 기준으로 어떻게 기능을 나눌 것인가를 배운 사레입니다. 이를 통해 같은 팀의 개발자 뿐만 아니라 다른 팀의 부서과도 협력시 기능을 어떻게 표기할까도 생각해봤습니다.
- README 업데이트
- 위의 기능 목록과 연계돼서 배운 자주 README업데이트하기입니다. 정보 공유 측면에서 성장한 포인트인데 이전에는 README가 대부분 처음이나 중간 큼직한 경우만 업데이트하였습니다. 하지만 이번에 좀더 잘 개 쪼개서 특정 기능이 구현되거나, 구현 중에 생긴 변경사항등을 기록하면서 자주 업데이트하였습니다. 그러다보니 좀더
살아있는 문서
라는 느낌이 무엇인지 이를 통해 같은 팀내 정보 공유시 이런 작업이 필요하겠구나등을 배웠습니다
- 위의 기능 목록과 연계돼서 배운 자주 README업데이트하기입니다. 정보 공유 측면에서 성장한 포인트인데 이전에는 README가 대부분 처음이나 중간 큼직한 경우만 업데이트하였습니다. 하지만 이번에 좀더 잘 개 쪼개서 특정 기능이 구현되거나, 구현 중에 생긴 변경사항등을 기록하면서 자주 업데이트하였습니다. 그러다보니 좀더
- 개발자끼리의 협업
- 오프라인 스터디를 통해 개발자끼리 협업시 많은 점을 생각해야된다는 것을 배웠습니다. 3주차에서 변수이름과 데이터포맷에 따라 로또의 상금을 말하는건지, 해당 등수를 말하는건지, 맞춘 개수를 말하는 건지와 같은 의사소통. 그리고 같은 변수라고 해도
process.env.PWD
로 할지path.resolve()
로할지,process.cwd()
로할지 등 의 의사소통이 전부 다르구나 등을 배워서 개발자끼리의 소통에서 고려해야할 점을 살짝 배운것 같습니다
- 오프라인 스터디를 통해 개발자끼리 협업시 많은 점을 생각해야된다는 것을 배웠습니다. 3주차에서 변수이름과 데이터포맷에 따라 로또의 상금을 말하는건지, 해당 등수를 말하는건지, 맞춘 개수를 말하는 건지와 같은 의사소통. 그리고 같은 변수라고 해도
- 커밋 컨벤션
- 어느 단위로 커밋을 나눌지, 컨벤션에는 어떤 내용을 담을지 정보공유 형태의 소프트 스킬을 배웠습니다.
프리코스전과 달리 바뀐 점 중 가장 인상 깊은 것
프리코스전과 후를 비교할 때 달라진 점이 없으면 성장한 것이 없다 생각화고, 만약 별로 없으면 어떡하지라는 고민을 프리코스 시작전에 했었습니다. 하지만 실상은 바뀐게 너무 많아서 무엇을 고를지가 고민이네요.
여러 바뀐점 중에서돟 가장 바뀐점은 커밋 단위로 구현 하기가 가장 크게 느끼는 변화입니다. 그 이유는 무의식적으로 커밋 단위로 기록한 자신을 발견했기 때문입니다.
실제 디스코드 봇 만들기 과정에서 약 2~3주 됐을 때 개발을 하면서 특정 기능이나 분기점마다 기록을 남겼습니다. 예를들어 10008에러 설공, 권한 문제 해결, cronjob 설정 등... 의식적으로 한 것도 아닌데 돌아봤을 때는 이런식으로 내가, 그리고 다른 사람이 보기 쉬운 단위로 구현을 했더라구요. 그러다보니 실제 구현에 있어서도 어느정도만큼 기능을 잘라서 나눠볼지를 파악하는 센스? 같은 점이 가장 바뀐 점이지 않나 싶습니다.
왜냐하면 과거에는 잘 안 해봤으며, 현재 무의식적으로 할 만큼 영향을 받고, 앞으로도 큰 영향을 미치기에 종합적으로 이런 경험이 가장 인상깊가도 느꼈습니다