[프리코스 1주차 회고] 너의 해석은?

도전

이번 주 나의 도전은 두 가지로 요약할 수 있다.

1. 문제 해결 중 AI🤖 도움 받지 않기 🔨
2. 🩰 우아한 코드 & 구현 속도⚡그 사이에서 적절한 균형 잡기

그걸 위해 나만의 체크 리스트를 만들고, 매일 코드를 초기화하며 재시도를 반복했다. 다 합치면 총 6번이다.

2주차까지는 이 방법을 그대로 가져갈 것 같다. 지금 내게 필요한 건 많은 시도와 반복 경험이다.

적어도 내가 하고 있는 이 짓이 지겨워질 때까지 같은 방식으로 작업을 반복해야 한다고 믿는다.

GitHub - ooMia/java-calculator-8: java-calculator-8

 

경험칙(오타 아닙니다)을 쌓아나가는 과정이고, 지금 나는 괜찮게 잘하고 있다.

때가 되면 좀 더 깊은 내용으로 회고를 진행할 수 있을 것 같다.

Gist를 노트 삼아 관리하고 있으니 필요하면 참고하시길!

---

1주차 미션: 간단한(?) 요구사항

구분자와 양수로 구성된 문자열에서 숫자를 추출하여 더하는 계산기를 구현한다.

 

와.. 이렇게 간단할수가?

문자열에서 특정한 방식으로 숫자를 모두 추출한 뒤로는, 그냥 반복해서 더하는 것이 전부다.

즉, 주어진 규칙에 따라 숫자를 모두 추출하면 90% 완성하는 것이다.

심지어 규칙도 간단하다.

1. 쉼표 또는 콜론을 구분자로 가지는 문자열을 전달하는 경우 구분자를 기준으로 분리한 각 숫자의 합을 반환한다.
2. 앞의 기본 구분자(쉼표, 콜론) 외에 커스텀 구분자를 지정할 수 있다. 커스텀 구분자는 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 사용한다.

기본 구분자든, 커스텀 구분자든, 아무튼 구분된 숫자들 파싱하면 되는거잖아! 😀
( 뚝딱뚝딱 🚧 구현 중 )

그렇게 첫 번째 구현을 3시간 만에 마친 후, 잘 완성했나 요구사항을 검토해보는데,

웬걸, 눈에 밟히는 게 한 두 개가 아니었다 ⁉️

1. 문자를 커스텀 구분자로 사용한다.

나는 이 '문자'라는 표현을 문자열과 구분되는 단어로 보았다.
'열'이 있냐 없냐 그런 얘기를 하는 건 아니고 🥵

보통 char는 문자, String은 문자열로 표현하니까.

 

자연스레 Character 클래스에 눈이 갔는데, 신기하게 이 친구의 생성자는 deprecated 되어 있었다.
ASCII는 이제 '문자'를 대표하기엔 너무 구식이 되어버렸다는 의미일 것이다.

Character의 생성자는 사용하지 않는다.

 

그래서 자연스럽게 유니코드로 문자의 개념을 확장시켜 생각했다.
Character.toString( int codePoint )를 사용하면 정수의 값에 대응되는 유니코드 문자를 얻을 수 있다.

이는 Java 8 문서에는 없지만, 21에는 존재한다. LLM으로 검색해보니 Java 11부터 바뀌었다고 한다.

** 이제 프로젝트를 진행 전에 JDK 버전의 API 지원 여부부터 확인해야겠지?

2. 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자

대체 앞부분이 어디죠? 아니, 실제로 앞뒤를 구분 못하는 건 아닌데요... 😫

일단 "\n"이 라인 피드로 활용되는 1 byte ASCII 문자가 아니라,
두 문자가 조합된 문자열이라는 것은 테스트 케이스를 참조하여 알 수 있었다.
그래서 문자열 리터럴의 규칙에 따르면 정확히는 "\\n"이 된다.

 

커스텀 구분자가 세미콜론이라 해보자.

그럼 "//;\\n"이 커스텀 구분자의 정의부가 될 것이다.

그리고 정답이 있는 건 아니겠지만,
나는 커스텀 구분자가 사용되기 전에 정의부가 먼저 나와야 한다고 생각했다.

 

대충 이런 느낌으로 조건을 하나씩 따져가며 테스트를 작성했던 것 같다.

충격의 OOP ⚡

이렇듯 단순해보였던 문제 속에도 모호함이 숨어있었고,
좋은 코드를 만들기 위한 노력의 일환으로 그 모호함을 추상화하고자 했다.

당시에는 OOP 없이는 좋은 코드가 될 수 없다고 생각했던 것 같다.

 

번뜩 떠오른 아이디어 중 하나는 Token 인터페이스를 만들고,
모든 토큰이 Token reduce( Token operand )를 구현하여 유기적으로 동작하도록 만드는 것이었다.

 

하지만 객체에게 독립성을 부여하면 관리의 책임도 크게 돌아온다.

모두 설명하기엔 좀 길고, 총 세 번 시도해봤는데 다소 작위적으로 구현되는 느낌이 있어서 그만 뒀다.

그리고 OOP 또한 유지보수를 위한 도구로 인식해야겠다는 경험을 하나 얻었다.

---

마치며...

이 밖에도 다양한 부분들을 고민했다. 객체지향적 설계/구현을 위한 고민과 시도, String을 순회하는 다양한 방법, 요구사항에서 어떤 정보가 필요한지, 또 그 정보를 어떻게 빠르고 효율적으로 정리할 지, 모호한 요구사항에 대처하는 마인드셋과 추상적인 설계에 대한 개념 증명 방식 등... 앞서 말했듯 스스로 경험을 통해 나만의 정답을 쌓아나가는 중이다.

 

1주차가 종료되었으니, 이제 다른 참가자들과 교류하면서 내 정답을 의심해볼 차례다.

다양한 분들의 코드에서 각자만의 이야기가 담겨있을 것 같아 벌써 설렌다!