[프리코스 1주차 회고] 아 쓰var지 말라고

타입을 지정하지 않고 변수로 var를 사용한 이유가 궁금합니다☺️
폴더를 나눠서 정리하는 연습을 하면 좋을 것 같습니다
주석이 없으면 이해가 안되는 코드가 좋은 코드라고 말할 수 있을까요?!!
... ［ 코드 리뷰어들의 질문 中 ］

 

열띤 이야기

" 무엇이 더 나은 방식일까? "

코드 리뷰는 단순히 내가 아는 것에 머물지 않겠다는 다짐이고,
내 세계가 또 다른 세계들과 충돌하는 시간이다.

 

내 스스로 생각해봤던 의문에 대한 질문도 있었지만, 전혀 예상치 못했던 질문도 받았다.
사고를 확장시키는데 이번 리뷰가 정말 큰 도움이 되었다.

어떤 이야기들이 오고 갔는지, 흥미로운 것들 위주로 다뤄보도록 한다.

김민우님의 PR

나는 내 코드보다 민우님이 PR을 먼저 소개하고 싶다. 나는 막연하게 '좋고 유익한 대화가 오고 갔으면 좋겠다' 싶었는데, 이 PR에서는 자신의 관심사와 함께 논하고 싶은 주제를 먼저 소개한다. 이러한 소통 방식에는 '능동적으로 개방적이다'라는 표현이 적절할 것 같다. 남이 와서 건드려야 그제서야 속에 담아왔던 기억들을 찾아가며 이야기를 꺼내는 '수동적으로 개방적'인 나에 비해, 자신이 무엇이 궁금하고 관심이 있는지, 어떤 고민을 해봤는지 등을 먼저 정리해서 꺼내놓는 적극성이 대단하다고 느껴졌다.

 

민우님의 이번 주차 미션에서 고민한 지점들
1. Service Layer는 정말 필요한가? (애플리케이션 구조)
2. TDD와 예외 케이스의 딜레마
3. 기술 선택의 트레이드오프 (정규표현식 vs split/substring)
4. TDD가 강제하는 Commit Log 단위
5. 기능 목록 작성 관점 (구현 vs. 사용자)

[문자열 덧셈 계산기] 김민우 미션 제출합니다. by minuuu0 · Pull Request #742 · woowacourse-precourse/java-cal

 

내 코드의 문제점

이제 비루한 내 PR로 돌아와서,

내가 생각하는 내 코드의 문제점은 너무 내 자신에게 매몰되어 있었다는 것이다.
내가 틀렸다, 잘못됐다기보단 '무엇이 좋은가'에 대한 가치 판단이 너무 내 기준으로만 이루어졌다는 뜻이다.

 

물론, 2주차도 계획했던 것처럼 계속 반복해서 다양한 방식으로 타임어택에 도전할 것이다.

(지금 내게 가장 필요한 것은 설계와 추상화의 정도에 따른 TDD 완수 가능성을 감각적으로 가늠하는 것이다.)

하지만 그런 내 도전이, PR에 올라 '좋은 코드란 무엇인가'를 논하는 자리의 흥을 깨서는 안 된다는 것이다.

 

너무 모호한 것 같으면 하나씩 사례를 뒤져보자.

 

1. 논란의 중심: var

당연히 이 var는 아니다

지금부터 AI가 생성한 간단한 만담을 즐겨보자.

---

 

🎩 var 만능주의자 “타입이 줄면 로직이 드러나. 우리는 코드를 읽는 게 아니야. 로직을 이해하는거지.”
👓 var 불신주의자 “눈이 있으면 로직도 보인다. 구조 파악을 위해 둘 다 있어야 한다.”

 

🎬 장면 1: 짧음은 미덕이다

 

만능주의자:
이봐, 이거 좀 봐봐!

어때? 쓸데없는 타입 선언이 사라지니까 로직이 한눈에 들어오지?
“그룹별로 사용자 묶기” — 그게 코드의 의도잖아.

 

불신주의자:

의도는 알지. 하지만 타입은 사라졌잖아.
나중에 findAll()의 리턴 타입이 Set<User>로 바뀌면?
var는 그대로 지나치고, 버그는 조용히 들어올 거야.

 

** 리턴 타입이 Set<User>가 되면 users의 순서가 변동되면서, 결과 배열의 User 순서도 달라집니다.

 

🎬 장면 2: var의 어두운 면

 

만능주의자:

그런 건 IDE 툴팁으로 보면 되잖아. 2025년에 아직도 종이 보고 디버깅하냐?

코드는 읽는 사람이 로직을 따라가면 돼.

 

불신주의자:

아니, IDE에 목숨 걸면 안 돼.
로직을 따라가려면 구조를 알아야지.

이건 로직이 아니라 안개야.
타입이 없으면 흐름도 없다고.

 

만능주의자:

아, 이건 좀... 근데 그건 var 문제라기보단 작명 센스 부족이지.
그리고 로직이 눈에 띈다는 건 여전히 사실이야.
그러니 중요한 건 ‘언제 써야 하느냐’지.

 

🎬 장면 3: 타입 신앙 논쟁

불신주의자:

나는 이렇게 써.

타입이 명시돼 있으니 코드의 구조가 명확하지.

코드만 봐도 문서야. 이게 바로 클린 코드 아닐까?

 

만능주의자:

중요한 건 “유저를 그룹으로 묶는다”는 논리지, 데이터 구조가 아니야.
나라면 이렇게 쓰겠어.

일단 이 정도면 누구나 타입을 유추할 수 있잖아?
불필요한 정보가 숨겨지면서 개발자는 논리의 흐름에만 집중할 수 있지.
읽히는 순서가 사고의 순서와 일치하는 게 var의 진짜 가치야.

 

불신주의자:

그건 유추가 아니라 추리야. 개발자는 셜록 홈즈가 아니라고.

 

🎬 장면 4: 회의실의 결론

팀 리드:

두 분, 둘 다 그만 싸워요.

var는 불필요한 타입을 숨기는 도구입니다.
우리가 내릴 결론은 이겁니다:

• API, 공개 메서드, 테스트 코드에서는 명시적 타입 유지
• 불필요하게 중복 표기된 타입은 var 사용
• 이외에는 로직이 더 명확해진다고 생각할 때만 var 사용

만능주의자: 즉, " 로직이 더 잘 보일 때만 var "

불신주의자: " 타입이 안 보이면 망할 때는 var 금지."

 

** 초기에 너무 불신주의자만 유리하게 나왔길래, 로직의 중요성을 좀 더 강조하도록 개입했다.

*** 이외에도 부자연스러운 표현들을 수정했다.

---

 

var를 사용할 지, 하지 않을지는 여러분의 선택이다.

나는 사용해보면서 여러 시행착오를 겪어보며 나름의 기준을 정하려 했다.

아쉬운 점은  너무 무분별하게 사용한 나머지 '미아 핑'이 많이 찍혔다는 것... ⁉️ 🤔 ❓ ❔⁉️

 

2. 패키지 분리와 애플리케이션 계층 구조

리뷰 답변 일부분

 

무슨 말인가 하면, 지금 짠 코드들은 다른 어딘가에 이식할 수 있는 범용성 있는 코드가 아니라는 뜻이다.

범용성 있는 코드는 Java API를 생각하면 된다.

물론 규모가 커지면 나누는 게 자연스럽다. 단지 현재의 수준에서는 그렇지 않아도 된다고 판단했을 뿐.

" 아니, 의도가 어떻든 그렇게 한 패키지에 다 몰아넣어놓고 관리하면, 당신 빼고 누가 알아먹어 ?! "
" 남들 다 이렇게 저렇게 하는데, 너님은 왜 그렇게 안 함? "

 

라고 하면 할 말이 없다. 진짜 없다.

그래서 세워둔 기준: 팀플에서 팀의 결정사항이면 무조건 따른다.

근데 아직 아니잖아? 그러니까 이 정도의 요구사항에서는 과하다고 생각한 내 판단이 맞음. ㅅㄱ

 

** 말은 이렇게 했지만, 리팩토링한 소스는 별도의 도메인 패키지로 분리했고, 추가로 내가 왜 하나의 패키지로 두려고 했는지 보여주기 위해, 인터페이스와 package-private 클래스로 수정해두었다. 궁금하다면 아래 링크 참고.

 

refactor: rename and move to `core` package · ooMia/java-calculator-8@ee837e3

---

마치며...

KPT, CSS, TIL, AAR, 4L, 5F 등 목적에 맞는 글쓰기 방법을 선택하는 분들의 '전략 패턴' 같은 모습을 보며
' 아, 시간 관리는 저렇게 하는거구나. ' 싶었다.

오늘부터는 코드 뿐만 아니라 내 삶에서 시간을 할애하는 것에도 기준과 제한을 두어 효율적으로 생활해야겠다!