[인프런 워밍업 클럽 스터디 4기 - 백엔드]

강의 출처 :

Readable Code: 읽기 좋은 코드를 작성하는 사고법

Practical Testing: 실용적인 테스트 가이드

2주차 발자국

강의 수강

• 학습 내용 요약

   

   

  • [ Readable Code: 읽기 좋은 코드를 작성하는 사고법 ]

    • 코드 다듬기 : 주석의 양면성(좋은 주석이란), 변수와 메서드의 나열 순서(변수는 사용 순서대로, 공개 메서드 우선, 상태변경/판별/조회), 적당히 패키기 쪼개기, 기능 유지보수하기 (알고리즘 교체, DFS/BFS), IDE 기능

    • 리팩토링 실습 : 리팩토링 포인트 (추상화 레벨, 객체의 책임과 응집도, SOLID, 일급 컬렉션)

    • 추가 조언 : 능동적 읽기 (리팩토링 하며 읽기), 오버 엔지니어링, 적절한 수준의 클린 코드 사용법

     

  • [ Practical Testing: 실용적인 테스트 가이드 ]

    • 테스트는 왜 필요할까? : 테스트 코드가 없는 경우 단점, 올바른 테스트 코드 (테스트는 귀찮지만 해야 한다.)

    • 단위 테스트 : 수동 테스트 작성해보기, JUnit5 자동 테스트, 테스트 케이스 세분화하기, 테스트하기 어려운 영역을 분리하기 (매번 다른 값에 의존하는 코드, 외부에 영향을 주는 코드), 순수 함수

    • TDD : Red/Green/Refactor, 선 기능구현 후 테스트 (누락, 지연 가능성), 선 테스트 후 기능구현 (유지보수 쉬움, 빠른 피드백), 애자일 방법론

    • 테스트는 문서다 : DisplayName (문장으로 작성, 행위에 대한 결과, 도메인 용어), BDD (시나리오 기반, Given/When/Then)

       

• 2주차 회고

   

  • 이번 주는 클린 코드 강의를 완강하고, 테스트 강의로 넘어가는 한 주였습니다. 그동안 클린 코드 강의를 수강하며 코드의 가독성과 구조, 테스트의 중요성에 대해 더욱 깊게 고민할 수 있었고, 단순히 코드가 짧거나 깔끔하다고 좋은 것이 아니라 객체 간의 관계와 책임, 흐름을 명확히 정리하는 것이 훨씬 중요하다는 점을 배웠습니다. 워밍업 클럽을 통해 하나의 강의를 완강하니 무척 뿌듯했습니다. 이제부터 테스트 코드 강의를 시작하게 되었는데, 왜 제대로 된 테스트가 필요한지 납득할 수 있었고, "테스트는 귀찮지만 해야한다."는 말이 가장 크게 와닿았습니다.

  • 금요일에는 중간 점검 라이브도 진행되었는데, 다른 분들의 Q&A를 들으며 평소 궁금했던 부분들을 해결할 수 있어 좋았습니다. 다른 분들의 코드를 함께 리뷰하면서 각자의 코드 설계나 이름 짓기 방식이 매우 다양하고 참신한 아이디어들이 많아서 놀라웠고, 제가 미처 생각하지 못한 부분들을 발견하며 많이 배우고 느낄 수 있는 시간이었습니다. 저는 코드를 보여준다는 점이 부끄러워 신청하지 않았는데, 리뷰를 지켜보며 제 코드도 리뷰를 받아보고 싶다는 아쉬움이 들었고 다음 미션에는 용기를 내어 신청해보고 싶다는 생각을 하게 되었습니다.

  • 스스로 칭찬할 점은 리팩토링 미션을 열심히 고민하고 끝까지 해냈다는 것입니다. 또한 하나의 강의를 완강했다는 점이 매우 뿌듯하고 칭찬하고 싶습니다! 아쉬운 점은 리팩토링 과정에서 계속 고민하다 보니 강의 진도가 조금씩 밀려서 주말에 몰아서 수강하게 되었다는 점입니다. 다음 주 목표로는 진도표를 따라가며 미루지 않고 강의를 수강하고 싶습니다.

미션

• 미션 해결 과정

   

  • 미션 3 (Day7) :

     세 번째로 하나의 프로젝트를 리팩토링하는 미션을 진행하였습니다. 처음에는 무엇부터 시작해야 할지 막막했지만, 다음 강의 제목들과 적어주신 리팩토링 포인트를 참고하며 하나씩 진행했습니다. 먼저 클래스와 메서드들의 추상화 레벨을 정리했고, 책임이 모호하게 섞여있던 부분들을 명확하게 분리했습니다. 특히 출력 로직의 중복을 제거하며 PassDisplayer 클래스를 도입하여 도메인 객체의 UI 관련 책임을 완전히 분리하였습니다. 또한 InputHandler, OutputHandler, FileHandler도 단일 책임 원칙에 따라 분리하고 인터페이스 중심 설계를 통해 DIP를 적용했습니다. 또한 일급 컬렉션을 도입하여 객체의 응집도를 높이고, 패키지 구조를 도메인별로 명확하게 정리했습니다. 이 과정에서 도메인 내부의 getter를 제거하고 비교 책임을 객체 내부로 이동하는 등 다양한 클린 코드 원칙을 실천했습니다.

   

• 회고

  • 미션을 진행하며 리팩토링할 부분이 끊임없이 나타나는 경험을 했습니다. 처음엔 리팩토링이 단순한 코드 정리라고 생각했는데, 실제로는 객체 간 협력 관계와 책임을 제대로 설계하는 과정이라는 걸 알게 됐습니다. 특히 어디까지 분리해야 할지, 책임을 어떻게 나눠야 할지 고민하는 과정에서 객체지향 설계의 본질을 깨달았습니다. 시간이 부족하여 어느 정도 마무리 후 미션을 제출하였지만, 계속해서 리팩토링할 부분이 보이는 것이 아쉽기도 했습니다. 그러다 미션 제출 후 수강한 강의에서 "적정 수준을 알기 위해서 한계까지 극단적으로 사용해보자."는 말을 듣고, 정말로 극단적인 리팩토링을 한 번 시도하며 저만의 기준을 찾아가고 싶다는 생각이 들었습니다. 이번 미션을 통해 단순한 기능 구현을 넘어서 '좋은 구조란 무엇인가'를 고민하고, 객체 간 협력과 책임을 처음부터 설계할 수 있는 기반을 다질 수 있었습니다.