우아한 테크코스 5기 - 2주차 프리코스 회고

후추·2022년 11월 8일
0

한 주가 또 금방 지나갔다. 과제 풀이에 몰입하니 시간이 너무 빠르게 흐르는 것 같다. 이번 미션은 숫자야구게임이었다. 솔직히 힘들었다. 단순히 프로그램을 구현하는 것은 어렵지 않았으나, 소위 "깎고 다듬은" 코드를 작성하려고 오래 고민했다. 과정은 힘들었지만 다 끝낸 지금은 너무나 뿌듯하고 기쁘다. 또 한 계단을 올라 성장한 것 같다.

깃허브 주소

이번 과제를 진행하면서 특히 중점을 두고 공부했던 내용과 주요한 의사결정들을 기록한다.

학습

1주차 공통 피드백

지난 과제를 수행한 후 공통 피드백을 받았다. 피드백 내용을 최대한 지키려고 노력했다. 특별히 신경 쓴 항목은 변수명, 메소드명 등의 네이밍에 관한 것이었다. 변수와 메소드의 이름이 제 역할을 드러낼 수 있도록 노력했다. 축약형 표현을 삼갔고 너무 자세한 정보를 담는 것도 배제했다. 이름을 떠올리는 것이 어려울 때는 최대한 다른 코드들과 어우러질 수 있게 주변 코드를 살폈다.

public class NumberBall {
[...]
}

public class GameController {
	[...]
	private void receiveNumberBall() {
    	[...]
        NumberBall userNumber = new NumberBall(Console.readLine());
    }
}

위와 같이 콘솔에서 입력을 받아 NumberBall 객체를 수행하는 코드가 있었는데 이름을 수정했다.

먼저 NumberBall userNumber코드에서 Number가 겹쳐 가독성이 좋지 않았다. 그리고 객체 안에 어떤 것이 담겨있는지 굳이 클래스명으로 표기할 필요가 없어 보였다. 따라서 NumberBall 클래스를 Ball 클래스로 변경했다.

메소드명도 수정했다. 단순히 receiveBall()으로 지으면 컴퓨터의 Ball을 받는 것인지, 유저에게 Ball을 받는 것인지 알 수 없었다. 따라서 receiveUserBall()로 바꾸었다. 바뀐 코드는 다음과 같다.

public class Ball {
[...]
}

public class GameController {
	[...]
	private void receiveUserBall() 
    	[...]
        Ball userNumber = new Ball(Console.readLine());
    }
    
    private int compareComputerBallWith(Ball computerBall, Ball userBall) {
        int strike = computerBall.compareByIndex(userBall);
		[...]
        return strike;
    }
}

새로 바뀐 이름이 무조건 좋다고 할 수는 없지만 개인적으로 만족했다. 특히 다른 코드에서 Ball이라는 이름이 잘 어우러져 좋았다. compareComputerBallWith() 메소드는 ComputerBallUserBall을 비교하는 메소드인데 난생 처음 코드를 보는 사람이라도 메소드의 이름으로 기능을 짐작할 수 있을 것 같았다.

문장가로 알려진 작가들의 글은 모든 단어가 적재적소에 배치되어 있고 문장이 서로에게 호응하며 그 의미를 명확히 전달한다.

클린 코드도 비슷한 맥락이 아닐까 생각해보는 계기였다.

객체지향 설계

지난 주 메소드 분리를 연습하면서 설계에 대해 공부하고 싶었다. 프로그램을 어떻게 설계했느냐에 따라 메소드 분리가 쉬워지고, 클린 코드에 가까워질 수 있다고 느꼈다.

객체지향 설계를 위한 공부는 아래의 과정을 밟았다.

  1. 우아한 객체지향 강의 듣기
  2. MVC 패턴 공부 및 적용
  3. 전략 패턴 공부 및 적용

우아한 객체지향

해당 강의는 우아한 테크세미나에서 열린 조영호님의 강좌이다. 모든 내용을 이해할 수는 없었지만 "의존성"에 관한 키워드를 알게 되었다. 관련 내용은 이곳에 정리했다. 나도 이번 과제를 수행하면서 계속해서 의존성을 염두에 두었고 양방향 의존성을 피하려고 노력했다.

MVC 패턴

양방향 의존성을 피하려다 보니 뚜렷한 구분선이 필요했다. 자료를 검색하다가 MVC 패턴을 알게 되어 공부해보았다. 깊이 있게 들어가면 끝이 없겠지만 Model, Controller, View를 나누어 기능을 개발하는 것은 해볼만 할 것 같았다. 따라서 적용해보았다.

전략 패턴

코드를 작성하다보니 Controller의 역할을 하는 클래스가 너무 비대해지는 것을 느꼈다. 그래서 클래스를 나누려하는데 무엇을 기준으로 나누어야 하는지 헷갈렸다. 클래스를 분리하는 도구를 찾아 헤매게 되었다. 전략 패턴은 그때 발견한 도구이다.

전략패턴을 적용하기 위해 클래스를 변화할 가능성이 있는 부분과 변화하지 않는 부분으로 나누었다. 변화할 가능성이 있는 부분을 Strategy로, 변화하지 않는 부분을 Context로 나누었다.

0개의 댓글