우아한 테크코스 7기 프리코스 3주차 회고

배달의 민족 운영사인 우아한형제들에서 운영하는 개발자 양성 프로젝트, 우아한테크코스에 지원하게 되었습니다. 우아한테크코스 프리코스과정에  4주차의 내가 시간을 많이 투자한 부분과 느낀점, 부족한점을 작성하는 회고록입니다.

https://github.com/woowacourse-precourse/java-lotto-7/pull/181

[로또] 최인호 미션 제출합니다 by inhooo00 · Pull Request #181 · woowacourse-precourse/java-lotto-7

드디어 3주차 미션이 끝났습니다. 갑자기 확 난이도가 어려워진 것 같네요ㅜ..!

2주차 미션까지는 즐거운 마음으로 배움에 임했는데, 그 마음은 어디 갔는지.. 3주차 미션까지 오니까 구현하기 급급합니다.

4주차 미션에서는 또 어떤 녀석이 올지 기대가 됩니다^^😇

 

 

 

항상 똑같지만 달라지는 나만의 MVC 클린코드 기준입니다. 계속해서 생각이 깊어지고 있는 게 느껴집니다.

1. 메서드 이름에 매개변수 관련 최대한 많은 정보가 담기도록 한다. → 메서드 이름에 최대한 많은 정보가 담기도록 한다. 클래스와 연계되어서도 읽힐 수 있도록 작성한다.
2. 하나의 메서드는 하나의 기능만 가지도록 구현한다. 기능이 많다면 메서드 분리를 진행한다. → 하나의 메서드는 하나의 기능만 가지도록 구현한다. 기능이 많다면 메서드 분리를 진행한다. 더해서 연속적으로 읽을 때 이해하기 힘든 코드도 메서드로 뺀다 ex) user != null && (user.getRole().equals("ADMIN") || user.getRole().equals("MODERATOR"))
3. 매개변수의 이름에도 의미를 잘 전달할 수 있게 구현한다.
4. 모든 클래스가 단일 책임 원칙을 지키도록 설계한다.
5. 프리코스 컨벤션에 맞춰서 코드를 구현한다.

 

1번에서 매개변수 관련 정보를 담는다는 부분을 없앴습니다.

3주차 코드를 구현하는 중, 매개변수가 바뀔 때마다 메서드 이름이 바뀌는 상황이 생겼기 때문입니다.

따라서 매개변수의 정보는 메서드에 담지 않고, 클래스(model)이 하는 행위라는 느낌이 들게하기 위해 “클래스와 연계되어서도 읽힐 수 있도록 작성한다.” 라는 새로운 기준을 새웠습니다.

 

2번에서 추가된 내용은 “연속적으로 읽을 때 이해하기 힘든 코드도 메서드로 뺀다” 입니다.

특히 if문을 읽다 보면 괄호 안에 boolean 값을 판별하기 어려울 때가 있습니다. 이를 메서드로 빼서 알기 쉬운 이름으로 넘기는 것이 더욱 클린코드에 맞는 것 같습니다.

 

 

 

2주차 공통 피드백에서 "테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다"는 피드백을 받고 고민해 보았습니다.

더 많은 장점이 있겠지만, 지금까지 제가 생각하고 있는 테스트 코드의 장점은 이렇습니다.

테스트를 짜는 목적은, 모든 상황을 수동으로 입력하여 확인하는 것이 비효율적이기 때문입니다.
서비스가 요구하는 예외 처리가 많아질수록, 이를 직접 입력하며 테스트하는 데는 많은 시간이 소요됩니다.
또한, 특정 기능을 구현하는 과정에서 다른 기능에 예기치 않은 오류가 발생할 가능성도 있습니다.
테스트 코드를 작성하면 바로 이러한 문제를 해결할 수 있습니다. 자동화된 테스트는 각 기능이 예상대로 작동하는지, 예외 상황을 올바르게 처리하는지를 빠르고 안정적으로 확인할 수 있습니다.
기능이 추가되거나 수정될 때, 테스트를 통해 다른 기능에 미치는 영향을 즉시 파악할 수 있어, 전체 코드의 안정성을 높일 수 있다고 생각합니다. 때문에 예외에 집중해서 테스트 코드를 작성했던 것 같습니다.

 

 

 

📍 문제 요구 사항

이번 회차에는 두 가지 새로운 학습 목표가 추가되었습니다.

1. 클래스(객체)를 분리하는 연습
2. 도메인 로직에 대한 단위 테스트 작성 연습

이번 미션에서 뿐만 아니라, 항상 MVC 패턴으로 구현하라는 명확한 요구사항은 없었지만, 요구사항과 학습 목표가 점점 늘어남에 따라 코드 구조가 자연스럽게 MVC 패턴에 가까워지는 것이 좋겠다고 느꼈습니다. 저는 1주차부터 MVC 모델로 구현하고 있었지만, 다시 한번 돌아보았습니다. 특히 도메인 로직에 집중해 보았습니다.

 

로또를 직접 구매하는 입장에서 몰입해서 생각해보니, 도메인의 구조가 어느정도 떠올랐습니다. 처음에는 "로또", "판매기계", "당첨결과", "나(로또 구매자)", "로또 매니저"로 생각하며 이를 바탕으로 초기 도메인 모델을 설계하여 docs를 작성했습니다.

다행히 프로젝트가 끝날 때까지 이러한 도메인 구조에 큰 변경 사항은 없었습니다.

이제는 비교적 복잡하지 않은 로직에서 도메인 분리를 하는 감각이 생긴 것 같아서 뿌듯합니다.😆

 

 

 

📍 Keep

인터페이스 사용하기.
이번에는 테스트코드를 작성을 위해 다른 방법을 생각해 보았는데요, NumberGenerator 인터페이스를 생성해서 원하는 값이 나오도록 설계해 보았습니다.

package lotto.util.generator;

public interface NumberGenerator<T> {
    T generate();
}

 

아래처럼 테스트코드를 작성하기 전에 전역 클래스로 generate() 메서드를 구현해 놓으면 랜덤 값이 아닌, 원하는 값으로 테스트할 수 있습니다.

    private static class FixedNumberGenerator implements NumberGenerator<List<Integer>> {
        @Override
        public List<Integer> generate() {
            return List.of(1, 2, 3, 4, 5, 6);
        }
    }

전에는 인터페이스는 단순히 설명서 느낌으로 "이런이런 기능을 반드시 구현하라!" 라는 느낌만 가지고 있었는데, 이번 기회에 테스트에도 용이하다는 사실을 알게 되었습니다. 시야가 점점 넓어지는 느낌이 듭니다.

 

추상 클래스 사용하기.

package lotto.util.validation;

public interface Validator<T> {
    void validate(T target);
}

package lotto.util.validation;

import static lotto.exception.ExceptionMessage.NOT_MUST_BE_NULL;

public abstract class AbstractValidator<T> implements Validator<T> {
    public void validateNotNull(T target) {
        if (target == null) {
            throwFail(NOT_MUST_BE_NULL.format());
        }
    }

    public void throwFail(String exceptionMessage) {
        throw new IllegalArgumentException(exceptionMessage);
    }
}

Validator 인터페이스와 AbstractValidator 추상 클래스를 사용해 보았는데요.

Validator만을 구현해서 전혀 다른 방식의 검증을 적용할 수도 있고, AbstractValidator를 상속받아 공통 메서드를 활용할 수 있게 해보았습니다.

다시 보니 로직 자체는 의도가 명확하지만, 예외 처리 구조의 확장성에 과하게 초점을 둔 것은 아닌지 의문점이 들긴 합니다.

하지만 이런 구조는 계속해서 가지고 나아가보고 싶습니다.

 

 

 

📍 Problem

이번 과제에서 가장 애먹었던 부분은 메서드 길이가 15줄을 넘지 않도록 제한하는 것이었습니다.

저만의 코드 컨벤션으로 return 전에 한 줄을 띄우도록 하고 있는데, 이 방식이 try-catch문과 함께 사용될 때는 줄 수가 쉽게 초과되는 상황이 발생했습니다.
이를 해결하기 위해 최대한 메서드 길이를 줄이려고 출력문을 한 줄로 합치는 등의 방법을 시도하여 15줄 제한에 맞추도록 구현했습니다.

 

 

 

📍 Try

4주차는 아마 굉장히 어려운 미션일 거라고 생각합니다. 때문에, 최대한 실제로 운영하는 서비스처럼 구현하고 싶습니다.

이번에는 내가 실무자라는 느낌으로 미션에 임하면서 클라이언트에게 프로그램을 전달하고, 협업을 위해 할 수 있는 설계를 하기 위해 노력할 예정입니다.🫡

 

 

 

📍 배운점

코드로 배운 것보다 생활습관에서 배운 것이 더 컸었던 3주차였던 것 같습니다. 

멘탈 관리를 잘해야겠다는 생각이 크게 들었습니다.. 미션을 하던 당시에는 하루하루 풀리지 않는 문제에 힘이 들었고 시간은 의미없이 흘러가는 듯이 느껴졌습니다.

여러가지 일정이 겹치면서 잠이 부족한 상태라, 3주 차 때 컨디션 조절을 잘하지 못해 힘든 상황 속에서 미션을 수행하다 보니 몸도 마음도 지쳤습니다.

4주차 미션 때는 스스로가 ‘잘 해낼 수 있는 환경’을 만들며 비단 개발 실력뿐 아니라 개발 외적으로도 성장하는 개발자가 되고 싶습니다.

 

 

 

📍 마무리

드디어 끝이 보이는군요.. 모두 마지막 미션까지 후회없이 불태워 봅시다!!🔥