어쩌다 보니 2024년에 처음 쓰는 글이.. 한참..(대략 한달정도) 지난 우테코 최종 코딩테스트를 준비하면서 알게된 새로운 것들을 정리하는 글이다.
연말 + 연초 버프로 매우 느슨해진 상태로.. 해당 글을 작성하는 걸 거의 한달정도…? 미룬 것 같다. 그래서 이제 다시 마음을 다 잡고자! 미루고 미뤘던 블로그 글을 다시 작성해보고자 한다.
새롭게 배운 것
5시간의 시간 제한을 두고 문제를 풀면서 새롭게 알게된 개념이 존재했다. 1,2주차는 Class도 잘 모르고 Test도 잘 모를때라.. 약간 뚱땅뚱땅 돌아가는 쓰레기 코드를 작성했는데, 이번에 최종 코딩테스트를 준비하면서 해당 문제를 성장한 현 상태에서 다시 풀다보니 기존에 풀던 방식과 다르게 생각하여 새롭게 알게된 개념이 존재했다.
숫자 배열 정렬
Lotto 문제를 재풀이하면서, 숫자가 담긴 배열을 오름차순으로 정렬해야 하는 경우가 발생했다.
이때, sort()를 통해서 배열을 정렬하고자 했다. 그래서 해당 배열에 바로 sort()를 적용하였으나 정렬되지 않았다.
// 처음에 작성했던 코드
lotto.push(ticket.sort());
그래서 도대체..? 왜 정렬이 되지 않을까? 아무리 봐도 이상한 코드는 존재하지 않았다.
그래서 역시나 오늘도 등장하는 나의 친구 ChatGPT에게 해당 코드를 던지고 정렬이 되지 않는 이유를 물어봤다.
결론은, js에서 숫자를 배열할 때는 그냥 sort()만 작성해서는 안된다는 것이었다..
js에서 숫자 배열을 정렬할때는 sort((a,b)=>a-b)로 작성해야 한다.
단순하게 sort()는 문자열을 정렬할 때만 적용이 된다..
// 수정한 코드
lotto.push(ticket.sort((a, b) => a - b));
정렬 전 결과
정렬 후 결과
왜 이런 문제가 생기는 것일까?
js에서 sort()는 정렬하기 전에 배열 내부 값은 문자열로 변경하여 정렬을 하기 때문이다. 그렇기 때문에 1이 아니라 ‘1’로 변경해서 정렬을 한다. 숫자를 문자열로 변경하여 정렬을 진행하면 가장 첫번째 숫자(문자)의 크기로 정렬을 진행한다.
예를 들어,
[1,200,3,100]의 배열이 존재하고 여기에 sort()함수를 적용하면 결과는 [1,100,200,3]으로 정렬된다.
그렇기 때문에 우리가 숫자 배열을 정렬할때는 꼭! 위에서 설명한 방식으로 정렬을 해야 한다.
sort((a,b)=>a-b)는 무슨 의미일까?
(a,b)는 인자로, 정렬 기준을 나타내는 콜백함수이다.
a와 b로 다음과 같은 규칙을 통해 숫자 배열을 정렬한다.
a - b를 진행한다. 이때,
- a가 b보다 작으면 음수(-) 반환
- a가 b보다 크면 양수(+) 반환
- a가 b와 같으면 0을 반환
예를 들어보자!
[1,10,5]의 배열이 존재한다.
- 1 - 10 = -9 => 음수이므로 그대로
- 10 - 5 = 5 => 양수이므로 둘이 순서 바꿈
[1,5,10]
- 5 - 10 = -5 => 음수이므로 그대로
나는 위와 같이 이해했다.
즉, 버블 정렬의 방식으로 숫자 배열 정렬한다! 라고 이해하니 한번에 이해가 됐다.
🔥 console에 직접 찍어본 결과 첫 a는 1, b는 10이 아니라 a는 10, b는 1이 된다!
근데, 똑같이 버블정렬로 이해하면 되는 것 같다. 단지 결과가 양수일 때 순서를 바꿀 것인지, 음수일 때 순서를 바꿀 것인지 정도의 차이가 생긴다.
오류 수정
자동차 경주를 다시 문제 풀이 하면서 발견한.. 엄청나게 중요하고 절대 하면 안되는 실수를 저질렀다..ㅎ
그건 바로.. 함수를 사용할 때 결과값을 반환하지 않는 것…!!!
문제의 코드
위 코드에서 뭐가 문제인지 알겠는가…?ㅎ..
return이 존재하지 않아서 반환값이 없어서 문제가 생겼다.
이런.. 멍청한.. 실수를 저질렀다.. 정말.. 왜 값이 안나오지? 이러고 엄청나게 삽질을 했는데, 연습을 하다가 자주 나올 것 같은 실수를 발견해서 정말 다행이었다.
수정한 코드
뭐가 문제인지를 찾아준 이번에도 한건 해주시는 ChatGPT…
해당 실수는 생각보다 자주 나올 수 있다고 생각한다.
실제로 예전에도 이런 실수를 한번 저질렀었는데.. 이번에 또.. 해버렸다ㅜ.. 시간이 좀 지났다고 그새 까먹었냐..후..
마무리
드디어 우테코 프리코스 + 최종 코딩테스트에 관한 모든 글을 작성했다. 앞으로 우테코 관련 항목은 우아한 테크 코스를 진행하면서 새롭게 배운 점들이 올라올 것 같은데.. 열심히 블로그를 작성해야겠다..!
참고자료
자바스크립트 배열 정렬: sort()와 toSorted() 함수
자바스크립트 문자열 & 숫자 정렬하기
2024년 9월 13일 추가 글
안녕하세요! 우테코 프론트엔드 6기로 활동중인 닉네임 소하입니다.
곧 있으면 7기를 모집한다는 이야기를 들어 오랜만에 작년에 작성했던 우테코 최종 합격 후기 글을 다시 읽게 되었습니다. 우테코를 다니면서 이전에 작성했던 것과 다른 부분이 존재하는 것을 발견했습니다. 따라서 현재 다니면서 느낀 부분들은 해당 형태로 추가 코멘트를 남겨두겠습니다.
또한, 우테코를 준비하시는 분에게 도움을 드리고자 합니다. 우테코를 준비하면서 궁금하신 점이 있으시다면 해당 메일 soy2302ten@naver.com로 보내주세요!
부족한 글 읽어주셔서 감사합니다 :)
글을 본격적으로 작성하기에 앞서, 미래에 우테코를 들어오고자 하는 이에게 도움이 되고자 이 글을 작성한다.
특히 프론트엔드를 준비하는 이에게 많은 도움을 주고 싶다.
백엔드는 합격 후기나 준비 방법이 많이 작성되어있지만, 프론트엔드는 백엔드에 비해 글이 많이 부족하다고 느꼈다. (실제 모집 인원과 프리코스 참여 인원이 2배정도 더 많기 때문인 것 같다.)
그래서 나의 방식이 이 글을 읽는 이에게 많은 도움이 될지는 모르겠지만, 참고정도는 될테니.. 상세하게 작성해본다.
참고로.. 앞부분은 지극히 나의 감정만은 담은 글이므로 중간부터 글을 읽을 것을 추천한다.
우테코 최종 합격: 당시의 나의 감정
정말 정말 간절히 바라던 일이 일어났다..!!
1차 합격 발표 전까지만 하더라도, 최종 코테라도 가면 좋겠다. 안되더라도 정말 배운게 많은 뜻깊은 시간이었다고 생각했다. 1차 합격발표가 났을 때는, 최종 합격을 못해도 정말 만족스럽다! 라고 생각했다.
그리고 최종 코테를 보고 왔을 때는 너무 기대를 하게 되었다. 시험이 종료되었을 때, 일단 너무 합격할 것 같은 느낌이 들었고.. (근거는 없다) 다음날까지도.. 정말 합격할 것 같은 느낌이 너무 드는 것이다 ㅜ.. (근데 최종 결과가 아니라 그냥 내 감이라 이걸 누구한테 말 할수도 없고..ㅎ)
나는 생각보다 감이 좀 정확한 편인데.. 이번에도 감은 너무 좋았지만… 이런 느낌이 든것이 대학 합격 이후로 정말 오랜만이었고.. 괜히 기대했다가.. 불합격할까봐.. 김칫국을 그만 마시고, 시간을 잊고자 했다..
그리고 이게 효과가 있었는지..? 결과날이 다가올수록 불합격했을 때의 나의 모습이 너무 현실적이게 상상이 되더라.. 그래서 정말.. 기대감을 버리려고 노력했다.
그리고 대망의 12월 27일.. 결과 발표날이 왔다. 그날.. 정말 시간이 안 갔지만, 시간을 잊으려고 2시부터 유튜브보고.. 시간 확인하고..를 반복했는데, 정확히 15시. 메일 도착 알림이 왔다.
심장이 미친듯이 뛰었고, 결과가 무서웠지만 궁금증은 이길 수 없어서 바로 메일을 확인했다. 결과는!!!!
합격이었다!! ㅜㅜㅜ
진짜.. 읽고 소리지르고, 제대로 읽은게 맞나? 다시 읽고, 침대 치고.. 응원해주고 같이 결과를 기다려준 친구들에게 연락하고..
정말 내가 합격할 수 있었던 것은 내가 프리코스 기간을 열심히 한 것도 있지만, 곁에서 응원해주고 한탄 들어주고 멘탈을 잡아준 내 주변 사람들 덕분이라고 생각한다.
시험 당일에도 응원 연락해주고.. 시험 결과도 안 좋을까봐 먼저 연락못하고 기다려주던.. 신씨와 행이.. 정말 너무 고맙다!ㅜㅜ
나도 그들에게 저런 사람이 되도록 정말 많이 노력해야겠다고 다짐했다.
최종 합격 이유?
내가 최종 합격할 수 있었던 이유를 정확히는 모르겠지만.. 내가 추측하기로는 자소서 + 매주 프리코스 소감문 + 단계별 성장 때문인 것 같다.
일단 우테코는 선발 기준을 명확하게 말해주지는 않고, 성장 가능성이 있으며 우테코의 도움이 필요한 사람을 선발한다고 설명회에서 들었던 기억이 난다.
이 말은 즉?
너무 뛰어나다면, 우리의 도움이 없이도 취업을 잘 할 것 같으니 선발 대상 아님.
프리코스 미션의 난이도도 제대로 해낼 수 없는 실력이라면? 우테코 교육 기간을 따라올 수 없으므로 선발 대상 아님.
이라고 나는 이해했다.
그러니 만약 js를 한번도 해본적 없고 코딩 언어를 배워본적이 없다면? 그리고 이미 여러 프로젝트를 진행하면서 월등한 실력을 보유하고 있다면? 우테코에서 원하는 선발 대상이 아닐 수 있음을 인지하고 프리코스에 임해야 한다.
🚨 이건 나의 지극히 개인적인 생각이므로 너무 맹신하지는 말아야 한다는 점을 유의해야 한다! 🚨
개발 실력이 매우 뛰어나고 코딩 1도 안해봤어도 합격하신 분이 존재할 수 있기 때문이다. 그러니 맹신하지 말 것. 나의 추측에 기죽지 말것..
근데 나의 글을 읽고 도전하지 않을 사람이라면 결국에는 우테코에 지원하지 않았을 것이라고 생각한다.
실제로 프론트엔드 6기에는 html, css, js를 한번도 접해보지 않았음에도 합격하신 분이 존재합니다. 다만 제가 아는 분들은 컴퓨터공학 전공생이셨습니다. 즉, 코딩은 해본 적 있다는 것입니다. (하지만 프론트엔드 관련 개발 언어는 한번도 접해보신 적 없습니다.)
내가 했던 것 & Tip
우테코 합격을 위해 준비하면서 느끼고 도움이 됐던 것들 및 합격하는데 중요한 요소라고 생각했던 것들을 작성
🔗
1. 자소서 작성
2. 프리코스
3. 최종 코딩테스트 준비
자소서 작성
나는 자소서를 제출 전날 밤 10시부터 작성해서 제출 마감 30분 전에 작성을 완료하고 10분전에 제출을 했는데.. 모집 공고를 늦게 알았다 새벽 약빨로 작성해서 그런지 생각보다..? 나름 잘 작성했던 것 같다.
자소서 항목은 총 5개인데, 1번은 그냥 프로그래밍 교육 경험이 있는지?를 작성하는 것이고 나머지 4가지 항목이 중요하다.
항목별 작성 내용
-
1번 항목: 프로그래밍 교육 경험
나는 2020년도에 3개월정도 웹 개발 풀스텍 교육 경험이 존재해서 해당 교육 경험을 작성했다.
-
2번 항목: 효과적인 학습방식과 경험
내가 실제로 했던 것이고 지금도 하고 있는 방식을 작성하였고 실제로 효과적이라고 느꼈던 경험을 작성했다.
효과적인 학습 방식은 근거 자료가 존재하면서 과거부터 꾸준이 하고 있는 것으로 작성했다.
경험은 근거자료는 존재하지 않지만 느꼈던 것을 굉장히 상세하게 작성했다. 누가봐도 실제로 경험했던 것이 느껴지는, 거짓말로 지어낼 수 없을 정도의 사실성이 느껴지도록 작성했다.
-
3번 항목: 성장중 겪은 실패와 극복
해당 항목의 주제는 개발과 전혀 관련 없는 주제로 작성했다. @@한 실패가 있었지만, 다른 방향으로의 극복을 했던 경험이었다.
해당 글에 MSG를 치려면 칠 수 있었지만, 굳이 자소설을 만들지는 않았다.
예를 들어, 학생회장 당선 실패 -> 과정 -> 다음년도 학생회장 당선! 이라는 소설을 작성한 것이 아닌 당선 실패 -> 과정 -> 다른 형태의 성공(극복) 으로 작성했다. 이게 더 진정성있어 보이니까.!
그러니 굳이 거짓말을 작성하지 말고 주제를 잘 선정해서 글을 작성하면 될 것 같다.
아 그리고 이 극복 경험은 증빙할 수 있는 자료가 있으면 매우 좋을 것이라고 생각한다. 증빙자료가 없으면 이게 거짓말인지 진실인지 진정성이 떨어지게 되니까.
-
4번 항목: 오랜 시간 몰입했던 경험 그리고 도전
내가 선정한 주제는 개발과 관련된 주제였다. 하지만 굳이 개발과 관련되지 않아도, 정말 몰입해서 임했던 경험 혹은 도전이 존재한다면 해당 주제를 선정하는 것이 더 좋다고 본다.
내가 개발 주제를 선정한 이유는 몰입이란 키워드에 너무나도 적합했던 경험이 개발과 관련된 것이었기 때문이다.
그리고 해당 항목 또한 증빙자료가 존재하는 것으로 선정했다. 이 경험이 실제로 있었다는 것을 글만 읽어도 알 수 있도록 구체적인 수치를 같이 적었다. 또, 구체적으로 얻고 배웠던 점들을 작성했다.
-
5번 항목: 원하는 프로그래머 모습 + 우테코 없이 어떻게 성장할 것인지
진짜로 내가 되고 싶은 현실적인 프로그래머의 모습을 작성했다. 그리고 내가 되고 싶은 프로그래머로 성장하기 위해 어떻게 하고 있는지도 작성했다.
그리고 우테코 없이 어떻게 성장할 것인지 상세하게 작성했다. 현재 나에게 부족한 점을 알고 있었기에 해당하는 부분과 필요하다고 느꼈던 점을 개선한다는 방향으로 작성했다.
자소서 작성 팁?
-
우테코는 교육 프로그램이기에 개발자가 아닌 개발자 지망생을 뽑는 것임을 유의하여 작성한다.
-
거짓말 없이 사실적으로 작성한다.
-
해당 주제가 사실임을 증명할 수 있는 증빙자료를 적극적으로 첨부한다. (매우매우 중요한 요소라고 생각한다.)
엄청 중요한 요소는 아닐 수 있습니다. 다른 크루들과 이야기해보면서 알게 된 사실인데요. 증빙자료로 제출한 url의 view 수가 늘지 않았다고 합니다. 증빙자료를 확인하는 것까지는..? 잘 모르겠습니다.
-
주제를 선정할 때, 구체적인 수치나 결과가 존재하는 것으로 선정하는게 좋을 것 같다.
결론, 작성한 모든 것이 실제로 겪은 것임을 글만 읽어도 느낄 수 있도록 하기
가 나의 자소서 작성 팁이다.
🚨 해당 방법이 모두 옳은 것은 아님을 유의할 것! 🚨
프리코스
프리코스 1주차를 막 시작할때의 나의 실력은 react로 어느정도 개발할 수 있는 정도. 이지만 js적인 요소를 작성할때는 구글의 서칭이 무조건 필요한 정도? 였다.
예를 들자면, js로 박스를 접고 열고 하는 기능을 구현하는 것도 구글의 서칭없이는 뚝딱 할 수 없는? 정도였달까…
말 그대로 기초공사로는 철근 10개 박아야 할거 2개만 박아서 진행했던 부실공사..의 대표적인 사람.. 이었달까.
여튼, 이렇게 js에 대한 기반 지식이 매우 부족한 상태에서 프리코스를 시작하게 됐다.
당시에 클래스로 코드 작성할 줄도 몰랐고, MVC? 당연히ㅎ 몰랐다. 3주차 까지도 글을 읽어도 머리는 이해해도 가슴은 이해하지 못했었다.
jest로 테스트코드 작성? 강의를 들은 적은 있지만, 역시나 2주차까지는 제대로 작성하지도 못했다. (2주차에 테스트코드 작성한걸 보면 좀 웃긴다ㅋ 누가봐도 이해못한 티 엄청 나더라..ㅎ)
4주간 프리코스를 진행하면서 매우 많은 배움과 성장을 몸소 느낄 수 있었다. 그리고 성장해나가는 나의 모습이 너무 뿌듯하더라. 주변에 프리코스 해보는 걸 추천하고 다녔다.
미션 기능 구현
공식 문서는 꼭 지키고 적용하기
매주 프리코스를 꾸준히! 임하는 것은 너무나도 필수적인 것이라 각설하고, 초반에는 잘 못해도 괜찮다. 요구하는 조건에 맞게 기능이 돌아가기만 하면 된다고 생각한다. 그 대신, 우테코에서 제시한 README는 무조건 지키려고 노력해야 한다.
그리고 매주 프리코스가 종료되면 단체 피드백 문서를 보내주는데, 피드백 문서에 작성된 내용을 추가하여 다음 주차 미션을 진행하는 것이 좋다. 그래야 성장할 수 있고, 성장하고 있다는 것이 보이기 때문이다.
예제 테스트코드가 통과되는 ‘돌아가는 쓰레기’ 만들기
기능을 구현할 때, 깔끔하게 작성하는 것도 너무 중요하지만! 일단 ApplicationTest 코드가 통과되도록 하는 것이 제일 중요하다.
해당 테스트코드가 통과되어야, 우테코 홈페이지의 예제 테스트코드도 통과된다.
그러니 일단 예제 테스트가 통과되게 한 후, 리팩토링을 하는 것이 좋다고 생각한다.
+ 하지만 처음부터 구조를 잘 짜서 작성하는 것이 제일 베스트이다. 강의를 보고 따라서 개발하는 것이 아닌 오로지 자신만의 힘으로 개발하는 것이 처음이라면, 구조를 잘 작성하는 것이 처음에는 힘들 것이다. 그러니 일단 기능이 돌아가게 코드를 작성해라.
우테코 내에서 정말 많이 들었던 이야기입니다. 돌아가는 쓰레기를 만들어라. 일단 요구조건을 충족하는 쓰레기를 만드세요. 그리고 나서 욕심을 부려 리팩토링 하세요. 우리에게는 시간제한이 존재합니다. 이 점을 유의하세요!
처음부터 구조를 잘 짜서 작성하는 것이 좋기는 합니다. 그래야 개발을 하면서 내가 뭘 작성했지?라는 생각을 줄일 수 있습니다. 어느정도 구조를 잡고 시작하는 것이 좋지만 완벽하게 짜려고 하지는 마세요. 어차피 수정하게 됩니다..
다른 사람의 코드 읽기
한 주차의 미션이 종료되면 다른 사람들의 코드를 볼 수 있는데, 꼭! 볼 것을 강력히 추천한다. 나의 경우 클래스를 1도.. 사용할 줄 모르는 사람이었지만, 다른 분들이 클래스를 사용하여 작성한 코드를 참고하면서 성장해나갔다. 프리코스에서 새롭게 배운 대부분은 다른 분들의 코드를 읽으면서 알게 되었다.
프리코스를 같이 진행하는 잘하는 분의 코드를 읽는것이 매우 큰 도움이 되는 이유는, 일단 나와 같은 미션을 앞으로 내가 성장해야 할 방향으로 이미 작성해둔 코드이기 때문이다.
구글에서 서칭을 통해 클래스를 배우는 것이 머리로는 이해가 됐지만 이 내용을 실제로 미션에 적용하려고 하면 어떻게 해야할지 감이 잘 안잡혔다.
이때, 다른 분의 코드를 보면 @@한 개념을 &&한 방식으로 사용하고 있다는 것을 알게 된다. 이게 여러 사람들이 &&한 방식으로 사용하고 있다면? @@한 개념은 &&한 방식으로 사용하면 된다는 것이다!
이런 식으로 적용해야 하는 방식을 조금 더 쉽게 이해할 수 있기 때문에 매우매우 추천한다. 또한 비효율적인 방식으로 작성하던 것도 효율적인 방식으로 작성하는 법을 알게됨으로 코드리뷰를 하지 않더라도 다른 사람의 코드를 읽는 것은 매우 중요하다.
+ 코드리뷰를 하면 너무 좋다! 하지만 나처럼 못하겠는 사람들도 있을 것이다. 그런 사람들은 꼭! 잘하는 다른 미션 제출자들의 여러 코드를 읽고 이해하면서 성장하도록 하자.
이건 이때나 지금이나 동일합니다. 다른 사람의 코드는... 꼭 읽으세요!! 남의 코드를 읽는 것 또한 개발 능력을 향상시킵니다. 다른 사람의 코드를 이해하는 과정이 개발 능력 향상에 크다고 생각합니다.
소감문
예제 테스트를 성공시키는 것도 중요하지만 소감문을 잘 작성하는 것 또한 중요하다고 생각한다.
다른 사람들은 어떤 방식으로 작성했는지는 모르겠지만.. 나는 다음과 같은 방식으로 작성했다.
-
새롭게 배운 점
인터넷의 글을 복붙이 아닌 내가 이해한 방식으로 작성
-
미션을 진행하면서 발생한 에러 및 해결한 방법
@@한 에러가 발생했었고 $$한 것이 문제 였으며, ##한 방식으로 해결하였고 \%\%한 것을 새롭게 배웠다. 형식으로 작성했다.
-
해당 미션을 종료하면서의 최종 소감
미션을 진행하면서 느꼈던 감정들을 작성했다. 해당 부분은 굳이 작성하지 않아도 된다고 생각한다. 나는 내가 감정을 서술하는 것을 좋아하기에 매번 작성했었다.
소감문의 글자수는 매우 넉넉하고 양식이 존재하지 않기 때문에 자신의 스타일에 맞춰서 작성하면 된다. 대신에 내가 해당 미션을 통해 이만큼 성장했다! 가 느껴져야 한다고 생각한다.
어떤 방식으로 작성하던 간에 해당 요소만 잘 들어나면 된다고 생각한다.
그리고 어떤 분들은 블로그에 작성하고 해당 글의 링크를 소감문란에 적었다고 했는데, 나는 그냥 소감문에 글만 제출했다.
내 블로그의 ‘프리코스 복기’를 작성한 것이 있는데, 이게 소감문의 내용에 이미지와 살을 더 붙여서 작성한 것이다.
처음부터 블로그에 작성해서 해당 링크를 제출해도 되지만, ‘소감문 박스’와 글자수 제한이 존재하는 의미가 없어진다고 생각해서 (그리고 읽는 사람이 링크 접속해서 읽는 건 귀찮을 것 같아서) 소감문에는 글만 작성하여 제출했다.
하지만 우테코측에서 소감문에 링크를 넣어도 된다고는 했다.
+ 내가 작성한 소감문이 궁금하다면 프리코스 복기 글을 읽으면 된다. 큰 틀은 그대로이며 작성한 내용 또한 약간의 추가 글과 이미지만 추가하였다.
저는 소감문을 통해 성장을 보여줬기 때문에 우테코에 합격할 수 있었다고 지금도 동일한 생각입니다. 하지만, 이게 모든 사람에게 동일하게 중요한 요소였는가?는 잘 모르겠습니다.. 일단 자소서든 소감문이든 '성장할 수 있는 사람'임을 보여주는 것이 가장 중요합니다.
요약
-
4주차까지 프리코스를 완주하는 것이 가장 중요하다.
-
에어비앤비 스타일가이드는 한번 정독하고 갈 것. 그리고 틈틈이 가이드를 읽으면서 확인해라.
-
피드백 문서(공식 문서 등)를 잘 읽고 꼭! 적용하여 미션을 진행하는 것이 좋다.
-
일단 예제 테스트가 통과되도록 기능을 구현하자.
-
다른 사람의 코드를 읽는 것을 강추한다.
-
소감문에 성장한 내용을 잘 담는 것이 좋다.
+ 매주 프리코스를 임하는게 가장 중요한 이유는 점점 미션을 제출하는 사람의 수가 줄어든다는 것이다. 첫 미션을 fork한 인원이 912명인데, 미션 제출 인원이 758-698-615-???로 계속 줄어들었다.
마지막 4주차 미션이었던 크리스마스 프로모션의 경우는 이전과 달리 생각할 것과 구현해야 할 것이 더욱 많았기에 최소 500명대로 떨어졌을 것이라고 생각한다.
프론트엔드의 경우 자소서를 제출한 인원이 대략 1000명이라하고 4주차까지 미션을 제출한 인원이 500여명 정도이면, 미션만 다 완료해도 절반 안에는 든 것이다. 그러니 꼭, 프리코스는 완주해야 한다. (그리고 개인의 성장이 엄청나기에 무조건 끝까지 하는 것을 강력히 추천한다.)
지금도 여전히 프리코스 완주는 강추드립니다! 프리코스 기간이 너무 즐거웠다? 그럼 여러분은 우테코에 합격하고 난 후에도 끝까지 살아남으실 수 있을 겁니다..!
최종 코딩테스트 준비
1차 합격 메일을 받았다? 이제 90% 성공했다고 본다.
그러면 마지막 테스트에서 뭘 보여줘야 할까?
3주 공백 기간의 성장을 보여주자
나는 프리코스가 종료되고 3주간의 공백동안의 모습을 보여줘야 한다고 생각했다.
프리코스 기간동안 배웠던 것을 잊지 않고 여기서 더 성장했다는 것을 보여주는 것이 승부가 아닐까? 생각했다.
그래서 이전에는 적용하지 못했던 MVC 모델, 데이터 관리, 클린한 구조를 보여주고자 했다.
나는 4주차까지의 나의 성장에서 더 발전했을때의 모습이 위에서 작성한 요소들이라고 생각해서 해당 모습을 보여주고자 했던 것이다. 3주간의 공백동안의 성장으로 보여줄 요소는 사람마다 다르기에 자신에게 맞는 성장 요소를 보여주면 된다.
5시간 기능 구현 연습
준비 시간이 아무리 없어도 이건 꼭 해야 한다.
5시간이 시간제한이 있는 상태에서 기능을 구현하는 것은 생각보다 쉽지 않다. 심지어 처음 보는 문제를 이해하고 기능을 구현하는 것은 더더욱 어렵다.
그렇기에 지난 1~4주차의 미션들을 5시간 시간제한을 두고 꼭 문제를 풀어보자. 나는 시간이 부족해서 1~3주차만 풀이했는데, 이 연습이 없었더라면.. 시간안에 시험날 기능을 구현할 수 없었을 것이다.
다른 분들을 보면 지난 최종코딩테스트 문제 + 지난 프리코스 문제까지 풀이하셨던데, 나는 4주차 미션도 연습하지 못했기 때문에 ^^.. 지난 문제들을 풀 시간은 없었다.
그래도 지난 최종 코딩테스트 문제정도는 풀어보는 것도 괜찮은 것 같다. 전혀 알지 못하는 새로운 문제를 5시간안에 풀이하는 것이기에 실전 연습을 하는데 많은 도움이 될것이다.
하지만 약간 도움이 안될수도 있는 요소가 존재한다. 다음은 모르겠지만 이번 6기 프리코스와 5기 프리코스에서 사용하는 라이브러리 내용이 달랐고, 주로 사용을 요구하는 API도 달랐다. 그렇기에 오히려 별 도움이 안될수도 있다.
그리고 최종 코딩테스트의 난이도는 4주차 프리코스 미션과 유사한 것 같다. 복잡하기는 4주차 미션이 더 복잡하지만 5시간의 시간제한이 존재하는 것을 생각했을 때, 최종 코딩테스트와 난이도가 유사하면서 약간 더 쉽다. (쉽다는 것은 시간이 넉넉하기에 쉽다는 것. 4주차 미션에 5시간제한이 존재하고 처음 보는 문제였다면 훨씬 어려웠을 것이다.)
요약
- 프리코스 1~4주차는 5시간 시간 제한을 두고 꼭 연습할 것
- 이전 기수의 문제는 풀어도 그만 안풀어도 그만
- 최종 코딩테스트 난이도는 4주차 프리코스 미션과 유사한 듯?
시간 단축 파일 작성
최종 코딩테스트는 5시간의 시간제한이 존재하기 때문에 5분이라도 시간을 줄이고자, 기초적으로 무조건 사용하는 것들을 담은 파일을 작성했다.
파일의 구성은 다음과 같다.
-
자주하는 실수 및 해결방법
사전에 연습하면서 했던 실수, 프리코스 기간 자주 행하던 실수, 필수적인 제출 요구사항 확인
- 구현하면서 주의할 사항
- 제출하기전 주의할 사항
-
기본 초기 설정
git clone, node 버전 변경, .gitignore 수정 등
-
기능 구현 전, 상기시킬 내용
기능 구현 순서 등
-
README.md 구조
바로 복붙해서 시간을 절약할 수 있도록
-
프로젝트 폴더 구조
빠트리는 것이 없게 하여 실수를 줄이기 위함
-
prettier 및 eslint 파일 내용
시간 절약을 할 수 있음
-
자주 사용하는 코드
서칭 시간을 줄이고 잘 변경되지 않는 기본 코드를 작성함으로 시간을 단축
실제 사용했던 파일 이미지
글을 마치며
도움이 될만한 것들과 생각나는 것을 막 작성하다 보니.. 글이 좀 많이 길어진 것 같다. 하지만 다른 사람들에게 정말 도움이 될 것 같다는 요소들만 선별해서 작성했다는 점.. 이해 바라며.. 가독성이 떨어지더라도 이해해달라..ㅎ;
내가 누군가의 글을 읽고 준비하는데 도움이 됐듯이 나도 우테코 합격을 원하는 다른 사람들에게 도움이 되고자 정성을 들여 작성했다. 3시간동안 작성했다..
2023년 하반기, 주변인이 봐도 우테코 프리코스를 열심히 임했을음 알아줄 정도로 우테코에 합격하고 싶은 마음이 간절했다. 간절한만큼 열심히 임한다면 좋은 결과가 나올 것이라고 생각한다.
우테코 합격이 다가 아니지만, 개발자로서 나아가기 위한 발판에 많은 변화와 도움이 될 것임을 의심치 않기에 2024년이 굉장히 기대된다. 다른 사람도 이 기쁨과 기대감을 가질 수 있도록 해당 글이 도움이 되기를 바란다.
굉장히 행복한 2024년을 보내고 있습니다. 개발 실력이나 인간으로서의 내면 또한 많은 성장을 이뤄냈습니다. 아직도 취업할 수 있을까 걱정이 많지만, 앞으로의 미래가 두렵지는 않습니다. 여러분도 우테코에서 좋은 사람들과 환경, 생활을 겪으셨으면 좋겠습니다. 화이팅!
1차 합격, 최종 코딩테스트
메일, 12월 11일
12월 16일 잠실에 있는 우테코 캠퍼스에서 최종 코딩테스트를 보러 가게 됐다. 사실 프리코스가 종료되고 1차 합격 결과까지 대략 한 달의 공백이 존재했기 때문에, 1차 결과 발표날을 약간 잊고 살았다. 당일에 달력에 적어둔 걸 보고 ‘오늘이 1차 발표날이군.’ 정도만 인식했다. 그리고 대망의 15시가 되었고, 1차 합격 발표 메일을 받게 되었다.
준비, 12월 12일 ~ 15일
1차 합격 발표를 받고 5일의 시간이 존재했다. (1차 합격 메일은 12월 11일에 받았고 시험은 12월 16일이었다.)
12일에 대학교 마지막 시험이 남아있었기에 11일은 기말고사 공부를 하고 그 주에 해당하던 모든 약속을 취소하고.. 코딩테스트 공부에 매진했다.
최종 코딩테스트 준비 과정은 해당 글에서 확인할 수 있다.
최종 코딩테스트, 12월 16일
최종 코딩테스트날 눈이 펑펑 내리고 갑자기 한파가 시작된 날이었다. 마치 수능을 치러 가는 것 같았다. 잠실로 가는 버스를 타고 근처 스타벅스에서 음료를 사서 시간을 때웠다. 너무 긴장이 돼서… 아무것도 하지 않고 그냥 노래 들으면서 커피를 마셨다. 스타벅스에 사람이 굉장히 많았는데, 노트북 보는 사람이 많았다. 확실하진 않지만 나처럼 우테코 최종 코테 시험을 보러 온 사람들 같았다.
카페에서 조금 시간을 보내다가 우테코 잠실 캠퍼스에 미리 갔다. 먼저 온 사람들이 생각보다 많았고, 복도에서 대기하다가 입실시간에 맞춰 신분증 확인을 진행한 후 시험장에 입실했다.
신분증 확인 후, 배민 굿즈를 받았다. 작은 노트와 펜 2개, 스티커였다. 펜에 적혀있는 ‘어머, 펜이에요~’가 센스 넘친다고 생각했다.
시험생들을 위해 간식과 물도 준비되어있었다. 안 먹을 줄 알았는데.. 시험 시간이 5시간이 되다보니 나도 모르게 긴장이 완전히 풀리면서 배가 고파져서.. 간식을 가져와서 먹었던 기억이 난다.
약간 긴장은 됐으나 최대한 긴장을 풀려고 노력했다. 노래 듣고 음료 마시면서 릴렉스 하려고 했고 캠퍼스도 구경했다. (코치님들이 언제 올 수 있을지 모르니 맘껏 구경하라고 하셨다.)
인터넷 연결로 인해 시험시간이 30분 늦춰져서 다시 긴장이 올라올뻔 했으나, 문제 해결 후 그냥 대기하는 시간이 주어지다보니 긴장이 완전히 풀렸다. 오죽했으면, 시험보면서 노래 듣는데 리듬에 맞춰서 몸을 움직였다..ㅎ; 그래서 덕분에 온전한 실력이 잘 나온 것 같다.
시험 종료 1시간 전에 한가지 기능 구현 미완성과.. 에러로 인해.. 갑자기 긴장이 엄청 됐지만.. 나의 영원한 친구 Chat GPT 덕분에 에러를 잘 찾아서 해결할 수 있었다.. 기능 구현도 잘 완료했고!
시험을 치르며
OnCall 미션 기능 구현
5시간의 제한 시간동안 해당 문제를 테스트코드까지 완벽하게 작성하기에는 다소 시간이 부족했다. 난이도도 약간 있었다고 생각이 든다. 문제 설명이 굉장히 길고, 기능을 이해하는데도 시간이 좀 걸리는 문제였다고 생각이 든다. 그리고 개발자가 생각해야 할 요소가 다분히 존재하는 문제인 것 같다.
최종 코딩테스트: 개발자 비상근무(oncall) Repository
그래도 나의 목표인 예제 테스트는 잘 실행을 완료할 수 있었다. 이것으로 굉장히 만족한다.
에러 해결
EmergencyShiftNumber 클래스를 실행하면 weekdays와 holidys의 값이 이상하게 변경되는 문제 (sort의 잘못된 사용)
이번 미션을 진행하면서 해결하는데 가장 오래 걸린 문제였다.
값 에러 이유
#validateListSameValue(weekdays, holidays)를 통해 두 배열의 입력된 값이 동일한지 확인한다. 이때, 동일한 값인지 빠르게 확인하고자 sort()를 활용하였다. weekdays와 holidays를 sort하여 정렬하면 두 배열의 값과 순서가 모두 동일하게 될 것이다. 따라서 sort를 사용하였다. 이게 에러의 원인이었다.
sort 할때 처음에 그냥 week.sort()로 했다. 이러면 안된다.. sort()를 사용하면 원본 배열에도 영향을 준다.
나의 코드는 const week = weekdays.sort(); 였는데, week에만 정렬되는 것이 아닌 weekdays에도 sort()가 적용되어 해당 클래스를 사용하고 난 후, weekdays를 출력하면 값이 변경됐던 것이다.
EmergencyShiftNumberContorller 코드
에러 해결
에러를 해결하는 방법은 구조분해할당을 하여 weekdays의 모든 값을 구조분해하여 새롭게 배열을 생성하고 그 배열을 정렬하면 된다.
const week = [...weekdays].sort();를 해야 원하는 결과로 잘 출력된다. 이렇게 하면 원본 배열인 weekdays에도 영향을 주지 않고 유효성검사를 할 수 있다!
EmergencyShiftNumber 클래스의 #validateListSameValue()
최종 코딩테스트 마친 소감
시험 메일에서 언급했던 것 처럼. 돌아가는 쓰레기를… 만든 것 같다.ㅎ
하지만, 일단 제한 시간이 주어진 이상. 어떻게든 돌아가게 기능을 구현하는 것이 중요하다고 생각한다. 그래서 기존에는 기능을 구현하면서 테스트코드도 바로 작성했었는데, 최종 코딩테스트에서도 이렇게 하면 시간이 매우 부족할 것으로 예상됐다. 그래서 테스트코드는 쿨하게 버리고. 일단은 기능 구현을 중점으로 두었다.
그리고 이 선택은 잘 한 선택이었다. 테스트코드도 작성하면서 기능을 구현했더라면 제 시간에 맞춰서 기능을 완성할 수 없었을 것이다.. 종료 30분전에 기능 구현을 완료했었고, 남은 시간에 how to solve와 테스트코드 하나를 작성하니.. 시간이 종료되었다!
선택과 집중을 잘 한 것 같다.
시험을 종료한 후에 느낌이 굉장히 좋았다. 그래서 N인 나는 집 가는 버스에서 행복회로를 오지게 돌리면서 갔다..
일단 전날부터 너무 걱정됐던 ‘5시간안에 기능 구현 완료’를 못해서 예제 테스트 실패하면 어쩌지? 예제 테스트만 성공시키자.를 목표로 잡았는데, 해당 목표를 이룰 수 있어서 너무 만족스러웠다.
기능 구현도 생각보다 잘 되었다. 비록 테스트코드는 거의 작성하지 못했고 how to solve도 잘 작성하지는 못한 것 같았지만, 이상하게 종료된 후에 기분이 굉장히 홀가분하고 합격할 것 같은 느낌이 확 들었다.
그래서 일까.. 결과 및 준비과정은…! 여기서.
자전거 주행으로 그리는 관광 컨텐츠 개발/공유 서비스
내가 개발한 페이지
코스개발페이지
마이페이지
프로젝트를 진행하며
타 파트와의 소통의 중요성
드로맵은 팀프로젝트로 진행했기 때문에, 다른 파트 팀원과의 소통또한 중요했다. 타 파트와 소통할 때 어려운점들을 느꼈는데 프로젝트가 종료하고 나서 이렇게 개선하면 될 것 같은 사항을 적어본다.
-
상세히 물어보기
잘 모르겠거나 이해가 안되는 것은 상세하게 물어보자.
내가 말하는 것 혹은 다른 파트원이 말하는 내용들이 이해가 안 갈수도 있다. 내가 엄청난 관심을 가진 분야가 아니면 기존 지식으로 이해하는 것에 한계가 존재하더라. 따라서, 조그만한 내용도 이해가 안되면 자세히! 풀어서 설명해줄 수 있는지 물어볼 수 있는 용기가 필요하다.
타 파트의 진행 상황을 상세하게 물어봐야 한다.
매주 단체 회의를 진행했는데 회의 시간은 항상 30분을 넘기지 않았었다. 당시에는 회의가 빨리 끝나서 마냥 좋았었는데, 끝나고 보니 이 점을 개선해야 했다고 느껴졌다.
단체 회의때 각 파트의 진행 사항을 이야기 하는데, 단순하게 ‘저희 파트는 ~ 했습니다.’하고 끝났다. 이렇게 간단하게 말하고 끝낼 것이 아니라 진행했던 결과까지 같이 확인하면서 구체적으로 뭘 했는지까지 설명해야 했다.
예를 들자면, API 명세서를 작성했다고 치자. 그럼 작성한 명세서와 함께 이건 어떤 데이터를 뜻하고 값으로는 뭐가 들어올 수 있는지 등을 말이다..! 그렇다.. API 명세서를 이해하지 못해서 고생했었다.
회의때, 명세서를 작성했다고 했을 때 같이 보면서 이야기했었더라면.. 명세서를 보고 상세히 물어봤더라면.. 라는 아쉬움이 많이 남는다.
-
잦은 소통의 필요
다른 파트와 소통을 자주, 많이 해야 한다.
직접 느끼게 된 계기는 API 명세서였다. 해당 프로젝트는 ‘스웨거(Swagger)’를 사용하였는데, 처음에 이게 뭔지 몰라서 (이때 처음 들었다) 회의를 하면서 찾아본 기억이 난다.
처음 듣고 사용하게 된 것이라 찾아보면서 사용하느라 애를 먹기도 했지만, 가장 큰 문제는 이게 아니었다.
백엔드 측에서 작성해둔 데이터 명이 뭘 뜻하는지 알 수가 없다는 것이 가장 큰 문제였다. 어떤 것은 눈치껏 데이터 값을 보고 알 수 있었지만, 도저히 이해되지 않는 데이터들이 존재했다. 또한, 프론트에서 받으려는 데이터의 갯수와 종류가 API 명세서에 적혀있는 것과 달랐다.
처음에 API를 명세서를 이해하느라 필요없는 시간을 많이 허비했다. 심지어 겨우 이해했다고 생각했지만, 작성한 의도와 다르게 이해를 해버려서 카카오로그인 토큰이 발급되지 않은 줄 알고 헛 고생을 했던 기억이 새록새록하다.
이런 문제가 발생했을 때, 회의에서만 물어볼게 아니라 메세지라도 지속적으로 물어봤다면 시간을 낭비할 필요가 없었을 것이다.
그렇게 하지 못했던 것이 프로젝트를 종료하고 나서 가장 아쉬웠던 것으로 기억된다.
같은 파트원과의 소통
‘드로맵’ 프로젝트를 진행하게 되면서 프론트엔드 팀장을 맡게 되었다. 프론트엔드 파트 회의 진행 및 의견 수렴, 일정 조정, 파트 분배 등을 일을 했다. 프로젝트가 종료된 후, 이렇게 팀장의 역할을 했었다면 더 좋았을 것 같은 점들을 적어본다.
-
진행 상황 발표
각자의 진행 상황은 상세히 발표하자.
파트 회의를 진행하면서 각자 해와야 했던 일들을 같이 확인하면서 발표를 진행하지 않았던 것이 아쉬운 점으로 기억된다.
회의 시작 시간 전에 깃허브에 push가 되어있는지 확인하고 회의에 들어갔었다. 그리고 회의때, 간단하게 ‘@@님 ~~하셨죠? 깃허브에 push를 안하셨는데 해주세요’ 정도만 하고 넘어갔었다. 이러면 안됐었다…!ㅜ
깃허브에 올려있지 않으니, 정확히 했는지 안했는지는 해당 파트원의 말만 믿고 넘어갔었다.
이렇게 말만으로 넘어갈 것이 아니라, 같이 해당 코드 혹은 결과물을 확인하면서 어떻게 구현했는지 꼭 같이 확인을 해야 했다.
그래야 우리 파트의 진행 상황을 정확하게 파악할 수 있고, 정기 회의때 정확한 진척 상황을 PM에게 말할 수 있다.
그러니 다음에는 꼭, 각자의 진행 상황을 발표하고 토의하는 시간을 가져야 겠다고 생각했다.
-
코드 리뷰
구현한 코드를 팀원들과 리뷰하자.
나중에야 알게된 것인데, 코드 리뷰는 정말 중요하다. 이론적으로만 리뷰가 필요하다는 것은 알고 있었다. 하지만 이게 왜 필요한 것일지는 느끼지 못했다.
이번 프로젝트를 진행하면서 왜 리뷰가 필요한지를 느꼈다.
파트원들과 코드리뷰를 가져야, 다른 사람이 구현한 기능을 사용할 때 원활하게 활용할 수 있다.
예를 들어 내가 select box를 구현했다. 이에 대한 props로 locataion과 title이 존재한다. 내가 이 props가 뭔지 설명하지 않으면, 다른 파트원이 해당 select box 컴포넌트를 사용할 때 뭘 뜻하는 건지 한번에 이해하기 어려울 것이다.
해당 컴포넌트는 어떻게 사용하는지 코드리뷰를 하면서 설명했다면, 타 파트원이 구현을 하면서 해당 컴포넌트를 사용할 때 쉽게 이해하고 사용할 수 있을 것이다.
또한, 코드리뷰를 통해 기능을 개선해 나갈 수 있다.
본인이 아무리 뛰어난 코딩 실력을 가졌다고 해도, 부족한 점은 존재할 것이다. 내가 작성한 코드를 다른 팀원이 리뷰하면서 더 좋게 발전할 수 있는 사항을 찾아줄 수 있다. 또한, 내가 이상하게 혹은 잘 못 작성한 것들도 찾아 수정할 수 있을 것이다.
항상 코딩을 하면서 느낀 것이지만, 내가 작성한 것은 잘못된 점을 찾기 어렵다. 그렇기에 제3자에게 리뷰를 받으면서 개선사항을 찾는 것이 중요하다고 생각한다.
프론트엔드 팀장을 맡으면서 확실하게 짚고 넘어가거나 프로젝트의 성장을 위해 이끌어나가지 못한 것 같아서 아쉽다.
위에 작성한 것처럼 했더라면, 일의 진행도 원활했을 것이고 코드리뷰를 통해 피드백을 받아 수정해나가면서 보다 완성도가 높은 프로젝트가 만들어질 수 있었을 것이라고 생각한다.
프로젝트를 종료하며
여러모로 아쉬움이 많이 남는 프로젝트다.
첫 시작부터 일정이 많이 밀린채로 시작했고, 종료 또한 완전한 완성이 아닌 상태에서 종료하게 되었다. 그래서 정말 많은 아쉬움이 남는 프로젝트인 것 같다.
처음으로 프로젝트의 프론트엔드 파트 팀장을 맡게 되면서 팀장의 역할을 제대로 하지 못한 것 같아, 같은 파트원들에게도 미안함이 든다. 더 잘 챙기고 이끌어 나갔더라면 더 좋은 결과물을 만들어 낼 수 있지 않았을까 생각이 든다.
그리고 무언가 불만사항이 있다면, 나는 그 불만사항을 해결하기 위해서 노력하였는가? 혹은 무조건 내가 다 수습하려고만 하지 않았는가?를 생각해야 할 것 같다.
내가 무조건 다 수습하는 것도 좋지 않고, 불만만 토로하고 해결을 위해 노력하지 않는 것도 좋지 않다는 것을 느꼈다.
혼자서 할 것이 아니라 이건 ‘팀’ 프로젝트니까 같이 해결해 나가고, 소통을 통해 같이 서로의 문제점을 개선해나가는 것이 중요한 것 같다.
여러모로 아쉬움은 많이 남은 프로젝트였지만, 해당 프로젝트를 진행하면서 React의 활용 능력이나 서버와의 통신, Kakao API를 활용하는 등의 능력이 많이 향상됐다는 것을 느낄 수 있는 프로젝트였다.
예전에 Kakao API를 연결한다고 애를 많이 먹었는데.. 이번에는 내가 생각한 것 보다 굉장히 빠르게 기능을 구현할 수 있었다.
나의 성장을 확인할 수 있었던 프로젝트였다.
다음번에는 좀 더 성장하여 이번에 아쉬웠던 점들을 개선하여 프로젝트를 진행하고 싶다. 성장하는 개발자가 되자.
모든 프리코스가 끝나고 이제야 작성하는 약간 늦은 2주차 프리코스 복기이다.
다 끝나고 진행해서 까먹은 개념도 존재할 것이고, 해당 복기로 인해 당시의 내 코드를 돌아볼 수 있기에 조금 늦게 작성하지만 안 적는 것 보단 낫다고 생각해서 지금이라도 작성해본다.
해당 글은 당시에 내가 작성했던 소감문을 바탕으로 작성했다.
2주차: 자동차 경주 Repository
2주차 미션은 1주차 미션의 코드리뷰를 통해 새롭게 알게된 개념들을 적극 반영하여 구현하였다. 확실히 이전보다 코드를 읽는데 아주 약간은..! 나아진 듯 싶다.
리뷰받은 내용 반영
고차함수 사용하기
1주차 코드리뷰에서 고차함수를 사용해보는 것도 좋다는 피드백을 받았다. 그전에는 for이나 while을 통해 단순히 코드를 작성했었다. 코드리뷰를 통해 고차함수가 있다는 것을 알았고 for을 사용하는 것 보다 코드가 더 간단해질 수 있다는 것을 알게되었다. 그래서 이번 2주차에는 고차함수인 filter, map, forEach을 사용하여 기능을 구현했다.
-
filter를 사용하여 값 걸러내기
자동차의 이름을 입력받을 때, 5글자 이상이거나 영어나 한글이 아니면 레이싱을 진행할 수 없도록 했다. 이때, 해당 조건에 맞는 값들만 걸러내기 위해서 filter을 사용했다.
-
map을 사용하여 입력받은 자동차 이름의 수만큼 배열에 값(0) 생성하기
우승자를 찾기 위해 입력받은 자동차의 이름의 수만큼 0의 값이 존재하는 배열이 필요했다. 이때 map을 사용하여 입력받은 자동차의 값을 x로 하여 0의 값을 반환하도록 해서, 자동차의 수 만큼 0의 값을 갖고 있는 배열을 생성했다.
-
forEach를 사용하여 배열 값 변경하기
forEach을 사용하여 입력받은 자동차의 이름들을 이름 에서 이름 : 의 형태로 배열의 값을 변경했다.
첫번째 인수(car)를 통해 각 자동차의 이름을 받고 두번째 인수(idx)를 통해 해당 값의 위치를 활용했다.
또한 우승자의 이름을 담은 배열을 생성할 때 forEach를 사용했다. 자세한 설명은 뒤에서!
Set을 사용하여 중복 제거
1주차 코드리뷰 중 Set을 사용하여 중복을 제거하는 것을 추천하는 내용이 있었다. 그래서 사용하게 될 기회가 있어서 Set을 활용해보았다.
자동차 이름을 입력받을 때, 중복된 이름은 입력받지 않도록 처리해야 했다. 이때 자동차의 이름을 담은 배열의 길이와 Set을 사용하여 중복을 제거한 자동차 이름을 담은 배열의 길이를 비교하여 중복된 값이 존재하는지 확인했다.
이 과정을 통해 추가로 알게된 것은 Set의 길이를 구할때는 length가 아니라 size라는 것을 알게되었다. length로 했는데 값이 안나와서.. 조콤 당황했다가 바로 찾아보고 size로 해야 한다는 것을 처음 알게 되었다.
매직넘버
코드리뷰를 통해 매직넘버의 개념을 처음 알게 되었다. 1주차에서는 boolean의 값을 1과 0 혹은 true로 단순히 명시하여 사용했었다.
매직넘버의 개념을 알게된 2주차에는 const FORWARD = true;와 같이 매직넘버를 적극 활용하여 기능을 구현했다. 사실 1주차에서 const를 사용하면 모두 upper 스네이크 케이스를 사용해야 하는 줄 알았다. 1주차 코드리뷰를 통해 그렇지 않다는 것을 알게 되었다.
매직넘버(const)일때, 해당 값은 절대 변경되지 않을 것이기에 upper 스네이크 케이스를 사용하고 단순 const를 사용할 때에는 lower 카멜케이스를 사용하면 된다는 것을 확실하게 알 수 있었다.
2주차에 새롭게 적용한 개념
정규표현식
자동차 이름을 입력받을 때, 올바르게 입력했는지 확인하기 위해 정규표현식을 사용하였다.
이전에도 정규표현식은 알았지만 작성하는 것이 어렵다고 생각하여 사용하는 것을 회피했다. 하지만, 생각보다 그리 복잡한 것도 아니었고.. 우리에겐 챗GPT가 있기 때문에 이 친구한테 부탁하면 바로 알려준ㄷ.. ^^
indexOf(‘’)
우승자의 이름만을 출력하기 위해서 득점 현황만 담고있는 배열(forwardCount)에서 가장 높은 득점의 위치(MAX_COUNT)를 찾는다. 해당 위치를 가지고 이름을 담고있는 배열(carList)에서 이름만을 출력하도록(이름 배열에 전진 실행결과도 같이 존재함) indexOf를 활용했다.
indexOf(' ')를 사용하여 첫 공백의 위치를 확인했다. carList에는 값이 soha : --------형태로 존재하는데, 첫 공백의 위치를 찾으면 0번째부터 해당 위치의-1 까지의 값만 출력하면 이름. 즉, soha만을 출력할 수 있다.
jest로 테스트코드 작성
이번 미션을 하면서 테스트 코드를 작성해보는 것은 처음이었다. 개념은 알고 있었지만 직접 기능을 구현한 코드에서 테스트 코드까지 작성하는 것은 처음이기에 좀 막막했다.
그래서 미션을 제출하는 순간에도 이렇게 테스트코드를 작성하는 것이 맞을 지 확신이 들지는 않았다. 실제로, 4주차까지 미션을 완료하고 나니.. 음 이렇게 테스트코드를 작성하는 것은 아니었다는 것을 알게되었다. 그래도 3주차부터 제대로된 테스트코드를 작성하는 방법을 알게되었다.
2주차 미션을 마치며
2주차는 1주차에 많은 역경을 견뎌서 그런지.. 1주차에 비해서 개인적인 스케줄이 많았음에도 좀 더 빨리 기능을 구현할 수 있었다. 2주차 미션을 진행하면서 개발 속도가 빨라진 것을 보고 일주일동안 정말 많은 성장을 이뤘다는 것을 몸소 느낄 수 있었다.
1주차때 애먹게 만들었던 행동도 하지 않기 위해 신경쓰고, 코드리뷰를 통해 받았던 피드백들을 적극 활용해보려고 노력했다. 이를 통해 이전보다 조금 더 코드의 가독성이 높아진 것 같다. 실제로 이때 들인 습관 덕분에 3,4주차 미션에도 잘 활용할 수 있었다.
학습 참고자료
자바스크립트 세트(Set) 완벽 가이드
Set() 함수를 이용한 중복제거 / Set 함수 객체 길이 구하기
idexOf: 문자열의 특정 문자 개수 세는 방법
코드의 매직 넘버 (Magic Number) 란 무엇일까?