title

현재 내가 사용하는 README 초안은 다음과 같다. 나머지는 너무 당연한 말이고, 시나리오라는 것은 절차적 프로그래밍과 거의 같은 말이다. 이번 포스트 내용은 이에 집중해서 내 생각을 작성해보려 한다.

# java-precourse

## 1. 시나리오로 문제를 표현한다.

- 하나의 문제는 하나의 시나리오로 표현된다.
- 현재는 존재하지 않는 코드를 작성하며, IDE의 생성/리팩토링 기능을 활용하여 뼈대를 만든다.

## 2. 입출력 형식을 정의한다.

- 입력 문자열에서 어떤 형식의 정보를 추출해야 하는가?
- 화면 출력에 필요한 형식의 정보는 무엇인가?

## 3. 문제를 가장 단순하게 해결할 수 있는 방법을 생각한다.

- **가장 행복한 상황**부터 상상한다.
- 주석으로 고수준 문맥을 코드에 적는다.
- 확신이 없는 부분부터 테스트한다.

## 4. 요구사항 문서를 읽어보고 점검한다.

- 요구사항을 놓쳤을 가능성을 염두에 둔다.
- 테스트로 적절히 표현되었는지 기록해두고 참고하자.

구현해보면서 느낀 점은 제한 시간을 준수하면서 아름다운 TDD를 수행하기에는 내 개발 실력이 아직 부족하다는 것이다. 그래서 내 한계를 인정하고, 중요한 것에 집중하는 방식으로 전환했다. 그렇다고 가장 어려울 것 같은 기능부터 구현하는 방식으로 시작하지는 않는다. 나는 문제를 ==시나리오로 정의하는 것==부터 시작한다.

시나리오로 문제를 표현하는 것은 설계 없이도 구현을 가능하게 한다. 일반 언어보다 프로그래밍 언어가 더 편한 내게는 이 방법이 더 좋게 느껴졌다. 모든 분석 결과를 문서에 장황하게 늘어놓지 않을 수 있다는 점이 좋았다. 문서화를 최소화하고 주석과 코드를 활용하는 것이 편하게 느껴졌다.

다음은 처음으로 vendingmachine 문제를 해결했을 때 내가 작성했던 시나리오의 내용이다. 원본은 총 세 개의 파일로 나누어져 있지만, 보기 좋게 하나로 합쳤다. GitHub 링크

exceptionHandler.tryUntilValid(() -> {
	int money = inputView.readInitialVendorMoney();
	vendor.vendorDepositBalance(money);
});

var balance = vendor.getVendorCurrentBalance();
outputView.printCurrentVendorMoney(balance);

exceptionHandler.tryUntilValid(() -> {
	var items = inputView.readInitialVendorItems();
	vendor.addStocks(items);
});

exceptionHandler.tryUntilValid(() -> {
	int money = inputView.readInitialUserMoney();
	vendor.userDepositBalance(money);
});

while (true) {
	int balance = vendor.getUserCurrentBalance();
	outputView.printCurrentUserMoney(balance);
	if (!vendor.canUserPurchase()) {
		break;
	}
	purchaseItem();
}

var balance = vendor.userWithdrawBalance();
outputView.printRemainingUserMoney(balance);

최초에 이 코드를 작성한 이후, 난 이 코드를 수정한 적이 거의 없다. (미묘한 뉘앙스 때문에 함수 이름 바꾼 정도?) 핵심은 Vendor vendor라는 변수를 전달받는다는 가정에서 시작하여, ==존재하지 않는 코드를 작성하며 프로그램 전체 설계를 완성할 수 있었다==는 것이다. 만약 앞서 제공한 깃허브 링크를 눌러보았다면, 실제 코드는 주석 때문에 좀 더 더럽게 느껴질 수 있다. 주석은 개발 중 고수준 문맥을 쉽게 참조할 수 있는 좋은 방법이라 생각한다. 마지막에 깔끔하게 정리한다면 개발 중에는 적극적으로 사용하는 것이 좋다고 생각한다.

재미있는 사실은 이런 방법론을 적극적으로 도입했음에도, 아직 손에 익지 않아 요구사항을 놓치는 등의 실수가 발생한다는 점이다. 예전에 최초 요구사항 분석으로 테스트 케이스를 만드는 선행 작업으로 도움을 받았던 기억이 나서, 다음에는 그런 부분을 고려해볼 예정이다.

---

+ 아래의 내용은 10일 전에 작성했던 내용이다. 12월 3일의 내 모습은 13일 현재의 모습과 많이 달라보인다. 물론 지금도 아래 적힌 내용들을 활용하지만, 차이점이라 하면 당시에는 구현의 순서나 행동에 제약을 두었다는 것이고, 현재는 사고의 틀을 좁히는 느낌이 있다.

[!tldr] 자주 반복되는 비슷한 것을 유형화하면, 차이점에 집중할 수 있게 된다.

계획은 사고의 틀이다. 이러한 기반은 사소한 고민 없이 핵심에 빠르게 집중할 수 있도록 만들어준다. 다음은 요구사항 정의서가 주어진다는 가정 하에, 그것을 PM/개발자의 언어로 작성하는 과정을 표준화한 내용이다.

## 1. 요구사항 정리

> 입력부터 출력까지 `자료형의 변환`으로 논리적 흐름을 표현한다.<br>
> 필요하다면 임의의 자료형을 새롭게 정의할 수 있다.

## 2. 객체 설계

> 작업을 진행할 대상을 선택하고,
> `책임과 역할`을 체크리스트로 나열한다.

## 3. 예외 상황

> 어떤 상황에 어떤 예외를 발생시키고, 어떻게 처리해야 하는지 설명한다.

커밋 메시지 작성 과정도 개발 중 은근히 오버헤드가 큰 부분이다. 기능 추가만 생각했을 때에는 다음과 같은 표준화도 가능할 것 같다. 이러한 방식은 ==1. TDD 기반==으로 ==2. 요구사항을 모두 테스트로 작성==하는 것을 전제로 하고 있다.

## 기본 원칙

### 커밋 표준

일반적으로 `인터페이스 - 테스트 - 구현` 순서로 진행한다.

> `feat(인터페이스): implement (구현한 메서드)`
>
> - (관련 테스트 메서드 나열...)

[!example]-

## 1. 요구사항 정리

- 문자열(+분리 규칙) -> 숫자 배열 -> 숫자(덧셈 결과)
- `String + ParseRule -> Iterable<Number> -> Number`

## 2. 객체 설계

- [x] 구분자(인터페이스; `Delimiter`): 주어진 문자열을 자신의 구분 규칙에 따라 숫자로 변환한다.
- 기본 구분자(클래스; `IntegerDefaultDelimiter`)
- [x] 쉼표(,)와 콜론(:) 모두 구분자로 간주한다.
- 커스텀 구분자(클래스; `IntegerCustomDelimiter`)
- [x] 문자열 앞부분의 `"//"`와 `"\n"` 사이에 위치하는 문자를 구분자로 간주한다.
- [x] 계산기(클래스; `Calculator`): 주어진 문자열을 분리하고, 더한 결과를 반환한다.

## 3. 예외 상황

`IllegalArgumentException`을 발생시키고 종료한다.

- [x] 커스텀 구분자가 기본 구분자와 겹치면 예외를 발생시킨다.
- [x] 커스텀 구분자가 숫자면 의도치 않은 결과가 발생할 수 있으므로, 요구사항에 명시되지는 않았지만 예외 상황으로 간주한다.
- [x] 숫자를 분리할 때, 형식 오류가 발생할 수 있다.
- [x] 분리된 숫자가 양수가 아니라면 예외를 발생시킨다.
- [x] 숫자를 더할 때, 오버플로우가 발생할 수 있다.