[우아한 테크코스 6기 프리코스] 2주차 회고록

 

이번 주도 너무나 많은 것들을 배울 수 있어 정말 감사한 한 주였습니다! 이번 주는 코드 리뷰부터 시작해 새로운 요구 사항들을 공부하느라 정신없이 몰입할 수 있었던 한 주였는데요, 그만큼 배울 것도 정말 많았습니다! 코드 리뷰, 공통 피드백에서 정말 생각지 못했던 많은 것들을 배울 수 있었습니다. 다른 사람의 코드를 보는 것이 이렇게 중요하구나! 새삼 깨닫게 되었구요, 또 요구 사항을 분석하면서 ‘코드 가독성’과 ‘TDD’에 대한 고찰을 할 수 있었습니다! 그리고 부족한 점을 채우고자 이번에 ‘클린 아키텍처’라는 책과 함께 한 주를 보냈는데요, 지난주에 이어 ‘객체 지향’에 대해 더욱 잘 이해할 수 있었습니다. 이 과정에서 제가 어떻게 공부를 했는지 말씀 드리겠습니다😆

 

🌱난생처음 해보는 코드 리뷰

처음 해보는 코드 리뷰가 저에게 이렇게 도움이 될 줄 몰랐습니다. 다른 사람의 코드를 보는 것도 유용하고, 제 코드에 대해 피드백을 받는 것도 이렇게 유용하다니요. 새로운 시각으로 다양한 코드를 접하니 새로운 것들을 깨달을 수 있었던 경험이 되었습니다!

우선 while문과 재귀의 차이에 관해서 공부했습니다. 저는 1주 차 야구 게임 미션을 재귀를 통해 구현했는데요, 많은 분들이 while문을 통한 반복문으로 미션 구현을 했더라구요. 이에 저는 ‘while문을 사용하는게 맞나? 재귀가 틀렸나?’ 라는 의문이 들었어요. 정답을 알기 위해서 이 둘의 차이점을 명확히 알아야 되겠다는 생각이 들었습니다. 그래서 이 점을 공부했고, 이 과정에서 while과 재귀의 차이를 통해서 ‘실행 컨텍스트’에 대한 개념을 잡을 수도 있었습니다!

그리고 처음 보는 구문인 do while 구문을 사용한 코드를 봤습니다. 처음 보는 생소한 코드였지만 야구 게임 미션에서의 기능 구현에 제일 부합하는 코드라는 생각이 들기도 했어요! 이렇게 다른 분들의 코드를 보는게 이래서 중요하구나 깨닫게 되었구요.

그리고 제가 받은 피드백 중 하나가 else if 대신 if return문을 사용하라는 것이었어요. 이 부분은 Airbnb 코드 컨벤션에도 적혀 있었지만, 제가 놓친 부분이더라구요. 이렇게 알고는 있지만, 익숙지 않아서 놓치는 부분들을 다른 분들이 봐주셔서 피드백이 감사하게 느껴지더라구요! else if를 사용하지 않을 것을 잊어먹지 않기 위해 왜 else if를 사용하는 것이 안 좋은지에 대해서도 공부하였답니다. 이 과정에서 “코드 가독성”에 대한 배움을 얻은 건 덤이네요!

✍️while문을 이용한 반복과 재귀를 이용한 반복문의 차이

 

[Javascript] while문을 이용한 반복과 재귀를 이용한 반복문의 차이

우아한 테크코스의 프리코스 1주차를 통해 많은 것들을 배웠는데요,, 코드 리뷰에서 다른 분들의 조언과 좋은 코드들을 보며 많은 생각을 하게 되었습니다. 😊 1주차 문제에선 “사용자의 입력

lurgi.tistory.com

✍️else if 대신 if return 사용하는 이유?

 

[Javascript] else if 대신 if return 사용하는 이유?

자바스크립트의 Airbnb 코드 컨벤션에 따르면 다음과 같습니다! else if 블록 안에 return 구문이 있으면 여러 if 블록으로 나눠질 수 있습니다. // bad function cats() { if (x) { return x; } else if (y) { return y; } }

lurgi.tistory.com

 

🌱피드백이 이렇게 달콤할 줄이야!

공통 피드백을 통해서도 정말 많은 것들을 배울 수 있었습니다. 특히 공통 피드백은 정말 유용한 정보들이 많았는데요, ‘내가 지금까지 이런 걸 몰랐다고?’ 할 정도로 너무나 중요한 것들을 배울 수 있었습니다! 나름 열심히 공부했다 생각했는데 모르는 부분이 이렇게나 많다니! 약간 죄책감도 들었지만 이렇게 피드백으로 유용한 것을 배울 기회를 얻게 되어서 너무 감사하다는 생각이 들었어요.

우선 Lintter와 formatter를 이해하고 이를 적용해 개발 환경의 질을 향상시킬 수 있었습니다. 처음 이 세팅을 마치니 신세계더라구요. Airbnb 코드 컨벤션을 적용 시키니 지금까지 잘 적용하고 있었다고 생각했던 코드 컨벤션이었는데, 여기저기서 뜨는 오류들을 보고 ‘이렇게 놓치고 있는 부분이 많았다니’ 새삼 느꼈습니다. 참 스스로 부족하구나 생각했고요.

또 이 공통 피드백 강의를 통해서 Git에 대한 다양한 기능들을 더불어 배울 수 있었습니다. 1주 차 때 올바른 커밋에 대해 고민했었던 적이 있었는데요, 딱 이 부분을 시원하게 긁어주는 그런 강의 였어요! 그래서 너무나 좋았습니다 😆 특히 이번 미션 때는 적극적으로 rebase를 활용해 봤습니다. ‘혹시 잘못되지 않을까?’ 생각해서 따로 연습하기도 했고요. 그래도 아직 미숙한 부분이라 커밋을 완전히 깔끔하게 정리하진 못했습니다. 그래도 많이 익혔으니 다음 미션부터는 더 깔끔한 커밋을 보낼 수 있겠다는 자신감이 들었습니다!

✍️ git 불필요한 커밋을 합치는 방법. Rebase 

 

[개발 상식] git 불필요한 커밋을 합치는 방법. Rebase

이번 시간에는 git에서 과거 커밋을 없애기 위해 합치는 방법을 알려드리고자 합니다! 개발을 하고 커밋, 푸쉬를 하다보면 다음과 같은 상황이 많이 발생하기 마련입니다. feat : #3 커밋을 푸쉬하

lurgi.tistory.com

 

🌱요구사항들을 분석해 보자!

본격적으로 이번 미션 기능 구현에 앞서 이번 새롭게 추가된 요구사항을 꼼꼼히 짚어봤습니다! 분명 배울 점이 있을 것이라 생각했거든요. 첫 번째 요구사항이었던 들여쓰기에서 저는 의문이 생겼습니다. ‘왜 들여쓰기 깊이를 2까지로 제한한 걸까?’ 라는 생각으로 들여쓰기에 대한 중요성을 짚어보는 시간을 가지기도 했습니다! 이 과정에서 역시 중요한 점은 ‘첫째도 가독성, 둘째도 가독성’이란 점을 다시 한번 깨달을 수 있었네요!

또한 ‘jest를 통해서 구현한 기능들을 테스트’ 라는 요구사항을 통해 TDD에 관해 공부하게 되었어요! TDD라는 개념은 프리코스 커뮤니티를 통해 1주 차 때 미리 접했던 개념이었는데요, 이번주는 이 TDD에서 ‘단위 테스트’를 중점으로 개념을 한 번 잡아 보려고 노력했어요. 지난주와 달리 이번 주는 요구 사항에 테스트가 있는 만큼, 꼼꼼하게 따져보면서 공부했답니다. 실질적으로 적용해 나갈 수 있는 부분들에 대해서 배우기도 하며 TDD에 대한 이해도가 높아졌습니다! 이를 통해서 테스트 코드 역시 실제 코드만큼 중요하다는 점을 깨달았습니다.

✍️들여쓰기가 코드 가독성에 미치는 영향

 

[개발 상식] 들여쓰기가 코드 가독성에 미치는 영향

이번에 우아한 테크코스 2주차 미션에서 추가된 요구사항이 있었습니다. 다름아닌 ‘indent(인덴트, 들여쓰기) depth를 2까지만 허용한다.’ 라는 요구사항이 있었습니다. 이 요구사항을 보니 의문

lurgi.tistory.com

✍️단위 테스트

 

[개발 상식] 단위 테스트

우아한 테크코스 프리코스 2주차 미션에서 요구되는 것은 ‘본인이 만든 기능 테스트’ 입니다! 지난주 TDD에 대해 공부를 했고, 단위 테스트에 대한 내용들을 훑어 보았는데, 이번에 이렇게 미

lurgi.tistory.com

 

🌱객체 지향을 더 알아가기 위해! ‘클린 아키텍처’ 읽기

1주 차 때 ‘객체 지향’이라는 개념을 알게 되어 잠깐 맛보았다면, 이번 주에는 본격적으로 이 개념을 이해하고자 노력했습니다! 프리코스 커뮤니티에서 추천받은 책이 두 권 있는데요, 하나는 ‘클린 아키텍처’, 다른 하나는 ‘객체 지향의 사실과 오해’라는 책을 추천받았습니다. 2주차가 시작함과 동시 ‘클린 아키텍처’를 읽고 있는데요. 이를 통해서 ‘객체 지향’이라는 것이 소프트웨어 아키텍처에 끼치는 영향에 대해 더욱 깊게 알 수 있는 시간을 가지고 있답니다!

책을 통해 배운 첫 번째 점은 SRP에 대한 생각이 바뀌었다는 점입니다. 단순히 ‘하나의 기능을 가진 함수를 만드는 것’이라 생각하고 있었던 이 법칙은 ‘하나의 액터만을 책임진다’ 라는 개념으로 바뀌었습니다. 이걸 이해하는 순간 지금까지 내가 해왔던 메서드 분리라는 것들이 부정당하는 느낌이 들더라구요. 그만큼 많이 배웠다는 뜻이라 생각합니다🤣

또한 의존성에 대한 개념을 통해서 ‘객체 지향’에 대해 한 층 더 이해할 수 있었던 시간이었습니다. 특히나 이번 주부터 메서드 분리가 요구사항으로 주어진 만큼 이 의존성에 대해서 신경을 썼는데요, 이 과정을 통해서 조금 더 깔끔한 아키텍처를 만들어 나갈 수 있었던 느낌을 받았습니다! 이 부분에서 “디자인 패턴”이라는 개념을 알게 되었고 간단하게 퍼사드 패턴에 대해서도 공부해 보는 시간을 가졌습니다.

✍️객체 지향의 의존성 

 

[Javascript] 객체 지향의 의존성

지난 시간 객체 지향의 핵심에 대해서 알아보았는데, 더 나아가 의존성에 대해서 깊게 공부해보고자 합니다! 객체 지향의 핵심에 대해서는 아래 포스팅을 참고해주세요! [Javascript] 객체 지향 (Obj

lurgi.tistory.com

✍️퍼사드(Facade) 패턴 

 

[개발 상식] 퍼사드(Facade) 패턴

객체 지향을 공부하는 와중 퍼사드 패턴이라는 것을 접하게 되었고 이를 완전히 이해하고자 블로그 글을 적습니다! ❓퍼사드 패턴? 우선 정의부터 살펴볼까요? 퍼사드(프랑스어: façade[fəˈsɑːd]

lurgi.tistory.com

 

🌱아쉬웠던 점

이렇게 많은 걸 즐겁게 배울 수 있는 한 주였습니다만, 스스로 만든 코드에 대한 만족도가 크진 못했습니다. 코드를 작성하면서 docs/README 파일을 계속해서 수정하며 스스로 이러지도 저러지도 못하는, 명확한 목표를 설정하지 못한 채 시간 낭비를 많이 한 것 같아 너무 아쉬웠습니다. 특히 README파일에 기능 목록을 정리하는 과정에서 흔들림은, ‘커밋 단위는 docs/README.md에 정리한 기능 목록 단위로 추가' 라는 요구 사항을 명확히 충족시키지 못한 것 같다는 느낌이 계속 저를 괴롭히더라구요 😭 그래서 이런 부분을 보완하고자 스스로 '기능 목록을 설계하는 방법론'에 대해서 만들어 보기도 했답니다. 이 부분을 다음 미션 때 적용해 볼 생각이에요!

그리고 코드 외적인 부분에 신경을 많이 쓰다 보니 코드 자체를 신경 써서 만들지 못한 점을 느꼈습니다. 이 부분 역시 프로그램을 설계할 때부터 신경 써서 코드를 작성해 나가야지 되겠다는 생각이 들더라고요. 그래서 결론은, ‘무작정 프로그램을 짜려고 덤벼들지 말고, 충분한 시간을 들여 설계를 하자!’는 결론을 내렸습니다!

🏃‍♂️그리고…

이번 주 처음 피드백이라는 것을 받아보면서, 정말 정말 많은 것들을 배울 수 있는 시간이었어요. 지금까지 혼자 공부하면서 느끼지 못한 부분들을 프리코스를 통해서 많이 배울 수 있는 것 같아 너무 기쁘네요😊 그리고 한편으론 프리코스의 절반이 지났다는게 벌써부터 너무 아쉬워지네요. 그러니 남은 기간도 열심히 달려볼 생각입니다!

 

2주차 미션 자동차 경주

 

GitHub - lurgi/javascript-racingcar-6: 2주차 미션

2주차 미션. Contribute to lurgi/javascript-racingcar-6 development by creating an account on GitHub.

github.com