[우테코] 😀프리코스 2주차 회고

---

🧾서론

프리코스 2주차가 끝났습니다.😢 저번 주차 과제에서 아쉬운 점이 많았었는데, 이를 해결하고 좀 더 나은 코드를 작성하려고 노력했었습니다. 분명 저번 주보다 많은 부분이 개선되었다고 생각했습니다!! 코드리뷰와 스터디를 하기 전까지....
어떤 과정을 통해 2주차 과제를 극복하려 했는지 회고를 통해 되집어 보려고합니다.👍

---

pr 주소

https://github.com/woowacourse-precourse/java-racingcar-7/pull/873

---

📗2주차 목표 회고

2주차 과제에서는 중점적으로 저번 주차 과제에서 아쉬운 점들을 개선하는 것이 목표였습니다!
목표 달성을 위해 코드를 작성할 때도 한 단계 한 단계씩 신중히 개선점을 생각했기 떄문에 시간이 더욱 오래 걸렸던 것 같습니다.😢
목표를 잘 이뤘는지? 밑의 글을 통해 확인해보겠습니다.

<최종 프로젝트 구조>
과제를 시작하기에 앞서 프로젝트의 전체적인 구조를 먼저 구성하였고 이를 토대로 진행했습니다👏

src
└── main
    ├── java
    │   └── racingcar
    │       ├── config
    │       │   └── AppConfig.java
    │       ├── controller
    │       │   └── RacingGameController.java
    │       ├── domain
    │       │   ├── car
    │       │   │   └── Car.java
    │       ├── exception
    │       │   └── ErrorMessage.java
    │       ├── service
    │       │   ├── CarSetupService.java
    │       │   ├── CarSetup.java
    │       │   ├── RacingGameService.java
    │       │   └── RacingGame.java
    │       ├── validator
    │       │   └── InputValidator.java 
    │       └── view
    │           ├── InputView.java
    │           └── OutputView.java
    test
    └── java
        └── racingcar
            ├── validator
            │   ├── CarNameValidatorTest.java 
            │   └── AttemptCountValidatorTest.java 
            ├── service
            │   ├── CarSetupServiceTest.java 
            │   └── RacingGameServiceTest.java
            └── ApplicationTest

---

1.객체지향원칙에 따른 코드를 작성하기[❗❗❗]

1-1 객체 생성을 전담하는 클래스를 만들기 ⭕

객체 지향원칙을 지키고자 노력하여 코드를 작성했습니다.
저번 주차 과제에서는 객체를 어디서 생성하고 주입하는지, 결합도를 낮추는 방법등 고민이 많았습니다. 결국 컨트롤러에서 많은 객체 생성을 하였었는데요, 이를 개선하기 위해 이번에는 객체의 생성을 하나의 클래스를 생성하여 의도적으로 전담시켜보았습니다.

<Appconfig.java>

이렇게 객체의 생성을 분리하니 관리하기도 편하고 컨트롤러나 메인에서 많은 역할을 주지 않아 결합도를 낮췄다고 저는 생각했습니다!👍

1-2 인터페이스 활용하기 ⭕

Service단의 비즈니스 클래스들에 인터페이스를 적용하였습니다! 제가 이번 과제에서 인터페이스를 쓴 가장 큰 이유는 명확한 설계 구조를 보여주는데 초점을 두었습니다.
이를 통하여 구현받은 클래스들이 무슨 역활인지 직관적으로 보일 것 같았습니다.

의문점과 고민😅

저는 이제까지 공통적인 기능이 필요한 클래스들에 인터페이스를 부여하여 다형성을 추구하였습니다. 하지만 스터디를 통해 인터페이스에 대해 많은 의견을 나누었고, 그 중 기억에 남은 말이 있었습니다.

하나의 클래스에만 사용할 인터페이스를 구현하는게 좋은 방법인가?

이제까지 자연스럽게 인터페이스를 사용해온 저로서는 생각지 못한 말이였고, 그 질문에 대해 고민했습니다. 인터페이스의 장점들을 나열하자면 사용해야 하는 이유에 대해 명확한 답이 나오지만 자기 자신에게 "어떤 의도를 가지고 인터페이스를 사용하고 있었나?" 라는 질문을 던질 수 있었고 인터페이스에 대한 공부와 스스로의 반성을 하고 있습니다.😤

❌개선점:

너무나도 큰 실수를 하였기에 개선점에 크게!!!!!! 표시하였습니다.
스스로도 많이 반성하고 있고 긴 시간 많은 리팩토링 과정을 거쳤는데도 생각하지 못했다니, 반성 !! 또 반성입니다!!

🚫나는 MVC 패턴 위반을 하였다..

<RacingGameService.java>

    private final OutputView outputView;

    public RacingGameService(OutputView outputView) {
        this.outputView = outputView;
    }

    @Override
    public void raceGame(List<Car> cars, int count) {
        for (int i = 0; i < count; i++) {
            playRound(cars);
            outputView.displayCarPositions(cars);
        }
    }

저의 중대한 실수가 무엇인지 보이실까요?? 많은 분들이 봐버린 저의 실수는

service 단에서 view를 의존성 주입 받아 사용하고 있다는 것입니다.

😱😱 아차차! Controller 단에서 Service와 View를 깔끔하게 연결하려 했건만, 어느 순간 Service에서 바로 View로 결과를 넘겨 처리해버린 것을 뒤늦게야 알아차리다니요…! TDD 방식으로 출력 결과를 테스트하고 기능을 작성하는 과정에서 일어난 실수라고는 해도, 여러 차례 리팩토링을 거치는 동안에도 눈치채지 못한 사실에 부끄러워 숨고 싶을 지경입니다. 😭

💡 이번 실수를 통해 배운 교훈 💡

1. 역할의 중요성
   이번 경험은 레이어 간 역할 분리의 중요성을 다시금 일깨워주었습니다. Service에서 View로 바로 데이터를 넘겨 출력할 경우, Controller가 관리해야 할 흐름 제어가 분산되며 코드의 결합도가 높아질 위험이 있습니다. 이로 인해 유지보수가 어려워질 수 있음을 이번 실수를 통해 깊이 깨닫게 되었고, 앞으로는 각 레이어의 책임과 역할을 더욱 신중하게 고려하며 코드를 작성하려 합니다.

2. 테스트와 코드 흐름 점검의 중요성
   리팩토링을 여러 차례 거치다 보면 작은 실수가 발생할 수 있기에, 테스트와 함께 코드 흐름을 정기적으로 점검하는 습관을 들이는 것이 중요하다는 점을 배웠습니다. TDD로 출력 결과를 테스트하며 기능을 구현하다 보니 실수하기 쉬운 부분이 있었지만, 이를 예방하기 위해 각 레이어 간 의도된 흐름을 테스트하는 것도 필요함을 느꼈습니다.

3. 성장과 교훈의 기회로 삼기
   실수는 성장의 발판이 됩니다. 이번 경험을 통해 실수의 과정을 되짚고 개선해나감으로써 더 탄탄하고 유지 보수하기 좋은 코드를 작성할 수 있는 계기로 삼으려 합니다. 앞으로는 리팩토링 시에 코드의 흐름과 역할을 재점검하는 습관을 들여, 보다 주의 깊고 책임 있는 코드 작성을 목표로 나아가겠습니다!
   
   
   

---

2.테스트 코드 활용하기[⭕]

    test
    └── java
        └── racingcar
            ├── validator
            │   ├── CarNameValidatorTest.java 
            │   └── AttemptCountValidatorTest.java 
            ├── service
            │   ├── CarSetupServiceTest.java 
            │   └── RacingGameServiceTest.java
            └── ApplicationTest

지난주 과제에서는 TDD(Test-Driven Development)방식으로 개발하는 데 미숙함이 있었던 점을 발견했지만, 이번 주차 과제를 통해 이를 개선하고자 많은 노력을 기울였습니다. 특히, 코드 작성의 초기 단계부터 테스트를 주도적으로 작성하여 코드의 품질을 높이고, 신뢰할 수 있는 테스트 케이스 만드는 데 집중했습니다. 개선된 부분을 중점으로 아래와 같은 성과를 이루었습니다.


1. 👏단일 기능 테스트 코드 작성 후 기능 구현

TDD 방식을 철저히 따르며, 기능 작성에 앞서 단일 기능 테스트 코드를 먼저 작성하고 나서 기능을 구현하는 프로세스를 거쳤습니다. 이를 통해 코드 작성에 다소 시간이 걸렸지만, 탄탄한 기반을 갖춘 프로그램을 완성할 수 있었습니다. 테스트 코드가 선행되다 보니 코드의 정확성과 신뢰도가 높아졌고, 예상치 못한 오류를 사전에 방지할 수 있었습니다. TDD의 장점인 버그 방지와 견고한 코드 작성의 의미를 실감할 수 있는 좋은 경험이었습니다.


2. 👏JUnit의 다양한 기능 활용

JUnit의 강력한 기능들을 적극적으로 활용한 것도 이번 프로젝트의 성과입니다. 특히 @ParameterizedTest 어노테이션을 통해 다양한 매개변수를 테스트 메소드에 전달하며 코드의 재사용성을 높였습니다. 또한 @MethodSource를 사용하여 공통 메서드를 하나로 정리함으로써 테스트 코드의 중복을 줄이고 간결하게 관리할 수 있었습니다. 이러한 JUnit의 기능들을 제대로 활용하며 테스트 코드가 보다 효율적이고 가독성 있게 작성되는 성과를 얻었습니다.


3. 👏다양한 예외 상황을 고려한 테스트 코드 작성

이번 프로젝트에서는 단순히 정상적인 입력만을 테스트하는 데 그치지 않고, 다양한 예외 상황에 대비한 테스트 코드도 추가적으로 작성했습니다. 덕분에 프로그램의 예외 처리가 보다 완성도 높게 구현될 수 있었고, 사용자 입력 실수나 예기치 않은 상황에서도 안정적으로 동작할 수 있도록 개선할 수 있었습니다. 이로써 예외 상황을 포함한 다양한 시나리오에 대비한 코드 작성의 중요성을 깨달을 수 있었습니다.

❌개선점

1. 우테코에서 제공한 테스트 기능을 활용해보자

랜덤 출력에 대해 많은 고민을 하고 테스트 코드를 작성했습니다. 하지만 우테코에서 제공한 테스트에 해당 기능이 있었습니다. 내부 구조를 보니 mock객체를 생성하여 테스트를 진행하는 방식이였고, 아직 mock에 대해 이해가 부족한 저로서는 쓰지 못한게 아쉬웠습니다.
3주차 과제에서는 우테코에서 제공한 테스트기능을 적극 활용해 보도록하겠습니다.

---

🧾코드 리뷰 모음

<좋은 점>

• 테스트케이스, 예외케이스를 문서화 한것
• 기능 별로 객체로 분리를 잘했다.
• 테스트 코드에 @ 어노테이션을 잘 활용했다.
• 여러 테스트 코드를 작성하였다.
• stream 사용을 적절히 사용하여 가독성이 좋았다.

<개선점>

• MVC 패턴을 위반한것
• 우테코에서 제공한 테스트 코드를 활용하지 못한 것
• InputView에서 입력만 받지말고 출력까지 담당하는것 고려하기
• 동일한 출력을 담당하느 기능을 인터페이스로 만들어서 캡슐화 하기
• 랜덤 기능을 인터페이스화 해서 결합도 낮추기
• 검증로직을 좀 더 한곳에 모아보자

---

💡2주차 소감

이번 과제를 통해 스스로에게 "저는 저번 주보다 성장한 프로그래머가 되었을까?"라는 질문을 던졌을 때, 저는 자신 있게 "예"라고 답할 수 있을 것 같습니다. 많은 부분에서 개선하려고 노력했고, 그 노력의 결과로 긍정적인 변화를 적용하는 데 성공했습니다. 그러나 2주차 과제는 실수와 아쉬운 점이 많았던 점도 사실입니다.

특히 2주차 프리코스 오프라인 스터디에서는 굉장히 흥미로운 주제들에 대해 많은 이야기를 나눌 수 있었습니다. 다양한 관점에서 의견을 나누고, 서로의 경험을 공유하는 과정이 저에게 큰 자극이 되었고, 이는 제 개발 역량을 한층 더 향상시키는 데 기여했습니다.

🔻1. private 의 범위 : private 메서드에 대한 테스트는 어떻게 해야하나?

클래스에서 내부적으로만 사용하는 메서드들에 대해서 private으로 접근지정자를 지정하는 것이 대중적일 것입니다. 그렇다면 TDD방식으로 개발을 진행한다면 해당 메서드들에 대한 테스트들도 진행해야하나? 라는 의문이 들었습니다.
의문을 해소하기 위해 여러 글들을 찾아보았고 결론적으로 말하자면 TDD도 유연하게 진행해야 한다는 것이 저의 생각입니다. private 메서드들을 쓰는 public 메서드를 테스트 하면 자연스레 하위 메서드들도 테스트 되는 것이 아닌가?라고 생각하고 이를 적용하려고 합니다.

🔻2. 인터페이스의 역활 : input,output도 인터페이스로 하면 장점

저는 입력과 출력에도 인터페이스를 적용할 생각을 하지못했습니다. 하지만 스터디원 한분이 적용하신걸 보았는데요, 처음에는 이렇게까지 해야하나? 라는 생각이 들었지만 생각해보니 그에 따른 편리함과 유용성이 매우 컸습니다! 예를 들어보면
입력을 받는 기능을 명시한 Input인터페이스가 있고 이를 구현한 두개의 클래스가 있다고 가정하겠습니다.

<Input 인터페이스>

    public interface Input {
    String read(); // 입력을 읽는 메서드
    } 

<파일입력 클래스와, 콘솔입력 클래스>

//파일 입력 클래스
public class FileInput implements Input {

    @Override
    public String read() {

    }
    
// 콘솔 입력 클래스
public class ConsoleInput implements Input {

    @Override
    public String read() {

    }
}

<main.java>

public class Main {
  public static void main(String[] args) {
      // Input 자료형으로 ConsoleInput 객체 생성
      Input consoleInput = new ConsoleInput(); 
      String userInput = consoleInput.read(); // 콘솔로부터 입력 받기
      System.out.println("User Input: " + userInput);

      // Input 자료형으로 FileInput 객체 생성
      Input fileInput = new FileInput("input.txt");
      String fileData = fileInput.read(); // 파일로부터 입력 받기
      System.out.println("File Input: " + fileData);
  }

그렇다면 main에서는 필요에 따라 유연하게 클래스들을 교체하면서 진행할 수 있습니다.
이에 따른 장점으로는

• ⭕유연성:
  Input 인터페이스를 사용하여 ConsoleInput 또는 FileInput 객체를 동적으로 교체할 수 있습니다.
• ⭕다형성:
  동일한 타입(Input)을 통해 서로 다른 구현체를 다룰 수 있어, 코드의 재사용성과 유지보수성을 높입니다.
• ⭕코드 간결성: 인터페이스를 자료형으로 사용함으로써, 코드가 더욱 간결하고 명확해집니다.

---

🔻3. MVC를 반드시 적용해야 하는가? main에서 모든 처리를 다하면 안되나?

저는 그동안 MVC 패턴을 사용하여 프로그래밍해왔고, 이 방식이 제 개발 습관으로 자리잡았습니다. 하지만 최근 우테코 프리코스 영상에서, 강사께서 main 메서드 안에서 모든 처리를 시연하신 것을 보면서 많은 고민을 하게 되었습니다. MVC 패턴을 고수하며 과제를 진행해온 저에게, 이러한 접근 방식이 과연 옳은 것인지에 대한 의문이 들었습니다.

강사님이 보여주신 방식은 참여자들이 개발의 특정 틀에 가두지 않고 다양한 방법으로 도전해보라는 의도로 진행된 것이라고 생각합니다.
실제로 main 메서드 안에서 모든 처리를 수행해도 테스트는 통과할 수 있겠지만, 여러 가지 고민 끝에 내린 결론은 제 기존 방식을 그대로 유지하는 것입니다. 개발에 정답은 없다고 생각합니다. 그러나 제가 경험한 바에 따르면, MVC 패턴은 가독성과 유지보수성을 높이며, 책임을 분산시키는 데 큰 도움이 됩니다. 이러한 이유로 저는 지금까지 공부해온 MVC 패턴이 저에게 최선의 해결책이 될 것이라고 확신합니다.

🔻4. static 의 필요성은?

저는 static 을 최대한 지양하라고 배웠고 그렇게 써왔습니다❗ 하지만 정확히 언제 static을 효율적으로 사용할지 고민이 많았었는데요, 이번 기회에 공부를 하여 추후에 협업 프로젝트 진행시 util 과 같이 공통적으로 쓰기 편한 클래스에 적용해보려고합니다!.

😤앞으로의 다짐

앞으로 남은 2주 동안 어떻게 발전할 수 있을지에 대한 걱정과 기대가 동시에 듭니다. 새로운 기술과 개념을 배우고, 이를 실제로 적용해보는 과정에서 많은 도전과 어려움이 있겠지만, 그만큼 성장할 수 있는 기회도 많을 것이라고 믿습니다. 이 기간 동안 더욱 열심히 학습하고, 실력을 쌓아나가며 제 자신을 한 단계 끌어올릴 수 있기를 기대합니다!