[개발 도서] 리팩터링 2판 - 스터디 회고 (Java, JUnit5)

🗂️ Information 

 

📚 도서

https://www.hanbit.co.kr/store/books/look.php?p_code=B6952616555

리팩터링 2판 (리팩토링 개정판)

 

⚙️ 개발환경 및 도구

• IDE: IntelliJ
• 사용 언어 : Java
• JDK : 17
• 빌드 툴 : Gradle
• 테스트 프레임워크 : JUnit5
• 정적 코드 분석 : SonarCloud
• 테스트 커버리지: Jacoco
• 코드 스타일: google-java-format
• 형상관리: Git

 

👨🏻‍💻 학습 저장소 

공식 예제 코드는 없는 걸로 알고 있어요. 필요하시면 참고하세요. (Java, JUnit5 사용)

https://github.com/ljw1126/refactoring2

GitHub - ljw1126/refactoring2: 리팩터링 2판 스터디 (12주)

 

✍️ 학습 절차

1. ch* 브랜치 생성 후 학습한다
2. 학습 완료 후 브랜치를 remote에 push한다
3. P.R(Pull Request)를 생성한다 (✅ Github Action 통해 jacoco 및 sonar 실행)
4. SonarCloud 분석 결과를 확인한다. (💩 Quality Gate 통과하지 못한 경우 수정해서 반영)
5. master 브랜치에 merge 한다.
6. 최종적으로 로컬 브랜치를 최신화한다. (1번부터 반복)

 

 

---

🤔: 잘 할 수 있을까?

2025년 1월, 커뮤니티에 리팩터링 2판 스터디 참가자 모집 글이 올라왔다.

 

과거에 이미 📚리팩터링 도서를 읽는데 두 번 실패했었다. 독학으로 해보기도 하고 강의를 구매해서 따라 해보기도 했지만, 머리 속에 들어오지 않고 단순히 타이핑만 반복하다보니 끝까지 해내지 못했었다. 그러다보니 스터디를 시작하기 앞서 망설이게 되었다.

 

"이번에도 중간에 포기하는거 아닐까?"

"나는 준비가 된 걸까?"

 

오만가지 걱정이 앞서면서 산책을 하러 나갔다. 그리고 작년 넥스트스텝-TDD, 클린코드 with Java 교육을 신청하기 전에도 비슷한 고민을 했던게 생각났다. 당시 교육을 듣지 않는다면 후회할 거라는 생각이 들면서, 큰 맘 먹고 💸80만원을 투자했다. 그렇게 돈이 아까워 주도적으로 과제 수행한 결과, 수강생 75명 中 첫 번째로 수료할 수 있었고 단위 테스트, 도메인 설계, TDD를 배우면서 한 단계 더 성장하는 계기가 되었다.

 

걱정하는 일은 대부분 일어나지 않는다는 말처럼 이번에도 결과보다는 과정을 통해 배울 점이 있을거라고 긍정적으로 생각하기로 했다.

그리고 비슷한 관심사를 가진 실무자와 스터디를 해보는 것도 좋은 경험이 될 거라 생각하며, 그렇게 스터디 참여를 신청했다.

 

"자바 한명 추가요 🙌"

출처. 조코딩 유튜브 채널 - 좋코딩 中

 

 

---

👨🏻‍💻 첫 스터디

첫날 오리엔테이션에 많은 사람들이 참여했다. 대략 70~80명 정도 신청을 했었고, 3회차에 절반, 7장부터는 정예 멤버(10~13명)만 남았다. 줄어드는 인원 수에 흔들리기도 했지만 목마른 사람이 우물을 판다는 말처럼 스터디는 계기라 생각하고, 온전히 나 자신에게 집중하기로 했다. 

 

스터디는 한 주별로 챕터를 공부한 후 음성 회의를 통해 후기 & 느낀점을 공유하는 형태로 매주 진행되었다.(🌃밤 9시 ~ 10시 ) 

참여 인원 수가 줄었기 때문에 묻혀 갈 수 없었고, 한명씩 돌아가면서 말을 해야 했다.

그러다보니 한 주간 챕터 학습은 필수가 되었고, 약속🤙이 되었다.

 

 

내 차례가 왔을 때 설정이 잘못되어 목소리가 작게 들린다거나, 화면 공유가 되지 않은 등 실수가 발생했다.

의욕만 앞서다 보니 말을 더듬기도 했고, 스터디 끝난 후 조리있게 말하지 못한게 생각이나 잠을 설치기도 했다. (😂)

 

결국 준비 부족이었다

 

원인을 알면서도 같은 실수를 하는 건 삼류라 생각하기에 조금씩 준비를 하기로 했다.

1. 챕터 학습 후 마지막에 간단히 후기 작성👨🏻‍💻
2. 후기를 바탕으로 스터디에서 말할 내용 정리🧹
3. 스터디 시작 15분전 장비 및 설정 확인⚙️

 

 

공통 관심사를 가진 분들과 스터디를 하니 크게 신경쓰지 않는 것으로 느껴졌고, 덕분에 마음에 안정을 느끼면서 조금씩 나아져갔다.

리팩터링 스터디 9주차

---

🛠️ 테스트와 정적 코드 분석 도구

7장 캡슐화부터 본격적인 리팩터링 시작이었는데, 단위 테스트를 작성하지 못 했다면 중도 리타이어 했을거란 생각이 들었다.

 

리팩터링과 테스트는 항상 붙어 다녔다. 일정한 in-out이 있을 때 테스트를 먼저 만들고, 리팩터링을 수행한다. "수정 - 테스트"를 반복하면서 쉽게 결과를 확인할 수 있었고, 문제가 발생하더라도 바로 전에 변경한게 원인이기 때문에 쉽게 찾아 해결할 수 있었다. 결국 테스트라는 안전 영역이 준비 되었기 때문에 과감하게 리팩터링을 시도해 볼 수 있었다고 생각한다. 또한, 코드가 발전함에 따라 테스트도 함께 리팩터링 된다는 것도 경험할 수 있어 좋았다.

 

하지만 도서의 예시가 추상적이고 생략된게 많아 이해가 안되는 부분도 있었다. 특히, 책에서는 JavaScript로 작성되어 있어, Java로 작성하려니 문법적으로 이해되지 않거나 치환하기 쉽지 않은 부분도 있었다. 이 경우 🤖Chat-GPT와 같은 AI에게 질문하여 도움을 받았다.

 

중간부터 코드 품질을 일정하게 유지하기 위해 코드 스타일과 정적 코드 분석 도구를 추가했다. 그리고 하는 김에 테스트 커버리지는 70% 정도 유지하도록 Quality Gate를 설정하고, Github Action 활용해 정적 코드 분석 실행까지 자동화했다. 설정하는게 익숙하지 않아 삽질🪏하기도 했지만 자동화를 해두니 세상 편해졌다 🙌. 

 

📑 README.md

README.md에 SonarCloud 뱃지를 추가하니 나름 이뻐 보인다

 

---

🧢 기능 추가 모자와 ⛑️ 리팩터링 모자

가장 기억에 남는 건 Chapter2. 리팩터링 원칙이었다. 🧢기능 추가 모자와 ⛑️리팩터링 모자라는 비유가 여기서 나왔는데, 참여자 대부분이 스터디 시작하자마자 이 얘기를 했던 기억이 난다. 

 

켄트 벡(Kent Beck)은 소프트웨어를 개발할 때 목적을 두 개의 모자에 비유했다.

1. 🧢 기능 추가 모자: 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다 
2. ⛑️ 리팩터링 모자: 기능 추가는 절대 하지 않기로 다짐, 오로지 코드 재구성에만 전념한다

 

 

작업을 할 때 모자를 바꿔써가며 한가지 목적에 집중해야 한다는 의미인데.. 보통 실무에서는 두 모자를 동시에 쓰기도 했던거 같다😅.

이로인해 작업이 꼬이기도 하고 커밋 이력이 복잡해지기도 했었는데, 이를 계기로 반성하고 이후 의식하며 연습을 하게 되었다.

 

 

그리고 Chapter2에서 "리팩터링 한다고 말하지 말라"는 문장도 인상 깊었다. 우리는 프로 개발자이고 우리에게 주어진 임무는 요구사항에 맞춰 새로운 기능을 빠르게 구현하는 것이다. 그러기 위해서는 리팩터링과 테스트를 자연스럽게 활용하면서 코드 품질을 유지해야 한다. 저자는 리팩터링을 하나의 추가 작업(❌)처럼 인식하기 보다, 개발 과정에서 당연히 함께 수행해야 할 습관(✅)으로 만들 것을 강조하는 듯 했다.

 

또한, 관계자나 고객은 코드 품질에 관심이 없을 수 있기 때문에 리팩터링 일정이 필요하다고 말을 하는 게 오히려 대충 일한다는 인상을 줄 수도 있다는 의견이 스터디에서 나왔었다. 충격이었지만 충분히 공감할 수 있었고 이제는 역량을 갖췄기 때문에 리팩터링까지 포함해서 일정 잡아 수행하면 될 거라고 생각했다.

 

 

이외에도 스터디에서 좋은 내용이 많이 나와서 일부 공유합니다🙌

• 리팩터링을 클린코드나 바람직한 엔지니어 습관이란 이유로 정당화하지 않기 ❌
  • 우월감이나 자기 과시욕은 지양한다
  • 일정이 급해 빨리 쳐내다보면 기술 부채💸가 발생 ➡️ 부채는 갚아야 한다 ➡️ 부채를 갚는 빠른 방법은 리팩터링✨이다
  • 서비스 이슈 또는 기술 부채와 연관지어 리팩터링의 필요성을 말하는 건 괜찮다
• 리팩터링과 성능 관련하여
  • 인터넷에 성능 관련된 얘기, 블로그 글 대부분은 헛소리이다 💩
  • 객관적 지표 비교도 없는 뇌피셜을 믿으면 안된다 ❌
  • 과거와 달리 메서드를 분리한다고해서 성능 이슈가 발생하진 않는다
  • 요즘 시대는 개발자 생산성이 소프트웨어의 성능보다 더 중요하다
  • 개발자의 생산성을 향상 시키는 방법은 역시 리팩터링✨이다
• 리팩터링을 하지 말아야 할 때
  • 시간만 잡아먹고 팀에 도움이 되지 않는 리팩터링은 하지 않는다 (주객전도)
  • 테스트가 없는 리팩터링은 오래 걸리고, 실수 유발할 수 있기 때문에 하지 않는게 나을 수도 있다
  • YAGNI 원칙 (You Ain't Gonna Need It, 너 그거 지금 필요 없어) ➡️ 오버 엔지니어링 하지 않기

 

---

👨🏻‍💻 스터디를 마치며

리팩터링을 학습하면서 단위 테스트를 작성하는 훈련을 마음껏 해볼 수 있어 좋았다. 이 과정에서 객체의 책임과 역할, 의존성에 대한 사고와 시야를 얻게 된 게 가장 큰 성과라고 생각한다. 이외에도 후반 챕터를 학습하면서 캡슐화의 정의나 "상속보다 위임을 사용해라"는 말을 이해할 수 있게 되어 인상 깊었다. (이에 대한 내용은 생략합니다. 직접 테스트와 함께 해보시는게 분명 도움이 될 거라 생각합니다 👍)

 

리팩터링 2판 도서를 3번째 만에 완독할 수 있었다. 아마 혼자였다면 하지 못했을 거라는 생각도 들었다. 마지막 스터디가 끝날 때 채팅창에 신입때 도서를 구매하고, 드디어 완독할 수 있었다는 분도 계셨는데 비슷한 느낌이지 않을까 싶었다 🤔🥹

 

관심사가 비슷한 분들과 함께 스터디 진행하면서 같은 글을 읽고 다양한 생각과 경험을 공유할 수 있었다. 그리고 이를 통해 시야와 네트워크를 확장할 수 있었다고 생각한다. 또한, 스터디를 주최하신 IT 업계 전설 토비(Toby)님이 계기를 마련해주시고 받쳐주셨기 때문에 12주라는 기간을 무사히 마무리 할 수 있었다고도 생각합니다. (🙇🏻‍♂️감사했습니다🙇🏻‍♂️)

 

TMI지만 직장 내 괴롭힘을 4년간 경험한 이후로 2년간 자기 계발하면서 은둔 생활을 하고 있었다. 불행한 일은 한꺼번에 온다고 사람이 두렵기도 했는데, 이 경험을 통해 앞으로 더 성장해 갈 수 있을거라는 생각이 든다. (빨리 이직해서 다음 스터디 하고 싶다 🙌 )

깃허브 - 잔디 심기