[우테코 7기 프리코스 1주 차] 객체 지향

프리코스 1주 차, 나라는 PQ의 루트는 항상 우테코였다. 

함께 진행하는 사람들의 열정에서 긍정적인 스트레스를 많이 받았고 느끼는 바가 많았다.

 

기록하고, 회고해 보자!

 

---

 

학습 목표

 

1주 차 학습 목표

 

 

첫 주부터 어려운 문제가 나오지는 않을까... 내심 걱정했는데 학습 목표를 보니 한결 맘이 편했다.

 

---

 

과제 진행 요구 사항 / AngularJS 깃 커밋 메시지 컨벤션

 

1주차 과제 진행 요구 사항

 

 

AngularJS 깃 커밋 메시지 컨벤션에서는 CHANGELOG 파일을 관리하는 방법을 시작으로, 예시를 통해 올바른 커밋 메시지들을 참고할 수 있었다.

 

구글 상단에 노출되던 커밋 컨벤션들 중 어떤 것을 사용하는 게 맞는지 궁금했는데 우테코에서 정해줬으니 앞으로는 이거다.

 

https://gist.github.com/stephenparish/9941e89d80e2bc58a153

Git Commit Message Conventions

 

---

 

기능 목록 / 기능 요구 사항

 

 

과제 진행 요구 사항을 읽어보면 우선 기능 목록을 README에 작성하라고 한다.

문제를 확인하려고 기능 요구 사항으로 빠르게 스크롤을 내렸던 기억이 난다.

 

 

간단하다... 너무 간단해서 내가 뭔가 놓친 게 아닐까 걱정된다.

그래서 계속 문제를 읽다 보니 요구 사항이 너무 모호하게 느껴졌다.

1. \n 이 (ENTER/RETURN)을 키보드로 입력받은 걸까? 그저 입력된 텍스트일까?
2. 커스텀 구분자를 사용한다면 이는 기본 구분자(쉼표, 콜론)와 동시에 사용되는 걸까?
3. 커스텀 구분자로 무엇이든 사용해도 되는 걸까? (숫자를 제외한)
4. 구분자만 있다면 어떻게 처리해야 할까, 공백을 구분자로 감싼다면 어떻게 처리해야 할까?
5. 양수라면 소수도 포함인 걸까? 자릿수는 제한이 없는 걸까?

실제로는 이보다 많은 의문이 있었지만 문제를 해결하다 보니 당연시되는 점들은 제외했다.

테스트 클래스를 빨리 확인했더라면 의문이 줄었을 텐데...

 

궁금한 점을 누군가에게 물어볼 수도 없었다. 해당 주차가 마무리되기 전까지 문제에 대한 질의응답이 금지되었기 때문이다.

어쩔 수 없이 혼자서 결론 내렸다. 수정에 용이한 코드를 작성하기를 원해서 그랬을 거라고.

---

 

슬픈 기억

 

처음에 작성한 README의 여러 섹션 중 메서드 호출 흐름을 깃 커밋 기록에서 가져왔다.

README 초안, 메서드 호출 흐름

부끄럽다...

 

객체 지향을 사랑한다고 말하며 스프링 프레임워크로 프로젝트도 몇 번이나 해봤지만, 그저 문제 해결에만 몰두한 흔적이 보인다.

객체 지향을 잘못된 방법으로 사용한 게 아니라 전혀 고려하지 않았다는 것이다.

액티비티 다이어그램

 

화룡정점, 클래스는 찾아볼 수 없는 다이어그램까지 그렸었다.

여기까지 커밋을 해두고 내일 기능 구현해야지~ 그저 신이 났었고...

 

다음 날 메인 메서드에 코드 작성하면서 접근 방법 자체가 잘못된 것을 알았다.

---

 

 

객체 지향

 

 

 

기존에 작성한 잘못된 섹션을 전부 지우고 다시 시작했다.

 

문제를 해결하기 위한 방법에 초점을 맞추지 않고 문제를 나눠보며 클래스에게 역할과 책임을 부여했다.

 

클래스에 역할과 책임을 부여

 

객체 지향이 항상 최선의 선택은 아니지만, 변경한 분석과 설계가 출제 의도에 더 부합한다고 생각한다.

 

SOLID 원칙에 따라서 클래스를 더 세분화하여 객체지향적인 설계를 더 강화할 수도 있지만, 이는 지나치다고 판단하여 적정 수준에서 설계를 유지했다. 같은 이유로, 서비스 구현 시 인터페이스를 따로 정의하지 않고 바로 클래스로 구현했다.

 

---

 

구현

 

 

우테코 디스코드를 보니 TDD가 인기가 많았지만 본 문제가 TDD를 적용하기엔 너무 작다고 판단했다. 그래서 나는 각 예외 케이스들을 어떤 클래스에서 처리해야 할지에 더 집중했고 이후에 테스트 코드를 작성했다.

 

README에 적어둔 입력 형식의 제약 사항을 확인하면서, 최적의 위치에 예외 처리를 배치하며 구현을 마쳤다. 큰 어려움은 없었다. 아마도 설계에서 시행착오가 있었고, 그때 충분한 시간을 들여 고민했기 때문인 것 같다. 한 번 갈아엎기도 했고.

 

PR 이후, 우테코 사이트에서 예제 테스트를 실행해 보니 문제없이 정상적으로 완료된 것을 확인할 수 있었다.

 

예제 테스트 결과

 

---

 

마무리, 회고

 

5F 회고

 

1. 사실 (Facts)

• 코딩 테스트에 절여진 사고로 절차 지향적인 설계를 했고, 이를 올바르게 객체 지향적으로 변경했다.

 

2. 감정 (Feelings)

• 실수를 확인했을 때 부끄러움을 넘어 스스로에게 실망했다. 나름 자신 있다고 생각했는데 아직 부족하다는 것을 느꼈다.

 

3. 발견 (Findings)

• 객체 지향적으로 설계하는 것은 문제를 바라보는 관점만 달라졌을 뿐, 복잡하게 해결하는 방법이 아니었다.

 

4. 향후 행동 (Future Actions)

• 문제 해결만을 쫓는 실수를 반복하지 않겠다. 더 나은 해결 방법을 찾는 행동이 익숙해지도록 노력하겠다.

• TDD를 시도해보겠다.

 

5. 피드백 (Feedback)

 

2024.10.22 - [우아한테크코스] - [우테코 7기 프리코스 1주 차] 피드백

[우테코 7기 프리코스 1주 차] 피드백

 

---

 

깃허브

https://github.com/m-a-king/java-calculator-7

GitHub - m-a-king/java-calculator-7: woowacourse - first