1주차 회고를 작성할 때만 해도 미루지 않고 제때 작성했지만, 미션이 점점 어려워지면서 해결에 더 많은 시간을 쏟다 보니 회고 작성이 늦어졌다. 3주차 미션은 간단한 로또 발매기 구현이었다. 1주차와 2주차 미션은 비교적 단순해서 바로 구현 후 클래스를 분리하는 방식으로 진행했다. 그러나 3주차는 요구사항이 많고 조금 복잡해 먼저 설계를 진행하고, 최대한 단일 책임 원칙에 맞춰 클래스를 분리하고 메서드를 구현했다.
3주차에는 개인적인 사정(변명이지만…)으로 데일리 스크럼을 작성하지 못하고, 리니어로 일정 관리만 했다. 4주차부터는 다시 꾸준히 작성해보려 한다.
아래는 이번 미션을 진행하면서 느낀 점을 4L 회고법으로 정리한 내용이다.
Liked, 미션을 수행하면서 좋았던 점
다양한 단위 테스트 코드 작성
이번 미션에서 다양한 단위 테스트 코드를 작성해볼 수 있었다. 2주차 코드 리뷰에서 테스트 케이스를 더 다양하게 작성하라는 피드백을 받고 Jest를 학습하면서 테스트 코드 작성 방법을 익혔다. 구매 금액 입력, 로또 발행, 당첨 번호 입력, 보너스 번호 입력 등에 대한 테스트 케이스와 코드를 작성하면서 테스트를 손쉽게 반복할 수 있어 개발 효율이 높아짐을 느꼈다. 테스트 코드를 작성하지 않고 개발하던 시절이 불편하게 느껴질 정도로, 테스트 코드가 코드의 안정성을 높이고, 예기치 못한 오류를 미리 확인하는 중요한 도구임을 실감했다.
짧은 함수 작성의 원칙과 이점
함수의 길이를 15라인으로 제한하는 규칙 덕분에, 짧은 단위의 함수로 나누기 위해 많은 고민을 했다. 특히 각 함수가 하나의 기능과 목적만 가지도록 신경 쓰며 구현했고, 이를 통해 함수들을 더 간결하고 재사용 가능하게 만들 수 있었다. 이 과정에서 코드의 가독성과 유지보수성이 높아지는 것을 느끼며, 더 나은 코드 설계 방법을 배울 수 있었다.
Learned, 미션을 수행하면서 배운 점
Jest 를 사용하여 단위 테스트 작성
3주차 미션을 수행하면서 Jest 테스트 프레임워크를 사용하여 단위 테스트를 작성하는 방법을 배웠습니다. 이 과정에서 기억에 남는 몇 가지 메서드들은 다음과 같습니다:
- toBe(): 두 값이 동일한 객체를 참조하는지를 확인하는 메서드로, 엄격한 동등성을 검사합니다.
- toEqual(): 기본 타입의 값이 동일한지를 검사하며, 동일한 객체를 참조하는지 확인하는 메서드입니다.
- test.each(): 다양한 입력값을 사용하여 반복적으로 테스트할 수 있게 해주는 메서드입니다.
- toHaveBeenCalledWith(): 특정 함수가 주어진 인자와 함께 호출되었는지를 검사하는 데 사용합니다.
- expect.stringContaining('[ERROR]'): 특정 문자열이 포함된 값을 검증하는 데 유용한 메서드입니다.
상수를 활용해 하드코딩 피하기
피드백을 통해 코드 내에서 하드코딩된 값을 피하고 상수를 사용하는 것이 가독성을 높이는 데 중요하다는 것을 배웠다. JavaScript에서 상수를 정의하기 위해 Object.freeze() 메서드를 사용하여 값이 변경되지 않도록 보호하는 방법을 적용했다. 이번 미션에서 로또 금액 단위를 나타내는 상수 LOTTO_PRICE_UNIT을 정의했으며, 로또 상금을 관리하기 위해 다음과 같이 상수 LOTTO_PRIZES를 설정했다:
const LOTTO_PRIZES = Object.freeze({
THREE: 5000,
FOUR: 50000,
FIVE: 1500000,
FIVE_AND_BONUS: 30000000,
SIX: 2000000000,
});그 외에도 매직 넘버나 에러 메시지 등을 하드코딩하지 않고 상수로 정의하여 코드를 작성했습니다.
Lacked, 미션을 수행하면서 부족했던 점
3주차 미션을 수행하면서 테스트 코드 작성에 부족함을 느꼈다. 미션의 지침에 따라 작은 단위의 테스트부터 시작하기로 했지만, 클래스의 메서드에 대한 테스트 코드를 작성하는 것부터 쉽지 않았다. 사실, 실제로 테스트 코드를 작성해본 경험이 없어 익숙하지 않아서 어렵게 느껴졌다. 그래서 기본적으로 제공되는 ApplicationTest.js 파일을 참고하여 테스트 코드를 작성하기 시작했다.
그 과정에서 expect()와 test.each() 메서드를 조금이나마 이해하게 되었지만, 여전히 스스로 테스트 코드를 작성하는 데는 어려움이 있다. 앞으로는 더 많은 연습과 공부를 통해 테스트 코드 작성 능력을 향상시켜야겠다고 생각했다.
Longed For, 앞으로 개선하고 싶은 점
비동기 처리 시 await 누락 방지
요구사항을 만족하도록 개발을 완료한 후, 테스트 코드를 실행했을 때 터미널에 처음 보는 에러가 발생했다. GPT와 구글링을 통해 해결해보려 했으나 쉽지 않았다. 결국 2주차 미션 코드를 살펴보면서 문제를 발견했다. App.run() 메서드에서 내가 구현한 LottoGame.play() 메서드를 호출할 때 await 키워드를 사용하지 않아 생긴 에러였다. 앞으로는 비동기 호출 시 await를 빠뜨리지 않도록 주의해야겠다.
개발 완료 후 테스트 코드를 실행하던 중, 터미널에 처음 보는 에러 메시지가 나타났다. GPT와 구글링을 통해 문제를 해결하려 했지만 쉽게 해결되지 않았고, 결국 2주차 미션 코드를 다시 살펴보며 원인을 찾을 수 있었다. 문제는 App.run() 메서드에서 LottoGame.play() 메서드를 호출할 때 await 키워드를 빠뜨린 것이었다.
여기서 LottoGame.play() 메서드는 async로 선언된 비동기 메서드이기 때문에 await 키워드를 사용하지 않으면 해당 메서드의 비동기 작업들이 완료되기 전에 다음 코드가 실행된다. 이러한 흐름이 깨지면 데이터가 준비되지 않은 상태에서 코드가 진행될 수 있어 의도치 않은 에러가 발생할 수 있다. 앞으로는 비동기 메서드를 호출할 때 await 사용 여부를 꼼꼼히 점검하는 습관을 길러, 비동기 처리에서의 오류를 예방해야겠다.
에러 메시지 읽기와 이해 습관화하기
기능 요구사항을 모두 구현한 후, npm run test 명령어로 테스트를 실행했을 때, ApplicationTest.js 파일의 예외 처리 테스트에서 에러가 발생했다. 이 테스트 코드에서는 구매 금액으로 '1000j'를 입력하여 일부러 에러를 발생시키고, 에러 메시지가 터미널에 출력되는지를 확인하도록 작성되어 있었다.
ApplicationTest.js 파일에 작성되어 있던 코드:
expect(logSpy).toHaveBeenCalledWith(expect.stringContaining('[ERROR]'));이 코드는 logSpy (즉, MissionUtils.Console.print 메서드)가 호출되었는지 확인하고, 호출될 때 전달된 인자 중에 문자열 [ERROR]가 포함되어 있는지를 검사한다. 이러한 방식으로 에러 메시지가 터미널에 출력되었는지를 확인하는 테스트 코드를 작성했다.
처음에는 모든 에러를 throw new Error() 코드를 사용해서 던지기만 하고 따로 처리를 해주지는 않았다. 2주차 미션까지는 그렇게 해도 문제가 없었으므로, 이번 3주차 미션 테스트 코드도 동일하다고 생각했다. 그런데 테스트를 실행해보니 통과가 되지 않았다. 테스트 코드가 실패했다고 에러 메시지를 보여줬지만, 읽어보지 않고 ChatGPT에 질문했다. 결과적으로 테스트의 어느 부분에서 에러가 발생했는지에 대한 정보만 얻었고, 원인을 파악하지 못했다.
테스트 코드를 분석한 후에야 throw new Error() 코드가 아니라 Console.print() 메서드를 사용하여 에러 메시지를 출력해야 한다는 것을 알게 되었다. 다음부터는 무작정 ChatGPT에게 물어보지 말고, 한 번은 스스로 에러 메시지를 읽어보고 에러가 발생한 코드에서 왜 문제가 생겼는지 생각해보고 이해해보아야겠다고 다짐했다.
파일명 변경 시 import 구문 철저한 검토(특히 대소문자!)
코드 작성 후 PR을 제출했지만, 예제 테스트에서 “예기치 못한 오류로 실행에 실패하였습니다”라는 메시지가 나타났다. 스터디원들에게 질문하여 내가 제출한 미션이 제대로 빌드되지 않아서 발생한 문제라는 답변을 들었다. 문제의 원인을 찾기 위해 파일명과 import 구문을 확인해본 결과, 파일명을 변경한 후 ErrorConstant.js를 errorConstant.js로 수정하지 않아서 오류가 발생했음을 알게 되었다.
앞으로는 파일명을 수정할 때 import 구문을 반드시 확인하는 습관을 들여야겠다. 자동으로 import가 이루어지는 것에 너무 의존하지 말고, 변경한 파일명이 올바르게 반영되었는지 재차 검토해야 할 필요성을 느꼈다. 이렇게 작은 실수들이 프로젝트의 빌드를 방해할 수 있으므로, 세심한 주의가 필요하다는 것을 다시 한번 깨달았다.
