[워밍업 클럽 3기 BE 클린코드&테스트] - 2주차 발자국

sdqkmlqdwkmqwdl 2개월 전

회고

2주차에도 많은 것을 학습하였습니다. 특히, 7일차 미션에서 직접 리팩토링을 진행해본점이 인상깊었습니다.

강의를 들으면서 이해했다고는 생각했지만, 막상 실제로 적용해보려니 어려웠고, 배웠던 개념을 떠오르기가 쉽지않았습니다. 그 후 강의를 들으면서 부족한점을 채워가면서 복습도 되고 좋았습니다! 또한 같은 수강생분들의 코드를 보면서 배울점도 많았습니다. 남은 주차와 테스트 강의도 열심히 듣고 참여하겠습니다!

강의 내용 요약

섹션 6. 코드 다듬기

1⃣ 주석의 양면성

  • 주석이 많다는 것은 비즈니스 요구사항을 코드에 제대로 녹이지 못했다는 신호

  • 만약 의사 결정의 히스토리를 코드로 파악할 수 없다면, 상세한 설명이 필요하다.

  • 하지만, 불필요한 주석은 오히려 가독성을 해치므로 최소화하는 것이 중요하다.

2⃣ 변수와 메서드의 배치 순서

  • 변수는 사용되는 순서대로 나열하여 인지적 경제성을 높인다.

  • 공개 메서드(Public)는 기준을 가지고 배치하고, 비공개 메서드(Private)는 공개 메서드의 호출 순서에 맞춰 정리하는 것이 좋다.

3⃣ 패키지 구조 설계

  • 패키지는 문맥을 제공하는 역할을 한다.

  • 패키지를 너무 크게 두면 관리가 어렵고, 반대로 너무 세분화해도 유지보수가 어렵다.

  • 처음부터 신중하게 패키지 구조를 고민하고 설계해야 한다.

4⃣ IDE의 도움받기

  • 코드 스타일을 유지하면 가독성이 향상된다.

  • 자동 포맷팅, 린트 도구, 코드 스타일 설정 등을 적극 활용하자.

섹션 8. 기억하면 좋은 조언들

1⃣ 능동적 코드 읽기

  • 복잡한 코드나 난잡한 코드를 읽을 때, 그냥 이해하려 하지 말고 리팩토링하며 읽자.

  • 핵심 목표는 코드를 이해하는 것이 아니라, 도메인 지식을 늘리는 것이다.

2⃣ 오버 엔지니어링 피하기

  • 필요 이상의 복잡한 설계를 하는 것은 불필요하다.

  • 적정 수준의 설계를 유지하고, 꼭 필요한 곳에만 적용하자.

3⃣ 은탄환은 없다

  • 현실적인 소프트웨어 개발은 빠른 결과물과 기술 부채 간의 균형을 맞추는 과정이다.

  • 모든 기술과 방법론은 적정 수준에서만 활용해야 한다.

Practical Testing (실전 테스트)

섹션 2. 테스트는 왜 필요할까?

  • 사람이 직접 테스트하면 예측하지 못한 사이드 이펙트(부작용)가 발생할 가능성이 높다.

  • 테스트 코드를 작성하면 빠른 피드백, 자동화, 안정감을 확보할 수 있다.

  • 테스트는 귀찮더라도 소프트웨어의 품질을 보장하기 위해 필수적이다.

섹션 3. 단위 테스트 (Unit Test)

✅ JUnit5로 단위 테스트하기

  • 단위 테스트: 작은 코드 단위를 독립적으로 검증하는 테스트

  • JUnit5: 자바의 대표적인 단위 테스트 프레임워크

  • AssertJ: 테스트 코드 작성을 더 간결하고 명확하게 도와주는 라이브러리

✅ 테스트 케이스 세분화하기

  • 암묵적인 요구사항이 있는지 고민하자.

  • 해피 케이스(정상적인 입력) & 예외 케이스(잘못된 입력)에 대한 테스트를 함께 고려해야 한다.

✅ 테스트하기 어려운 영역을 분리하기

  • 테스트하기 어려운 부분을 외부로 분리하면 테스트 가능성이 높아진다.

  • 예를 들어, DB 접근 로직을 인터페이스로 분리하면 더 쉽게 테스트할 수 있다.

섹션 4. TDD (Test-Driven Development)

  • TDD는 프로덕션 코드보다 테스트 코드를 먼저 작성하는 개발 방법론이다.

  • TDD 3단계:

    1. 실패하는 테스트 작성 (프로덕션 코드 없이 테스트부터 작성)

    2. 테스트를 통과하는 최소한의 코드 작성 (엉터리라도 우선 통과)

    3. 리팩토링하여 코드 개선

섹션 5. 테스트는 문서다

✅ 테스트는 곧 문서다

  • 테스트 코드는 프로덕션 코드의 동작을 설명하는 문서 역할을 한다.

  • @DisplayName을 활용하여 테스트 의도를 명확하게 기술하자.

✅ 테스트 네이밍 가이드라인

  • 명사의 나열보다는 문장으로 작성하기

  • 테스트 행위에 대한 결과까지 기술하여 명확한 의도를 전달하기

  • 도메인 용어를 사용하여 한층 추상화된 내용을 담기

✅ BDD 스타일로 작성하기

  • BDD (Behavior-Driven Development, 행위 주도 개발) 방식은 테스트를 더 직관적으로 만든다.

  • Given / When / Then 패턴을 활용하여 테스트를 구조화하면 가독성이 향상된다.

@DisplayName("주문 목록에 담긴 상품들의 총 금액을 계산 할 수 있다.")
    @Test
    void calculateTotalPrice() {
        //given
        CafeKiosk cafeKiosk = new CafeKiosk();
        Americano americano = new Americano();
        Latte latte = new Latte();

        cafeKiosk.add(americano);
        cafeKiosk.add(latte);

        //when
        int totalPrice = cafeKiosk.calculateTotalPrice();

        //then
        assertThat(totalPrice).isEqualTo(8500);
    }

✅ 테스트가 읽기 쉬워지고, 테스트가 곧 문서 역할을 하게 됨

 

미션

Day 7 -리팩토링 연습

https://github.com/5jeong/readable-code/tree/main/src/main/java/cleancode/mission/day7

리팩토링을 진행하고, 강의내용과 남들의 코드를 보니 부족함을 많이 느꼈다. 그만큼 얻는것도 많았다!

댓글을 작성해보세요.


채널톡 아이콘