[우아한테크코스 AN]

[우아한테크코스] 4주차 회고

Hevton 2024. 3. 23. 15:57
반응형

 

4주차에는 블랙잭 미션을 진행했습니다.

이번 미션에서 학습한 내용은 다음과 같습니다.

 

블랙잭 미션에서는 정말 많은 것들을 얻어가게 되었다고 느낍니다.

 

 

 

DSL(Domain-specific language)

선언적 언어. 젯팩 컴포즈나 코틀린의 UI 방식입니다.

이걸 처음 봤을 때, 빌더 패턴이 이렇게 생겼구나 라고 느낄 수 있었습니다. buildString을 활용할 줄만 알았는데, 시야를 조금 더 깨우칠 수 있는 계기였습니다.

 

 

설계의 중요성

기본적인 설계를 어느정도 생각해 두고 가면 뒤에 사고가 발생하는 것을 방지할 수 있습니다.

그 전까지는 어느정도 설계를 마치고 진행했었는데, 이번 주차에는 페어와 함께 주먹구구식의 방식에 도전해보기로 했습니다.

결과는 3일동안 매일 남아서 미션을 했습니다.

 

 

 

의존성 관계 정의

설계를 할 때 의존성 그래프를 그리고 시작하면 장점이 있습니다. 기능을 구현할 때 의존성이 제일 작은 것부터 (내가 무언가를 가리키는 화살표가 없을 수록) 구현을 진행하면 비교적 쉽게 접근할 수 있습니다. 또한 도메인의 의존성 그래프를 정의했을 때, 그래프가 한 방향으로 이루어져야 복잡하지 않은 설계라고 볼 수 있고, 순환 구조를 이루게 된다면 설계를 다시 생각해봐야 합니다.

 

 

MVC 패턴에서 컨트롤러의 역할

안드로이드에서 MVVM 패턴을 진행해오다가, 콘솔에서 MVC 패턴을 진행하면서 "Controller"의 역할은 어디까지인가? 라는 생각이 들었습니다. 만약 백엔드의 전형적인 MVC 패턴이라면

Controller - Service - Repository 구조가 놓이기에, Controller에서는 사용자의 응답을 받아서 Service에게(도메인) 일을 시키기만 하는 과정을 갖습니다. 그래서 Controller의 역할이 비교적 가벼워 코드의 가독성이 좋습니다.

Kotlin 콘솔 프로그램에서는 Service를 따로 구현해보지 않게 되면서, Controller의 무게가 무거워져야할까 Model의 무게가 무거워져야할까 고민이 놓였습니다. 즉 Controller가 게임을 진행할지, 아니면 게임을 진행하는 누군가가 있을지에 대한 고민입니다.

 

Controller에서 게임을 진행해도 되지만, 게임을 진행해주는 자를 정의해주면 좋습니다. 하지만 해당 객체는 Model이 아닐 수도 있습니다. Model의 객체는 각자의 역할을 할 수 있어야 합니다. 이는 일급컬렉션을 선언해놓고 일급컬렉션 안에서 해당 리스트를 다루지 않고, 밖에서 꺼내서 사용한다는 의미에 가까워지지 말아야 한다는 것을 의미하기도 합니다. GameManager처럼 게임을 진행해주는자가 존재하게되면  Controller의 무게가 가벼워져서 코드의 가독성이 좋아진다는 장점이 있고, 또한 하나의 컨트롤러에서 여러 게임을 진행할 수 있게 된다는 장점을 가질 수 있습니다.

 

 

도메인에서 뷰의 역할을 하고 있진 않은가?

여태 사용자의 응답을 모두 Model로 감싸주었습니다. 그리고 그 Model 객체 안에서 사용자 응답에 대한 모든 유효성 검증을 진행하였고, 이는 테스트화하기도 쉬웠다. 하지만 아래와 같은 피드백을 받을 수 있었습니다.

 

  1. View에 표시되는 문구가 수정되어야 한다면, 도메인이 수정되어야 할까?
  2.  '정해진 응답의 객체'로 변환이 View에서 하는 역할이 이런 역할이지 않을까요? 예를 들어, 출력 양식이 또는 입력 조건이 수정되었을 때 동료 개발자가 어디를 가장 먼저 찾아볼까요?
    A. Answer 도메인 로직이 어떻게 구현되어 있는지 들어온다.
    B. OutputView /InputView 와 Controller 호출부를 찾아본다

 

하지만 이렇게 되면 모델 테스트에서 진행이 불가능하고 뷰를 테스트해야한다? 는 궁금증이 생긴다. 이 부분에 대해서는 다음 리뷰어분께도 여쭤볼 계획!

 

 

테스트 코드도 코드다.

테스트 코드도 유지보수와 리팩터링의 대상입니다.. 그래서인지 많은 회사에서는 테스트 코드를 작성하지 않기도..한다고..!

테스트 코드를 가독성있게 유지하자는 개념으로 Test Fixture를 이야기합니다.

 

 

추상클래스를 활용하여 다형성

공통된 로직이 있을 경우에 추상클래스를 활용하여 다형성을 구현하는 방향은 코드의 중복을 방지할 수 있기에 좋습니다.

이는 알고 있으면서도 막상 활용하는 것을 잊기 쉬운 부분입니다.

 

반응형