layout: post
title: "레이싱 게임 미션 페어프로그래밍 - Day1"
date: 2022-02-11T00:00:00-00:00
author: sangyeop
categories: Sproutt-2nd
레이싱 게임 미션 페어프로그래밍 - Week1
바로 구현에 들어가기에 앞서서 우리는 프로그램이 실행되는 흐름을 먼저 작성한 뒤, 작성한 흐름을 바탕으로 주어진 기능 요구 사항 외에 우리가 필요하다고 생각되는 요구사항을 추가적으로 작성하여 정리하였다. 다음은 페어프로그래밍을 처음 진행하며 공부했던 키워드들을 정리해 보았다.
정적 팩토리 메서드
- 객체 생성의 역할을 하는 클래스 메서드
그렇다면 객체를 생성하는 역할을하는 것이라면 생성자가 있는데, 굳이 정적 팩토리 메소드를 만들어서 사용하는 이유가 무엇일까?
"생성자 대신 정적 팩토리 메서드를 고려하라" - <이펙티브 자바>
정적 팩토리 메서드의 장점들은 다음과 같다.
- 이름을 가질 수 있다
- 호출할 때마다 새로운 객체를 생성할 필요가 없다
- 하위 자료형 객체를 반환할 수 있다
- 객체 생성을 캡슐화할 수 있다
- 정적 팩토리 메소드 네이밍 컨벤션
- from : 하나의 매개 변수를 받아서 객체를 생성
- of: 여러개의 매개 변수를 받아서 객체를 생성
- getInstance | instance: 인스턴스를 생성, 이전에 반환했던 것과 같을 수 있음
- newInstance | create: 새로운 인스턴스를 생성
- get[OtherType]: 다른 타입의 인스턴스를 생성. 이전에 반환했던 것과 같을 수 있음
- new[OtherType]: 다른 타입의 새로운 인스턴스를 생성
유틸리티 클래스란?
InputView와 OutputView와 같이 인스턴스 변수가 없고 매개변수에만 의존하는 클래스와 같은 경우에는 객체를 만들지 않고, 모든 메소드를 Static으로 바꾸어도 무방하다.
이렇게 모든 메소드들이 static이고 객체를 만들어쓰지 않는 클래스를 유틸리티 클래스 라고 한다. 유틸리티 클래스에서 비즈니스 로직을 다루는것은 좋지 않지만, View는 흔히 유틸리티 클래스에서 다루곤 한다.
느낀점
내가 어떻게 더 작은 단위를 설계를 할 지 고민을 하기보다, 당장 구현에 급급하다는 것을 깨달았다. 페어프로그래밍을 진행하며, 내가 생각했던 클래스 단이 이야기를 나누면서 더 작게 쪼개지고, 메소드의 기능들도 계속해서 작게 나누어지는것을 경험하면서 아직 자바라는 언어에 대해서도 잘 이해하지 못하고 있었다고 느꼈고, 새로운 것들을 계속 배워가는 기분이 들어서 큰 흥미를 느꼈다.
- 코딩컨벤션
서로 페어프로그래밍을 진행하면서 자주 반복되는 변수와 용어를 일치시키려는 노력을 하였고, 덕분에 의사소통과 코드 가독성에 있어서도 두 사람이 번갈아 가면서 코드를 작성했지만 최대한 일관성있는 코드가 작성된 것 같았다.
- 테스트코드
작은 기능 하나 단위로 테스트코드를 작성하기로 하였는데, 테스트코드를 작성해본 경험이 많지 않았기 때문에 이 부분에 있어서 꽤 고민을 했던 것 같다. 첫 날 해결하지 못하고 다음으로 기약한 내용 또한 이 테스트코드와 관련된 부분인데, "과연 랜덤 값 같은 경우에는 매번 값이 달라지는데 어떻게 테스트를 해야 하는가" 였다. 이 부분에 대해서 고민을 해보고 Day2에서 이야기를 나누어보기로 하였다.
- 리팩토링
현재 코드에서 View에서 도메인 클래스를 직접 접근하고 있기 때문에, Dto 클래스를 생성해서 View가 도메인을 알지 못하도록 리팩토링을 진행할 계획이다. 이 과정에서 자바8 stream 사용과 이중 for문 사용에 대한 부분도 공부해서 고려해볼 예정이다.
