[회고] 우아한테크코스 3주차 회고 (FE)

우테코 프리코스 3주차 회고

3주차 - 🚀 로또

이번주도 문제는 하나였다.

 

로또를 만드는 문제였으며 저번주에 비해 조건이 추가되었다.

 

갈수록 조건이 추가되어 과제가 까다로워지는 것 같다.

 

이번주 과제에서는 OOP를 사용했다.

 

🏃‍♂️ 시작하며

추가된 조건 중 else문 사용의 지양이 있다.

 

else문을 사용하지 않고 분기를 만들고 else 또는 switch문은 언제 사용해야 되는지 생각해보라는 의도인 것 같다.

 

또한, 단위 테스트의 구현이 있다.

 

이는 어떤 경우에 테스트가 필요한지 스스로의 경험에 근거하여 테스트를 구현하라는 의도로 파악했다.

 

저번주는 App 클래스 하나만 주어졌지만 이번주는 App 클래스와 Lotto 클래스가 추가로 주어졌다.

 

저번주와 다르게 두개의 클래스가 주어졌기 때문에 OOP를 사용하라는 의도로 파악했다.

 

(실제로 코드의 재사용이 많았기 때문에 OOP로 구현하는 편이 더 낫다고 생각한다)

---

✨ 과정 및 배운점

저번주에 학습한 OOP에 대해 실제로 사용해볼 수 있었다.

 

진행하며 느꼈던 점은 "설계가 어렵다"라는 것이다.

 

구현 자체는 어떻게든 할 수 있다는 자신감이 있다.

 

하지만, OOP에 익숙하지 않은 탓인지 설계에 가장 많은 시간을 투자한 것 같다.

 

스스로 생각했던 것은 "왜 OOP를 사용해야 하는가?"였다.

 

어떤 것을 하던지 왜 그것을 해야하는지를 이해하는 것이 중요하다고 생각한다.

 

내가 내린 결론은 "로또는 모두 같은 형식을 가지므로 별도의 객체로 만들면 재사용하기 쉬울 것이며, 각 객체로 분리함으로써 각 객체가 독립적으로 자신이 맡은 역할만 할 수 있기 때문"이다.

 

이 결론에 맞추어 설계를 하고 구현을 하려 노력했다.

 

src
 ├─── controllers
 │  ├── LottoGame.js (특정 로또의 결과를 구하는 클래스)
 │  └── Result.js (LottoGame을 통해 구해진 모든 로또의 결과를 구하는 클래스)
 ├─── IO (사용자 입출력에 관련)
 │  ├── Input.js
 │  └── Output.js
 ├─── models (각 데이터에 대한 형식을 설명하고 적절히 가공하여 데이터를 갖는다)
 │  ├── BonusNumber.js
 │  ├── Money.js
 │  ├── RandomLotto.js (금액별 랜덤 로또를 생성하여 갖는다)
 │  └── WinningNumbers.js
 ├─── utils
 │  ├── Constant.js (프로그램 전체에 사용되는 변수들을 갖는다)
 │  └── Message.js (에러 메시지에 관한 내용들을 변수로 선언하여 갖는다)
 ├─── App.js (프로그램의 시작점, Input 클래스에 콜백함수를 넘겨주고 Output 클래스에 데이터를 넘겨주는 역할)
 └─── Lotto.js (Lotto 데이터의 형식을 설명)

위는 본인이 과제를 진행하며 구성한 디렉토리의 구조이다.

 

(Lotto.js는 models안에 있는 파일들과 역할에 큰 차이가 없으나 문제에 조건에 의해 위치를 이동하지 않았다)

 

MVC 모델을 어느정도 참고하였으나 정석대로 따랐다고 하기는 힘들다.

 

controllers 디렉토리에 있는 각 파일들은 models에 있는 데이터들을 이용해 결과를 만들어 내거나 로또 게임을 진행하는 역할을 한다.

 

controllers에 포함되는 클래스들도 독립적인 데이터를 가지지만, 자신의 고유 데이터를 갖는것이 아닌 다른 데이터를 활용한다.

 

models 디렉토리의 파일들(Lotto.js 포함)은 각각 파일명과 동일한 클래스 하나만을 가지며 각 클래스는 담당하는 데이터에 관한 로직만 가지고 데이터를 다루며 해당 데이터를 갖는다.

 

IO는 말 그대로 사용자와 상호작용하는 부분이며 2주차 피드백의 내용대로 비즈니스 로직과 UI 로직을 분리하기 위한 것이다.

 

utils는 프로그램에 자주 사용되는 변수, 문자열 등을 갖는 파일들로 구성되어 있다.

 

프로그램은 App 클래스의 play 메소드에서 시작한다.

 

play 메소드는 사용자의 입력을 받고 해당 입력을 각 클래스로 넘겨주는 역할을 한다.

 

각 클래스는 해당 입력을 적절히 처리하여 데이터를 생성한다.

 

play 메소드는 해당 데이터를 다시 넘겨받아 갖게 된다.

 

각 클래스에서 받아온 데이터를 최종적으로 Result 클래스로 넘겨주는 역할을 한다.

 

Result 클래스는 LottoGame 클래스를 이용하여 각 로또에 대한 결과를 구한다.

 

최종적으로 App 클래스는 Output 클래스에 데이터를 넘겨준다.

---

이번 과제를 하며 "어떻게 프로그램을 설계할 것인가"에 대한 생각을 해볼 수 있었다.

 

여러가지 설계 방법론도 찾아보고 현제 과제에 적용시킬 수 있는 방법들에 대해 고민했다.

 

위의 디렉토리 구조는 그 고민에 대한 결과인 것이다.

 

이번 과제를 통해 코드의 재 사용에 대해 경험해볼 수 있었다.

 

로또라는 클래스를 하나 만들어두고 로또 클래스를 틀로 삼아 여러개의 로또를 찍어내는 것이다.

 

validation이 로또 클래스에서 이루어지고, 데이터를 가공하여 저장하는 역할을 하므로 로또에 관한 내용은 로또 클래스에서만 다루게 되는 것이다.

 

이는 로또 관련하여 수정 사항이 생기면 로또 클래스로 가서 수정하면 된다는 뜻이다.

 

다른 클래스는 로또 클래스를 통해 생성된 데이터에만 관심이 있을 뿐, 해당 데이터가 무엇을 의미하고 어떤 과정을 통해 생성되었는지에는 관심이 없다.

 

이를 통해, 책임을 분리하면 어떤 부분에 문제가 생겼거나 수정이 필요한 경우 해당 클래스를 찾아 가면 되므로 유지 보수 측면에서도 훨씬 용이하다는 것을 깨달았다.

 

추가적으로, 변수를 분리하는 과정에서 "로또 번호의 일치 갯수를 변수로 빼야 하는가"에 대한 고민을 하게 되었다.

 

결론적으로는 변수로 만들지 않았다.

 

나름의 이유는 만약 로또 번호의 일치 갯수가 변화한다는 것은 프로그램의 메인 로직이 변화하는 것을 의미하며, 이것을 수정하는 경우는 메인 로직의 수정도 불가피 하다는 생각이다.

 

그 외 로또 번호의 범위, 로또 번호의 개수, 당첨금 등은 메인 로직이 변화하지 않으면서 언제든지 바꿀 수 있기 때문에 별도의 변수로 만들어 관리했다.

 

이번 과제를 통해 어떤것을 변수로 선언하여 재사용할 수 있도록 해야하는지에 대한 고민도 할 수 있었다.

---

물론 내 방법이 정답이 아닐 수 있다. (정답이 아닐 가능성이 높다고 생각한다)

 

일부는 맞을 수도 있지만 완전히 틀린 생각일 수도 있다.

 

하지만, 이렇게 다양한 상황에 맞딱뜨리는 과정을 통해 고민하며 성장할 수 있다고 생각한다.

---

💡 아쉬운 점

뭔가 더 나은 방법이 있을 것 같다는 아쉬움이 남는다.

 

처음부터 완벽하게 할 수는 없는 것 같다.

 

이번 과제를 하면서도 중간에 기능 목록이 수정되었다.

 

코드가 마음에 들지 않고 스파게티 코드가 되어버려 다시 갈아 엎고 새로 시작하기도 하였다.

 

기능 목록에 모든 것을 세부적으로 작성하고 시작하기 보다는 어떤 기능이 필요한지 큰 시선에서 파악하는 것이 중요한 것 같다.

 

처음 기능 목록을 너무 세부적으로 작성하여 그것에 오히려 얽메였던 것 같다.

 

또한, 자신의 방법이 잘못 되었다는 생각이 들면 과감히 방법을 바꾸는 태도가 중요한 것 같다.

 

중간에 코드가 꼬여버렸지만 이때까지 내가 작성한 코드들이 아까워서, 이 방법으로 조금만 더 해보면 어쨌은 완성은 될 것 같다는 생각에 오히려 시간을 낭비했던 것 같다.

 

자신의 생각과 계획에 어느정도 확신을 갖고 나아가는 힘도 중요하지만 과정을 돌아보는 과정에서 때로는 "과감함"이 필요하다는 것을 깨닫게 되었다.