3주차 회고
3주차 피드백을 읽고 3주차를 진행 하면서 아쉬웠던 부분이 많이 보였습니다..,, 그리고 지금은 4주차가 끝난 시점입니다!
한 달 동안 프리코스를 진행하면서 스스로 많이 성장함을 느꼈습니다. 사실 첫주차에는 생각보다 익숙해지는데 금방 걸리는가? 싶었지만 마지막까지 방심하면 안됨을 느꼈습니다. 힘든만큼 값진 경험이라고 생각하기 때문에 끝까지 해낸 것에 의의를 두려고 합니다.
다시 3주차로 돌아가서 회고를 진행해보겠습니다..!
3주차에는 로또 발매기를 만드는 미션이 진행되었습니다!
Lotto 미션
로또 프로그램은 간단한 로또 발매기입니다. 로또 구입 금액을 입력하면 로또가 자동으로 발행됩니다.
로또는 1에서 45까지의 6개의 숫자이고, 사용자가 로또 당첨 번호와 보너스 번호를 입력하면, 사용자가 구매한 로또 번호와 당첨 번호를 비교하여 당첨 내역 및 수익률을 알려주는 프로그램입니다!
3주차 목표
관련 함수를 묶어 클래스를 만들고, 객체들이 협력하여 하나의 큰 기능을 수행하도록 한다.
클래스와 함수에 대한 단위 테스트를 통해 의도한 대로 정확하게 작동하는 영역을 확보한다.
주어진 3주차의 목표는 다음과 같았습니다. 그리고 2주차의 피드백을 확인한 후 제가 세운 3주차의 목표는 다음과 같습니다.
1. 살아있는 README 만들기
처음부터 기능구현 목록을 완벽하게 세울 수 없으므로 처음에 완벽한 리드미를 작성하려 하기 보다는, 계속해서 주기적으로 업데이트 하는 리드미를 만드는 것이 첫번 째 목표였습니다.
2주차 코드리뷰 또한 반영하여 체크박스를 활성화 시키고 기능을 하나씩 구현한 후, 중간에 더 필요해 보이는 기능이 생기면
그 때 추가하는 방식으로 진행하였습니다.
2. 관련 함수를 묶어 클래스 만들기
2주차 피드백에서 작성하였듯이, 기존 코드에는 App의 책임이 컸습니다. 모든 주요 로직이 App에서 실행되게 했던 코드를 짰었습니다,,
사실 단일 책임 원칙을 제대로 알지 못한 채, 함수가 하나의 기능만 하도록 짠 것에 대한 뿌듯함만을 느끼고 안주했던 것 같습니다,,
즉,단일 책임 원칙이 클래스에도 적용되어야한다는 사실을 잘 인지하지 못하고 있었습니다.
여기서 단일 책임 원칙(SRP)는 객체는 단 하나의 책임만 가져야 한다는 원칙을 말합니다.
여기서 책임은 '하나의 기능을 담당하게 해야한다'라고 보시면 됩니다. 즉, 하나의 클래스는 하나의 기능 담당하여 하나의 책임을 수행하는데 집중되어야 있어야 한다는 의미입니다.
그렇게 App에서는 전체 프로그램의 흐름을 이해할 수 있도록 간소화하고, 주요 기능들은 각각의 기능들의 역할에 따라
- Lotto
- BuyLotto
- BonusLotto
- LottoResult
- LottoReturn
으로 클래스를 나누었습니다. 예시로 LottoReturn, Bonus 로또의 코드를 들고왔습니다.
이렇게 클래스 별로 책임을 분배하니, 나중에 코드를 고쳐야할 일이 생겼을 때 해당 클래스 안에서 수정할 수 있어 편했습니다.
함수 뿐 아니라 클래스를 사용할 때 단일책임원칙의 중요성에 대해서 알게되었습니다.
의미 있는 변수 명 만들기
클래스가 많아지고 코드가 점점 길어지면서, Lotto, number 등 겹치는 변수 명이 많아져 점점 헷갈려하는 현상이 발생하였습니다.
구매한 로또를 buy, purchased 등으로 섞어 쓰기 시작하고 match와 winning의 의미도 희미해지면서, 변수명을 정리해야겠다는 생각을 하였습니다.
구매자가 구매한 로또들 : purchasedLottos
구매자가 구매한 로또중 하나의 로또 : purchasedLotto
구매자가 구매한 로또중 하나의 로또의 숫자 : purchasedNumber
로또 당첨 번호 : lottoWinningNumbers
로또 당첨 번호의 숫자 : winningNumber
보너스 번호 : lottoBonusNumber
로또 번호 일치 갯수: matchCount
당첨 순위: winningRank
내가 내 코드를 보더라도, 변수명이 헷갈리는데 클린코드를 위해서는 하나의 변수도 명확한 의미를 가지고 있어야합니다.
3주차에서 내가 아쉬운 것
3주차가 끝나고 나서 4주차를 시작하기 전 바로 작성한 3주차의 아쉬운 점들입니다.
- 단위테스트를 하지 않은 점 → 테스트 코드를 먼저 작성하라(TDD에 대해서 공부하기)3주차에서 테스트 코드를 작성하였지만, TDD에 대한 개념을 알지 못하여 단위 테스트를 구현하지 못하였다.
- 클래스를 어떻게 나눌지 처음부터 생각하지 않은 점
- BonusLotto는 테스트 코드를 작성하던 도중에 추가한 클래스 입니다. 클래스를 어떻게 나눌지 처음부터 명확하게 생각하지 않으니, 중간에 코드를 수정함에 있어서 시간이 오래걸린 것 같습니다.
- UI 로직과 비지니스 로직을 분리하지 않은 점(Input, output을 클래스로 분리한다)
- 이번 미션에서 Input을 App에 나머지 비즈니스 로직은 클래스에 담으려고 하였지만, UI와 비지니스 로직이 명확하게 나눠진 것은 아니라고 생각합니다. 따라서 UI 로직과 비지니스 로직의 의존성이 커졌던 것 같습니다..
피드백을 받은 것 중에 UI로직과 비지니스 로직을 분리할 수 있는 MVC 패턴을 적용하는 것이 어떠냐는 피드백이있었습니다.
MVC 패턴에 대해서 공부한 후 이는 4주차에 적용하고자 하였습니다.
MVC(모델-뷰-컨트롤러)는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다.
Controller: 사용자의 요청을 처리하고 응답을 되돌려주는 과정을 처리하는 부분
View : Controller가 전달하는 데이터로 사용자에게 응답으로 제공될 템플릿(HTML, XML, JSON 등)을 생성하는 부분입니다.
Model : Controller에 의해 호출되어 DB에 데이터를 저장하거나, DB에서 데이터를 조회해 View가 사용할 수 있는 형태로 Controller에게 제공하는 부분입니다.
비즈니스 로직과 UI 로직의 분리한다
비지니스 로직과 UI로직을 한 클래스에서 처리하는 것은 단일 책임 원칙에 위배된다. 비지니스 로직은 데이터 처리 및 도메인 규칙을 담당하고, UI 로직은 화면에 데이터를 표시하거나 입력을 받는 역할로 분리한다.
- 객체는 객체 답게 사용하기
- 궁금한점
- UI로직을 클래스로 분리할지
- 함수로 만들어서 App에서 처리?
- → app 함수를 constructor와 가장 맞닿게 하자