강의 수강

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

학습 내용 요약

섹션6. 코드 다듬기

• 좋은 주석

  • 주석의 양면성

    • 주석은 코드로 표현할 수 있는 내용을 대체하는 것으로, 지양해야 함

    • 의사 결정의 히스토리를 코드로 표현할 수 없을 때 주석으로 설명해야 함으로 필수임

  • 좋은 주석: 코드를 통해 최대한 표현했음에도 전달하지 못한 정보가 남았을 때 사용하는 주석

• 나열 순서

  • 변수: 사용하는 순서대로 나열 (인지적 경제성 고려)

  • 객체의 공개/비공개 메서드

    • 공개 메서드는 기준(중요도, 종류 등)을 가지고 배치

    • 비공개 메서드는 공개 메서드에 언급된 순서대로 나열

    • 나열 순서로도 의도와 정보 전달 가능

       

• 패키지 나누기

  • 패키지는 문맥으로써의 정보를 제공

  • 패키지 분리 시 유의할 점

    • 적절히 쪼개야 함 (너무 안 쪼개면 관리 어렵고, 너무 쪼개도 유지보수 어려움)

    • 공통으로 사용하는 클래스들의 패키지 분리/변경은 충돌을 야기함

    • 패키지 구조는 가능한 한 초기 프로젝트 설정 때 잘 고민해서 나누기

• 기능 유지보수하기

  • 버그 잡기

  • 알고리즘 교체

• IDE 도움 받기

   

  • 정렬 단축키: Ctrl + Alt + L

  • linting, style - sonarlint, editorconfig

섹션7. 리팩토링 연습

• 메서드 추출로 추상화 레벨 맞추기

• Optional

• 객체에 메시지 보내기

• 객체의 책임과 응집도

  • IO 통합

  • 일급컬렉션

  • display()

  • Order 추출

• 추상화 관점의 차이

  • 구현에 초점을 맞춘 추상화 vs. 도메인 개념에 초점을 맞춘 추상화

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

•  능동적 읽기

  • 복잡하고 엉망인 코드를 읽고 이해해야 할 때 리팩토링하면서 읽기

    • 공백으로 단락 구분

    • 메서드와 객체로 추상화

    • 이해한 내용 주석으로 표기

• 오버 엔지니어링

  • 필요한 적정 수준보다 더 높은 수준의 엔지니어링 (불필요)

  • 적절하게 적용해서 리팩토링할 것

• 은탄환은 없다

  • 항상 정답인 기술은 없다

  • 한계까지 연습해보고, 적정 수준, 적정 시점을 깨닫기

섹션3. 단위 테스트

• 단위 테스트

  • 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트

  • 검증 속도가 빠르고 안정적임

• 수동 테스트, 자동화 테스트

  • 수동 테스트: 사람이 검증 (콘솔에 출력)

  • 자동화 테스트: 기계가 검증

• Junit5, AssertJ

  • Junit5: 단위 테스트를 위한 테스트 프레임워크

  • AssertJ: 테스트 코드 작성을 돕는 테스트 라이브러리

• 해피 테스트, 예외 케이스

• 경계값 테스트:

  범위, 구간의 경계값으로 테스트

   

• 테스트하기 쉬운/어려운 영역 (순수함수)

  • 테스트하기 어려운 영역

    • 관측할 때마다 다른 값에 의존하는 코드

    • 외부 세계에 영향을 주는 코드 (외부에 의존하는 코드)

  • 순수 함수

    • 테스트하기 쉬운 코드

    • 같은 입력에 항상 같은 결과 출력

       

• lombok

  • @Data, @Setter, @AllArgsConstructor 지양

  • 양방향 연관관계 시 @ToString 순환 참조 문제

섹션4. TDD: Test Driven Development

• TDD (테스트 주도 개발)

  • 프로덕션 코드보다 테스트 코드를 먼저 작성 -> 테스트가 구현 과정을 주도하도록 하는 방법론

     

• 레드-그린-리팩토링

  • 레드: 실패하는 테스트 작성

  • 그린: 테스트를 통과하는 최소한의 코딩

  • 리팩토링: 구현 코드 개선 및 테스트 통과 유지

• 애자일(Agile) 방법론 vs. 폭포수 방법론

• 익트트림 프로그래밍 (XP, eXtreme Programming)

   

  • 빠른 개발 주기와 지속적인 피드백을 중심으로 하는 소프트웨어 개발 방법론

     

• 스크럼(Scrum), 칸반(kanban)

  • 스크럼: 짧은 개발 스프린트를 반복적으로 진행해 빠르게 결과물을 만들고 지속적으로 개선

  • 칸반: 지속적인 개선과 작업량 관리를 위해 작업을 시각적으로 표현

섹션5. 테스트는 []다.

-> 테스트 코드는 문서다

• 프로덕션 기능을 설명하는 테스트 코드 문서

• 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완

• 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜 모두의 자산으로 공유

• @DisplayName - 도메인 정책, 용어를 사용한 명확한 문장

  • 메서드명만으로는 테스트의 의도 파악 어려움

  • DisplayName을 섬세하게 (모두가 명확히 알아볼 수 있도록)

    • 명사의 나열보다는 문장으로 기술

    • 테스트 결과까지 기술

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

• Given / When / Then - 주어진 환경, 행동, 상태 변화

  • Given: 시나리오 진행에 필요한 모든 준비 과정

  • When: 시나리오 행동 진행

  • Then: 시나리오 진행에 대한 결과 명시, 검증

• BDD

  • TDD에서 파생된 개발 방법

  • 시나리오에 기반한 테스트 케이스 자체에 집중하여 테스트

• JUnit vs. Spock

  • Spcok: Groovy 언어로 BDD 패턴을 적용해서 테스트 코드를 작성

회고

바쁜 한주를 정신없이 보내고 나니 벌써 중간점검을 할 시기라 좀 놀랐다. 이번주는 할일이 많아 강의 진도를 따라가기 급급한 나머지 Day 7 미션은 기한 내에 끝내지 못했다. 강의를 들으며 강사님을 따라할 때는 어렵지 않았는데, 막상 배운 내용을 적용해보려 하니 생각보다 막막하고 오랫동안 고민해야 했다. 아쉽게도 강의를 끝내지 못한 상태로 중간 점검 라이브에 참여했지만, 다른 사람들이 리팩토링한 코드와 그에 대한 강사님의 피드백을 보며 코드를 리팩토링하는 다양한 접근법을 확인할 수 있어서 좋았다. 동시에 내가 얼마나 부족한지 깨닫는 시간이기도 했다... 이번 스터디가 끝나더라도 배운 내용을 다시 한번 정리하고, 코드를 리팩토링하는 것도 꾸준히 연습해야겠다.

• 칭찬하고 싶은점: 바쁜 한주였지만 들어야 하는 강의는 다 들었고, 지난주에 하지 못한 정리도 끝냈다.

• 아쉬웠던 점: 너무 바빠서 이번주 미션은 끝내지 못했다.

• 보완할 점: 다음 주말에 Day 7 미션을 끝내고, 다른 사람들이 리팩토링한 것과 비교하며 공부하기

• 다음 주 목표: 강의와 미션 진도표에 맞춰서 끝내기