위 사진과 링크는 작년에 진행한 우아한테크코스 7기 프리코스 1주차 회고입니다.
이때도.. 대학생이었는데 여전히 대학생 신분으로 우아한테크코스 프리코스를 진행 중입니다.
(2023년부터 시작해서… 벌서 프리코스만 3번째 도전 중입니다 🤦🏻♂️ 그래도 끝까지 화이팅!)
다행인 건 작년에는 5전공 시험들로 인해 시간이 빠듯했는데 올해는 막 학기를 진행 중이라 시험을 1개만 본다는 점에서 너무 다행인 것이죠….
과제 목표
본론으로 넘어가서 이번 프리코스 8기 1주차는 작년 1주차와 동일했습니다.
- Git과 GitHub, IDE 등 실제 개발을 위한 환경에 익숙해지기.
- 문자열 계산기 구현하기
문제 자체는 익숙했지만, 이번에는 더 나은 구조로 리팩토링하는 것에 초점을 맞췄습니다.
단순히 작동하는 코드가 아니라, 이 코드가 왜 이렇게 설계되어야 하는가를 저 스스로 납득하면서 작성하려 했습니다.
구현 순서
이번에는 단순히 기능부터 구현하지 않고
입력 → 출력 → 도메인 비즈니스 로직 → 통합 + 예외 처리 → 테스트 코드 작성이 순서로 진행하였습니다.
이와 같이 단계를 나눈 이유는 프로그램의 흐름을 사용자의 입력이 어떻게 처리되어 결과로 이루어지는지 정확하게 파악하기 위함입니다.
처음부터 모든 로직을 한 번에 짜기보다는 점진적으로 입력과 출력 구조를 정의하고 도메인을 채워나갔습니다.
이런 구현 순서 덕분에 기능 간의 의존 관계를 명확히 이해할 수 있었고, 리팩토링할 때도 변경 범위를 쉽게 파악할 수 있었습니다.
구현시 고민한 점
- 어떻게 분리해야 단일 책임 원칙(SRP)를 지킬 수 있을까?
- Stateful 하게 설계할까, Statelee 하게 설계할까?
이 두 가지를 고민했습니다.
1. 어떻게 분리해야 단일 책임 원칙(SRP)를 지킬 수 있을까?
처음에는 Calculator라는 객체 안에 입력값 검증, 문자열 파싱, 연산 처리 등 모든 로직을 몰아넣었습니다.
하지만 이렇게 하게 되면 클래스의 역할이 불분명해지고 테스트하기가 어려웠습니다. 단일 책임 원칙을 지키지 못했다는 뜻입니다.
그래서 책임을 세분화하는 과정을 겪었습니다.
숫자 검증과 파싱은 Number 객체, 여러 숫자의 연산은 일급컬렉션인 Numbers 객체를 만들어 분리하였습니다.
이렇게 분리하면 단일 책임 원칙(SRP)을 적용할 수 있었고, 각 객체가 한 가지 역할에만 집중할 수 있게 되었습니다.
결과적으로는 코드 응집도도 높아지고 테스트 작성이 훨씬 수월해졌습니다.
2. Stateful 하게 설계할까, Stateless 하게 설계할까?
ExpressionParser를 Stateful 하게 설게할지, Stateless 하게 설계할지 많은 고민을 했습니다.
처음에는 내부 상태를 유지하기 위해서 Stateful 방식으로 구현했었습니다. 하지만 매번 인스턴스를 새로 생성해야 했고, 상태 관리가 불필요하게 복잡해졌습니다.
ExpressionParser 클래스의 역할은 ‘문자열을 특정 규칙에 따라 분리하는 행위’를 제공하는 객체이기 때문에 이 역할에 집중하기로 했고, 데이터를 저장하지 않는 Stateless한 객체로 변경했습니다.
Stateless한 객체로 설계했기에 재사용성과 안전성이 높아졌고, 유지보수도 쉬워졌습니다.
마무리
이번 1주차는 작년보다 여유롭게 진행할 수 있었습니다.
같은 문제를 풀면서도 미흡했던 부분이 생각나서 그때보다 훨씬 명확한 기준으로 코드를 작성하고 리팩토링할 수 있었다는 점이 좋았습니다.
남은 과제도 화이팅! 👍🏻
코드: https://github.com/giwoong01/java-calculator-8/tree/giwoong01
PR: https://github.com/woowacourse-precourse/java-calculator-8/pull/286
