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

Reable Code

강의 요약

섹션 6. 코드 다듬기

주석의 양면성
- 주석이 많다는 것은, 그만큼 비즈니스 요구사항을 코드에 잘 못 녹였다는 이야기.
- 코드를 설명하는 주석을 쓰면, 코드가 아니라 주석에 의존한다. 주석에 의존하여 코드를 작성하면, 적절하지 않은 추상화 레벨을 갖게 되어 낮은 품질의 코드가 만들어진다.
- 우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석
변수와 메서드의 나열 순서
- 변수는 사용하는 순서대로 나열한다.
- 공개 메서드를 상단에 배치하는 것을 선호하는 편.
  - 공개 메서드끼리도 기준을 가지고 배치하는 것이 좋다.
  - 상태 변경 >> 판별 >= 조회 메서드
- 비공개 메서드는, 공개 메서드에서 언급된 순서대로 배치한다.
- 공통으로 사용하는 메서드라면, (가장 하단과 같은) 적당한 곳에 배치한다.
패키지 나누기
- 패키지는, 문맥으로써의 정보를 제공할 수 있다.
- 패키지를 쪼개지 않으면 관리가 어려워진다.
- 패키지를 너무 잘게 쪼개도 마찬가지로 관리가 어려워진다.
- 처음 만들 때부터 잘 고민해서 패키지를 나눠놓는 것이 제일 좋다.
IDE의 도움 받기
- 코드 포맷 정렬 (Ctrl + Alt + L)
- 코드 품질 (Sonarlint)
- 포맷 규칙 (.editorconfig)

섹션 7. 리팩토링 연습

스터디 카페 이용권 선택 시스템
- 리팩토링 포인트
  - 추상화 레벨
  - 객체로 묶어볼만한 것은 없는지
  - 객체지향 패러다임에 맞게 객체들이 상호 협력하고 있는지
  - SRP : 책임에 따라 응집도 있게 객체가 잘 나뉘어져 있는지
  - DIP : 의존관계 역전을 적용할만한 곳은 없는지
  - 일급 컬렉션
- 리팩토링 한 단계마다, 그 이유를 설명할 수 있어야 한다.

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

능동적 읽기
- 복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링하면서 읽기
  - 공백으로 단락 구분하기
  - 메서드와 객체로 추상화 해보기
  - 주석으로 이해한 내용 표기하며 읽기
- 핵심 목표는 우리의 도메인 지식을 늘리는 것. 그리고 이전 작성자의 의도를 파악하는 것.
오버 엔지니어링
- 필요한 적정 수준보다 더 높은 수준의 엔지니어링
은탄환은 없다
- 클린 코드도 은탄환이 아니다.
- 모든 기술과 방법론은 적정 기술의 범위 내에서 사용되어야 한다.

미션 (Day7)

지금까지 배운 내용을 기반으로 리팩토링 진행
결과: https://github.com/iPhone-design/readable-code/pull/1

과정

추상화 레벨 리팩토링
Early return 리팩토링
DIP 리팩토링

아쉬운점

새로운 도메인을 도출하는 과정에서 많은 어려움을 겪었습니다. 도메인 모델을 명확히 정의하고 적절한 개념을 추출하는 작업이 예상보다 복잡하고 까다로워 리팩토링에 많은 시간이 소요되었습니다. 또한, 리팩토링 과정에서 새로운 버그가 유입되거나 기존 기능이 손상되는 등의 부작용도 발생하여 기대만큼 만족스러운 결과를 얻지 못한 점이 아쉬웠습니다. 특히, 도메인을 명확히 정의하고 코드의 책임을 명확히 분리하는 클린 코드의 기본 원칙과 사고방식을 더욱 깊이 이해하고 습관화할 필요가 있다고 생각합니다. 앞으로는 작은 단위로 점진적으로 리팩토링을 진행하고, 자동화된 테스트를 적극적으로 활용하여 코드의 품질과 안정성을 높이도록 노력해야겠다 느꼈습니다.

Pratical Testing

강의 요약

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

우리가 얻고자 하는 것
- 빠른 피드백
- 자동화
- 안정감
테스트 코드를 작성하지 않는다면
- 변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 한다.
- 변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야 한다.
- 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.
테스트 코드가 병목이 된다면
- 프로덕션 코드의 안정성을 제공하기 힘들어진다.
- 테스트 코드 자체가 유지보수하기 어려운, 새로운 짐이 된다.
- 잘못된 검증이 이루어질 가능성이 생긴다.
올바른 테스트 코드는
- 자동화 테스트로 비교적 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
- 소프트웨어의 빠른 변화를 지원한다.
- 팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.
- 가까이 보면 느리지만, 멀리 보면 가장 빠르다.
테스트는 귀찮다. 귀찮지만 해야 한다.

섹션 3. 단위 테스트

단위 테스트
- 작은 코드 단위를 독립적으로 검증하는 테스트
- 검증 속도가 빠르고, 안정적이다.
JUnit 5
- 단위 테스트를 위한 테스트 프레임워크
AssertJ
- 테스트 코드 작성을 원활하게 돕는 테스트 라이브러리
- 풍부한 API, 메서드 체이닝 지원
테스트 케이스 세분화하기
- 암묵적이거나 아직 드러나지 않은 요구사항이 있는가?
- 테스트 케이스 세분화하기 (해피 케이스, 예외 케이스)
테스트하기 어려운 영역을 구분하고 분리하기
- 관측할 때마다 다른 값에 의존하는 코드
  - 현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등
- 외부 세계에 영향을 주는 코드
  - 표준 출력, 메시지 발송, 데이터베이스에 기록하기 등

섹션 4. TDD: Test Driven Development

Test Driven Development
- 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론
- 실패하는 테스트 작성 > 테스트 통과 최소한의 코딩 > 구현 코드 개선 테스트 통과 유
선 기능 구현, 후 테스트 작성
- 테스트 자체의 누락 가능성
- 특정 테스트 케이스만 검증할 가능성
- 잘못된 구현을 다소 늦게 발견할 가능성
선 테스트 작성, 후 기능 구현
- 복잡도가 낮은, 테스트 가능한 코드로 구현할 수 있게 한다.
- 쉽게 발견하기 어려운 엣지(Edge) 케이스를 놓치지 않게 해준다.
- 구현에 대한 빠른 피드백을 받을 수 있다.
- 과감한 리팩토링이 가능해진다.

섹션 5. 테스트는 문서다.

문서
- 프로덕션 기능을 설명하는 테스트 코드 문서
- 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완
- 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있다.
DisplayName을 섬세하게
- 명사의 나열보다 문장으로
- 테스트 행위에 대한 결과까지 기술하기
- 도메인 용어를 사용하여 한층 추상화된 내용을 담기
- 테스트의 현상을 중점으로 기술하지 말 것
BDD(Behavior Driven Development) 스타일로 작성하기
- TDD에서 파생된 개발 방법
- 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트한다.
- 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준(레벨)을 권장
- Given / when / then

발작국 2주차 회고

이론으로만 접하고 있었던 부분을 실제 리팩토링 실습을 통해 더욱 피부로 와닿게 느낄 수 있었습니다. 특히, 직접 코드를 개선하는 과정에서 이론과 실무 간의 차이를 명확히 이해할 수 있었고, 클린 코드와 리팩토링의 중요성을 더욱 깊이 깨닫게 되었습니다. 또한 이번 주는 다른 개발자분들의 코드를 함께 리뷰하고 피드백을 주고받는 시간을 통해 다양한 접근법과 사고방식을 경험할 수 있었던 의미 있는 시간이었습니다. 혼자서는 생각하지 못했던 다양한 관점과 해결책을 알게 되었고, 협업을 통한 코드 리뷰의 중요성도 다시금 느끼게 되었습니다. 더불어 두 번째 강의에서 다루었던 테스트 코드의 중요성 또한 다시 한번 상기하게 되었습니다. 리팩토링 과정에서 테스트 코드가 얼마나 중요한 역할을 하는지 실질적으로 체감할 수 있었으며, 앞으로 테스트 코드 작성 능력을 향상시키기 위해 더욱 노력해야겠다는 생각이 들었습니다.