[우아한테크코스] 프리코스 1주차 코드 리뷰 후기

[우아한테크코스] 프리코스 1주차 회고

1주차 코드 제출 후, 프리코스 커뮤니티를 통해 코드 리뷰를 해줄 사람을 구해 리뷰를 시작했다.

코드 리뷰 피드백 요약

클래스와 메서드 네이밍 개선

클래스와 메서드의 이름이 직관적이지 않다. 특히 `CalculatorModel`과 `CalculatorUtils`의 기능이 혼재되어 있어, 더 명확한 네이밍과 구조 개선이 필요하다.

 

이는 회고에서도 말했던 건데, 다음에는 클래스 이름을 더 구체적으로 짓고자 한다. 각 클래스가 이름에 걸맞는 기능들만을 담당하도록 세분화하고 메서드도 한 가지 기능만 수행하도록 할 계획이다.

 

입출력 로직의 MVC 패턴 분리

`Application.java`에 입출력 로직을 넣어두었는데  view 클래스로 분리하는 것이 좋겠다. 

 

이것도 회고에서 말했던 건데 print문은 view라고 생각하지 않았고, 그래서 view 클래스로 따로 분리하지 않았는데 다음에는 분리해서 MVC 패턴을 확실히 적용해보려고 한다.

 

자원 해제 및 예외 처리

`Console.readLine()`을 사용할 때 자원을 제대로 해제하는 것이 중요하다. 이때, `try-with-resources`나 `finally` 블록을 활용해 자원을 해제하고, `Console.close()`를 호출하는 방식으로 마무리 할 수 있다. 

 

자원을 해제해야한다는 것을 처음알았기에 관련해서 좀 더 공부해야겠다.

 

static과 DI 적용

`CalculatorController` 생성 시 새로운 `CalculatorModel` 인스턴스가 만들어져 강한 결합이 발생하므로, 생성자 주입(Dependency Injection)을 사용하는 것이 좋다.

 

이건 관련 책에서 본 내용이었는데 , 막상 직접 적용할 때 기억이 가물가물했다...

 

불필요한 인스턴스 생성을 막기 위해 필요한 경우 기본 생성자를` private`로 선언해서 제약을 주자

 

클래스를 만들면 자동으로 생성자가 추가되기 때문에 확실히 이러는게 좋을 것 같다. + 지식1...!

 

매직 넘버와 상수화

코드 내에 사용된 `"\n"`, `"\d"`등의 문자열은 매직 넘버에 해당하므로, 의미 있는 이름으로 상수화하는 것이 가독성을 높이는 데 도움이 된다.

 

TDD 및 리팩토링 제안

TDD를 사용할 때, 커밋 단위를 테스트 작성과 로직 구현으로 분리하나? 테스트 코드 내 중복된 코드를 리팩토링하고, `BeforeEach`를 활용해 공통 초기화를 분리하는 것이 좋다.

 

TDD에 대해 알아보면서 나는 테스트 코드를 먼저 작성하고, 애플리케이션이 작동될 정도로만 구현해놓고 나서 커밋하면 되고 이후, 중복코드는 리팩토링을 통해 고치면 된다고 생각했다.

 

객체지향 설계와 패러다임 연습

TDD, MVC 등을 적용하기 전에 객체지향 개념을 확립하고 코드 구조를 설계하는 연습이 선행되면 더 좋을 것이다.

 

이 말이 맞는 것 같다. 처음엔 구조를 미리 설계하지 않고 단순히 입력, 로직, 출력 정도만 생각했다. 글 결과로 메서드가 과도하게 많은 역할을 담당하고, 클래스들 간 기능이 혼재되었다. 앞으로는코드를 작성하기 전에 구조를 설계해 각 역할을 명확히 분배하려고 한다.

---

다른 사람들의 코드에 대한 후기

내가 지금까지 보아왔던 코드들은 대부분 MVC 패턴, 즉 Model, Controller, View로 나누는 구조였다. 하지만, MVC에 국한되지 않고 코드를 작성하는 사람들도 많았다. 또한 폴더 구조를 한 눈에 파악할 수 있게 클래스 다이어그램을 남기거나, 모든 상수를 한 곳에 모아서 관리하는 사람도 있었다

 

그 중에서도 인상깊게 본 코드가 하나 있다. 이 코드는 MVC 패턴을 활용하지 않았지만, OCP(개방-폐쇄 원칙)를 잘 준수한 코드였다. OCP는 "확장에는 열려 있고, 수정에는 닫혀 있다"라는 뜻인데, 말로만 들었을 때는 잘 이해가 가지 않았다. 그런데 이번 코드를 보며 그 의미를 어느 정도 이해할 수 있었다.

 

특히 `Adder` 클래스의 설계가 깔끔해서 인상적이었다. `Operator`라는 추상 클래스를 만들어 `Adder`이 상속하도록 설계한 방식이 참 좋았다. 나중에 이 코드에 대한 리뷰를 보니, 추상 클래스에 상태(state)가 없다면 인터페이스를 사용하는 게 더 낫지 않느냐는 질문이 있었고, 이에 대해 그게 맞는 것 같다는 대화가 오갔었다.

 

또한 `AppConfig` 클래스를 만들어 Controller가 아닌 이 클래스에서 각 객체를 생성하고 관리하도록 설계한 점도 인상적이었다. 이렇게 하면 나중에 기능을 수정하거나 확장할 때 최소한의 수정으로 변경할 수 있어 유지 보수가 훨씬 쉬울 것 같다는 생각이 들었다.

 

역시 다른 사람들의 코드를 보는 건 정말 유익한 경험인 것 같다. 내가 몰랐던 것을 배우고, 시야를 더 넓힐 수 있다고 느낀다. 또, 다른 사람들이 코드에 대해 나누는 대화를 보면 다양한 관점을 접하게 되어 많은 도움이 된다. 다만, 무엇이 구체적으로 더 좋은지 확실히 알지 못해 아쉬움도 있다. 공통 피드백을 받긴 하지만, 개인적으로 피드백을 받을 수 있다면 더 큰 도움이 될 것 같다.