숫자 야구 게임 전체 회고

숫자 야구 게임 과제가 끝나고 제 프로젝트를 돌아보며 잘한 점과 못한 점에 대한 회고를 하려고 합니다.

잘한 점

통일된 예외 처리

BaseballException을 상속받는 다양한 예외 처리를 통해 통일감 있고 규칙적인 예외 처리를 구현했습니다. 무질서하게 흩어져 있을 수 있는 예외 상황을 하나의 규칙 아래 묶음으로써, 예외 처리 코드의 가독성과 유지보수성을 크게 높일 수 있었습니다.

개인 과제였지만, 이러한 일관성 있는 처리 방식은 협업 시에 큰 장점으로 작용할 것입니다. 향후에는 다양한 예외 상황을 다루면서 예외 메시지와 상태 코드를 정의하여 더 정교한 예외 처리를 시도해 볼 계획입니다.

 

메서드 파라미터에 final

메서드 파라미터에 final 키워드를 사용하면서, 불변성을 보장할 뿐만 아니라 휴먼 에러를 예방할 수 있다는 점을 새롭게 깨달았습니다. 협업 시 다른 개발자들에게 해당 파라미터가 수정될 수 없다는 사실을 명시적으로 전달함으로써, 보다 안정적이고 명확한 코드를 작성할 수 있었습니다.

 

전략 패턴 사용

처음 숫자 야구 게임의 자리 수가 3자리로 고정되어 있었지만, 요구사항이 점차 확장되어 5자리까지 변화하게 되었습니다. 이를 유연하게 처리하기 위해 전략 패턴(Strategy Pattern)을 도입하여 NumberGenerator 인터페이스와 이를 구현한 RandomNumberGenerator 클래스를 만들었습니다..

package level4.domain;

import java.util.List;

public interface NumberGenerator {

    List<Integer> generate();
}

package level4.domain;

import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Random;
import java.util.Set;

public class RandomNumberGenerator implements NumberGenerator {

    private final int digitSize;

    public RandomNumberGenerator(final int digitSize) {
        this.digitSize = digitSize;
    }

    @Override
    public List<Integer> generate() {
        final Set<Integer> set = new HashSet<>();
        final Random random = new Random();
        while (set.size() != digitSize) {
            set.add(random.nextInt(9) + 1);
        }
        return new ArrayList<>(set);
    }
}

이 패턴을 통해 컴퓨터의 숫자 생성 과정에서 구현체가 아닌 인터페이스에 의존하게 되어, DIP(Dependency Inversion Principle)를 지킬 수 있었습니다. 또한 추후 요구사항 변경에 보다 유연하게 대처할 수 있는 구조를 만들었다고 생각합니다.

 

못한 점

주석 부족

코드를 작성할 때 주석을 거의 달지 않았는데, 이를 통해 리뷰어 입장에서 코드 이해가 어려울 수 있다는 점을 깨달았습니다. 복잡한 로직이나 비즈니스 로직을 설명하는 주석은 필수적이며, 이를 통해 코드 가독성과 협업 효율성을 높이는 것이 좋다고 생각합니다.

물론 모든 코드에 주석을 다는 것이 바람직하지 않으므로, 꼭 필요한 부분에만 적절히 주석을 추가하는 습관을 들이려고 합니다.

 

코드 설명 능력 부족

구현을 하면서 깊게 생각하지 않고, 단순히 "이때는 이걸 사용하면 되겠지"라는 식의 안일한 사고로 작업을 진행한 경우가 많았습니다. 그 결과, 질문을 받았을 때 왜 이런 방식을 선택했는지 제대로 설명하지 못하는 상황이 발생했습니다.

앞으로는 설계나 구현을 진행할 때 이유를 명확히 하고, 기록을 남기며 그 과정에서 어떤 문제를 해결하려 했는지 정리하려고 합니다. 이런 습관을 들이면, 설계를 설명할 때도 자신감을 가질 수 있을 것 같습니다.