기능구현 목록

Domain

구분자 processor
- [x] 구분자 추가 요구 사항이 있는지 확인( 확인해서 boolean 출력)
- [x] 구분자 추출 기능
- [x] 구분자를 제외한 String 추출 기능
- [x] 구분자 List 만들기 기능
- [x] 구분자 입력 validator
입력값 Validator
- [x] 구분자로 처리 된 값들 이외의 숫자가 아닌 문자가 있는 경우 IllegalArgumentException 을 Throw ( 오류 사유 작성 )
- [x] 구분자가 숫자인지 확인하는 validateDelimeter
- [x] 문자로 된 숫자가 숫자가 맞는지 확인하는 isInteger
계산기
- [x] List<Integer>을 받으면 계산해주는 계산기
split procesor
- [x] 문자열을 구분자로 잘라줌

<aside> 💡

CODE REVIEW DISCRIPTION

💻 1주차 미션 - 문자열 덧셈 계산기

👉 로직 실행 순서

프로그램이 시작되면 문자열을 입력받습니다.
들어온 문자열은 가장 먼저 커스텀 구분자 요청을 확인하고 요청이 정당한지 검증합니다. 문자열의 커스텀 구분자 요청 부분을 Delimeter Segment라고 구분했습니다.
커스텀 구분자를 요청했다면 요청을 처리하고 구분자들의 List와 문자열의 나머지 부분을 반환합니다. 만약 커스텀 구분자 요청이 없다면 디폴트 구분자 List와 문자열을 그대로 반환합니다. 문자열의 부분을 Calculation Segment라고 구분했습니다.
Calculation Segment는 앞서서 처리된 구분자 List에 따라서 구분자 이외에 문자가 있는지 검증 과정을 거치게 됩니다.
Calculation Segment에 문제가 없다면 구분자를 기준으로 분해되어 숫자 List로 만들어지게 됩니다.
최종적으로 계산이 이루어집니다.

👉 Logic 논점

입력값에 대한 논점

🔴 소수 입력값은 들어오지 않는다고 가정했습니다. ( . 이 구분자와 혼동될 것이라 생각)

🔴 입력값이 공백으로 들어오게 되는 경우 예외처리를 하지 않고 0으로 계산되도록 하였습니다.

🔴 입력값이 "2,3," 다음과 같이 구분자 다음에 공백이 있는 경우를 예외 처리 하지 않고 계산했습니다.

🔴 구분자를 입력하지 않고 "2345" 와 같이 숫자로 들어오게 되면 하나의 숫자를 입력한 것으로 간주했습니다.

구분자에 대한 조건

🔴 구분자는 숫자를 사용할 수 없다.

🔴 구분자의 length는 1로 제한한다. (예를 들어 ,, 와 같은 커스텀 구분자 요청이 들어오게 되면 , 와 혼동되는 문제가 발생하고 이런 문제들을 전부 통제하기에는 과하다고 생각했습니다.)

설계구조에 대한 논점

저는 전처리 파트( Delimeter Segment 처리, Calculation Segment 처리)와 메인 파트( 덧셈 계산) 으로 구분해서 유지 보수나 로직의 변경점이 발생할 만한 부분을 기준으로 나누어 MVC 설계를 했습니다. MainProcessor와 Preprocessing은 각자 수행하는 기능은 크게 없지만 확장성을 고려해서 만들어 놓았습니다.

😄 감사합니다

</aside>

<aside> 💡

과제 소감

이번에 우테코 프리코스를 통해 처음으로 코딩 과제를 진행했습니다. 처음엔 어떤 기능을 추가하고 어떻게 설계할지에 대해 대략적인 가이드라인만 세우고 개발을 시작했습니다. 하지만 이렇게 하다 보니 커밋의 개수가 많아지고, 설계를 다시 해야 하는 상황도 발생했습니다.

두 번째 시도에서는 입력값과 반환값, 그리고 기능이 동작해야 할 순서를 구체적으로 계획한 후에 코딩을 시작했습니다. 그 결과 커밋 단위도 훨씬 명확해졌고, 논리적으로 설계할 수 있었습니다.

테스트 과정에서 각 클래스의 메서드를 테스트하는 것은 어렵지 않았지만, 컨트롤러 자체를 어떻게 테스트해야 할지 고민이었습니다. 그러던 중 'Mock'을 이용한 테스트 방법을 알게 되었으나, 프리코스 규칙상 Gradle을 조작할 수 없어 디버깅이 쉽지 않았습니다. 대신 프로그램에 print 기능을 활용해 어느 부분에서 문제가 발생하는지 확인하며 디버깅하는 방법을 배우게 되었습니다.

이번 과제에서는 readLine() 메서드에서 줄바꿈 문자가 자동으로 \\n으로 변환되는 문제를 발견해 수정했습니다.

리팩토링 작업을 하면서 설계 이상의 것을 배웠습니다. 처음 설계된 코드가 너무 복잡해서 코드 리뷰를 받기에 어려울 것 같다는 생각이 들었습니다. 그래서 시간을 들여 이해하기 쉬운 코드로 수정하고, 과도하게 분리된 클래스 구조를 단순화하면서도 확장성을 유지하려고 노력했습니다. 이 과정에서 리팩토링 방법을 새롭게 배웠습니다.

특히, 다른 사람들이 코드를 쉽게 리뷰할 수 있도록 이름을 짓고 구조를 개선하는 과정에서 앞으로의 개발 방향에 대한 인사이트를 얻었습니다. 아직 해결하고 싶은 궁금증은 "어떻게 이 과제를 더 좋은 방식으로 설계할 수 있을까"라는 점입니다. 이번 주차 과제가 끝나면 많은 사람들의 코드를 리뷰하고, 또 제 코드에 대한 리뷰를 받으면서 더 많은 경험을 쌓고 싶습니다.

</aside>

⚡ 트러블 슈팅 + 추가 개념 공부

readLine() 과 String 입력의 차이

Mock를 통한 Controller test