이번 주 역시 너무나 많은 것을 배울 수 있는 좋은 시간을 보냈습니다. 2주 차와 동일하게 코드 리뷰를 통해 많은 것들을 배울 수 있었구요. 특히나 이번 주는 코드를 작성하면서 TDD에 대해서 깊게 생각해 볼 수 있는 시간이었어요. 저는 1주 차 때부터 TDD에 대한 내용을 공부하고, 3주간 이를 적용해 봤는데요, 이번 주가 되어서야 TDD의 본질적인 의미를 조금 이해한 느낌이 들었습니다! 아직 한참 멀었겠지만요🤣
🌱3주 차 미션을 시작하기 앞서 배운 것들
이번 주 역시 많은 분들이 코드 리뷰를 해준 덕분에 중요한 지식을 배울 수 있는 시간을 가졌습니다! 코드 리뷰를 하면서 ‘정규 표현식’으로 작성된 코드들을 보며 ‘이런 식으로 작성할 수 있구나!’ 깨달음을 얻게 되었죠. 지금 까지 미뤄왔던 정규 표현식을 이제는 배워야 할 때구나! 생각이 들었고 이에 대해서 공부하는 시간을 가졌답니다.
[개발 상식] 정규표현식을 배우자!
개발자라면 개발 언어를 불문하고 정규표현식을 접하는 일이 정말 많을텐데요. 초보 개발자인 저에게 정규 표현식은 아직 낯설기만 하네요. 그래서 이번 시간에는 정규 표현식을 완전히 마스터
lurgi.tistory.com
그리고 정말 중요한 사실 하나를 배웠는데요, ‘전역에서 객체를 선언하지 말아야 한다’는 것이었습니다. 정말 중요한 부분임에도 이를 인지하지 못하고 코드를 짰었던 제가 부끄럽기도 했지만, 이렇게 코드 리뷰를 통해 부족한 부분을 깨우칠 수 있게 되어서 정말 다행이라 생각했습니다.
[Javascript] 전역에서 객체를 선언하면 안되는 이유
이번에 우테코 2주차 코드 리뷰에서 정말 중요한 피드백을 하나 받았습니다! 바로 전역에서 객체를 선언하지 말라는 것! 그렇다면 왜 객체를 전역에서 선언하는 것이 위험할까요? ❓객체의 특성
lurgi.tistory.com
또한 미션을 시작하기 앞서 먼저 코드와 요구사항을 분석했습니다. 이번에 눈에 띄었던 것은 jest의 watch 기능인데요, 이 기능이 분명 유용하기 때문에 설정이 되어있을 것이라 생각했습니다. 그래서 watch 기능을 공부하면서 다양한 jest의 CLI 옵션들에 대해서 공부할 수 있는 기회가 되었습니다!
[Javascript] Jest 실패한 테스트만 실행시켜보자. watch 모드 기능
벌써 우테코 프리코스 3주 차가 시작되었습니다! 이번 새로운 과제에서의 테스트 코드가 조금 바뀌었는데요, 단순히 jest로 실행하던 테스트 CLI가 다음과 같이 변경되었습니다. "scripts": { "test": "j
lurgi.tistory.com
🌱2주 차의 아쉬움을 3주 차의 목표로
본격적으로 시작하기에 앞서 이전의 아쉬운 부분을 보완해 나가며 이번 미션에 적용해보고자 했습니다! 특히 2주 차 때는 미션의 결과가 너무 만족스럽지 못했었어요. ‘Git의 커밋 단위는 앞 단계에서 docs/README.md에 정리한 기능 목록 단위로 추가' 하라는 요구 사항을 만족시키기가 참 어렵더라구요. 어떻게 만족시킬 수 있을까? 고민을 많이 했습니다. 코드를 작성해 나가면서 README 파일은 끝도 없이 수정되었고, 이에 따라서 커밋은 질서 없이 엉망진창으로 추가되었거든요..🥲 그래서 딱 3주 차 목표는 '이 요구사항을 지켜보도록 노력하자'였습니다. 완벽한 설계를 위해 MVC 모델과 MVVM 모델에 대해서 공부하기도 했어요.
[개발 설계] MVVM이 뭔가요?
이번에는 MVVM에 대해서 공부하며 정리하는 시간을 가지려 합니다. ❓MVVM? MVVM은 MS사에서 프레젠테이션 모델(PM) 패턴을 수용하여 만들어 낸 모델이라고 합니다. MVVM은 모델, 뷰, 뷰 모델 이 세기자
lurgi.tistory.com
그런데 3주 차 미션이 시작되고 나서 이 목표는 더 어려워졌어요. 바로 '죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다' 라는 피드백의 한 문장 때문이었어요. '기능 목록의 완벽한 설계'를 목표했던 저에게 '과연 적당한 설계의 균형은 어디쯤일까?'라는 숙제가 스스로에게 주어졌습니다. 그리고 이는 TDD를 공부하면서 어느 정도 저만의 해답을 찾을 수 있었습니다!
🌱설계부터 구현까지, TDD가 와닿는 경험
이전 미션의 아쉬움을 만회하기 위해 좀 더 명확한 설계의 필요성을 느꼈습니다. 이번에는 유스케이스 다이어그램이라는 것을 도입해 보았습니다. 이를 통해 요구 사항을 보다 명확하게 할 수 있었죠. 이렇게 다이어그램을 그려보니, 프리코스에서 말하는 기능 목록 구현이란 것이 사용자의 요구 사항을 더 명확하게 알 수 있게 도와주는 것이란 깨달음을 얻을 수 있었습니다. (이전 미션에서 제가 얼마나 이상하게 구현했는지 역시 깨달았죠…🤣) 이번 과정의 ‘로또 게임’에서는 ‘콘웨이 법칙’을 떠올리며 설계를 했었는데요. 실제 구조를 상상하며 구현을 하였습니다. ‘로또 판매원 (사용자)’ - ‘로또 컴퓨터 (로직)’ - ‘로또(모델)’ 이런 식으로 접근해봤습니다.
[개발 설계] 유연한 설계를 위한 유스케이스와 콘웨이 법칙
이번 우아한 테크코스 프리코스의 3주차 미션을 설계하기 위해 많은 준비를 했는데요, 이번 읽고있는 책인 ‘클린 아키텍처’에서 ‘유스 케이스’라는 개념을 알게 되었습니다. 그리고 ‘유스
lurgi.tistory.com
이렇게 마친 설계를 이후, TDD를 본격적으로 연습하기 시작했습니다. TDD의 법칙을 따르기 위해 테스트 케이스를 우선적으로 만들었구요. 이번에 새롭게 접한 ATDD의 given, when, then 설계 법칙 역시 따르기 위해 많은 생각을 하며 코드를 작성해 나갔습니다.
사실 이렇게 TDD를 연습하고 있지만, 이 이유가 아직까지 완전히 체득되진 않았습니다. 언제나 이런 생각을 가지고 있었죠. ‘테스트 케이스가 없다면 기능 구현을 더 빠르게 할 수 있을 텐데’. 혹은 ‘이 정도의 간단한 프로그램에서 TDD를 굳이 해야 하나?’라는 생각이었죠. 그런데 이번주에 이렇게 공부하면서 깨달은 TDD의 필요성이 있습니다. 바로 TDD가 가져다주는 ‘심리적 안정감’이 있다는 것이에요.
설계와 구현의 반복으로 이루어진 개발 상황에서 길잡이 역할을 해줄 수 있는 것, 그것이 TDD 개발 방법론이라는 것을 깨달았습니다. 테스트 코드를 만들면서, 요구 사항을 명확히 함으로써 인자와 반환 값을 예상할 수 있는 메서드를 만들 수 있다는 것, 그로 인해서 걱정 없이 리팩토링 할 수 있다는 것, 이러한 과정에서 수행되는 법칙들은 이는 SOLID 법칙과 같은 객체 지향의 법칙과 다르지 않음을 깨달았어요. TDD를 통해 자연스레 의존성과 메서드 분리를 신경 쓰게 될 수 있었다는 것이죠!
이러한 생각들을 통해 TDD라는 것, 그리고 더 나아가 객체 지향이라는 것에 대한 법칙들이 ‘정량적 방법론’ 이라기보다는 ‘추상적 방법론’ 이란 사실을 깨닫게 되었습니다. 법칙의 뜻을 하나하나 기억하기보다는, 소프트웨어를 유연하게 설계하기 위한 본질적인 핵심을 깨우치자는 결론에 다다르게 되었습니다!
[개발 설계] ATDD(Acceptance Test-Driven Development)란? 그리고 TDD에 대한 생각
이번 시간에는 ATDD에 대해서 공부해 보려 합니다. ATDD는 사용자 요구를 더 잘 이해하기 위한 방안으로 탄생한 소프트웨어 개발론 인데요, 현재 TDD에 대해서 공부하고 있는 저로써 TDD의 심도있는
lurgi.tistory.com
[객체 지향] SRP의 진정한 의미
저번주 우아한 테크코스 프리코스 2주 차 피드백에서 이러한 피드백을 받았습니다 한 함수가 한 가지 기능만 담당하게 한다 그리고, 현재 읽고 있는 ‘클린 아키텍처’ 책에서 다음과 같은 내용
lurgi.tistory.com
그런 생각을 바탕으로, TDD 다운 개발을 위한 저만의 방법론을 만들게 되었습니다.
- 요구 사항을 분석한다.
- 요구 사항을 토대로 유스케이스 다이어그램을 만든다.
- 유스케이스 다이어그램을 바탕으로 기능 구현 목록을 만든다.
- 기능 구현 목록을 바탕으로 테스트 케이스를 만든다.
- 테스트 케이스를 바탕으로 기능 구현 코드를 작성한다
- 기능 구현 코드를 리팩토링 한다.
이렇게 생각하고 나니, 너무 깔끔하게 모든 것들을 처리할 수 있겠다는 자신감이 들더라고요. 이전 TDD를 접하기 전에는 많은 생각과 고민 때문에 효율적인 개발 환경을 구축하지 못했다는 느낌을 많이 받았었습니다. 개발을 해 나가면서 복잡한 로직을 생각할 때면 ‘만들기 싫다’는 마음이 우선적으로 들었고, 억지로 만들더라도 복잡하게 구성해 버린 탓에 기능을 추가하기도 어려울뿐더러, 목표했던 서비스를 만드는 데 실패했었습니다.
TDD를 통해서 이러한 부정적인 감정들을 없애버릴 수 있었어요. 이 ‘심리적 안정감’이 저에게 TDD의 필요성이 부각되는 요소라고 느껴졌습니다. 물론 앞으로 다양하고 큰 프로젝트를 많은 동료들과 함께 함으로써 TDD의 중요성이 더욱 부각될 것임을 기대하고 있습니다!
🌱리팩토링을 하면서
TDD를 이해하고 적극적으로 실천함에 따라 리팩토링을 해야 할 코드가 줄어드는 느낌을 받았는데요, ‘객체간의 의존성이 느슨해져서 그런게 아닐까?’ 생각을 해봤습니다. 이렇게 리팩토링을 하면서도 TDD의 중요성을 느끼기도 했답니다!
이번 리팩토링에서 특히 중점으로 생각했던 부분은 ‘switch문의 사용’이었습니다. 저번주 피드백에서 swtich 구문을 써보라는 피드백을 받았었는데요, 신기하게 이번 요구 사항에서 역시 switch에 대한 언급이 있었습니다. 한번도 이 구문을 사용해 본 적이 없었는데, 이렇게 많은 분들께서 말씀해 주시니 이를 ‘리팩토링과정에서 적극적으로 활용해 봐야겠다!’ 생각했었습니다. 그 이전, switch문과 if문의 차이를 정확하게 아는 것이 필요하겠다 생각해서 공부했고요. 결론은? switch 구문을 지양하자..! 사실 아직 스스로에 대해 의심이 들긴 하지만, 그렇다고 굳이 써야 할 이유를 찾진 못했습니다.. 그래도 의심을 버리진 않았답니다!
[Javascript] If 조건문과 Switch 조건문의 차이
우테코 프리코스의 3주 차가 벌써 막바지에 다다랐습니다. 저는 현재 3주 차 미션의 리팩토링을 진행하고 있는데요, 저번 2주 차 피드백에서 “if문 대신 switch문을 쓰는 게 더 깔끔하게 보일 수
lurgi.tistory.com
🏃♂️그리고!
이번 주는 3주간 공부한 내용을 되돌아보고, TDD에 대해 깊이 공부할 수 있었던 한 주였습니다. 이 덕에 조금 더 객체 지향의 목적에 부합하는, 유연한 코드를 만들 수 있게 된 것 같아요. 확실히 3주간의 기간 동안 성장한 느낌이 듭니다😊 벌써 한 주 밖에 남지 않았네요! 마지막 주 더 열심히 달려보겠습니다!
GitHub - lurgi/javascript-lotto-6: 3주 차 미션
3주 차 미션. Contribute to lurgi/javascript-lotto-6 development by creating an account on GitHub.
github.com
'우아한 테크코스 6기 > 우아한 테크코스 6기 프리코스' 카테고리의 다른 글
| [우아한 테크코스 6기] 최종 코딩 테스트 후기, 프론트엔드 풀이 방법 (0) | 2023.12.17 |
|---|---|
| [우아한 테크코스 6기 프리코스] 4주차 회고록 (0) | 2023.11.16 |
| [우아한 테크코스 6기 프리코스] 2주차 회고록 (0) | 2023.11.02 |
| [우아한 테크코스 6기 프리코스] 1주차 회고록 (0) | 2023.10.24 |
| [우아한 테크코스 6기 프리코스] 지원하기까지의 생각, 회고 (0) | 2023.10.23 |