Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back

[Day 15 of 21] 클린코드 TIL

#clean_code
1년 전
262

오늘 TIL 3줄 요약

  • 경계에 위치하는 코드는 최대한 깔끔히 분리해야 한다.

  • 테스트 코드가 망가지면 실제 코드도 망가진다.

  • 깨끗한 테스트를 작성하는 방법 F.I.R.S.T

TIL (Today I Learned) 날짜

  • 2024.02.09

오늘 읽은 범위

  • 8장. 경계

  • 9장. 단위 테스트

책에서 기억하고 싶은 내용을 써보세요.

  • 8장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교 살펴본다.

<외부 코드 사용하기>

  • 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출 되지 않도록 주의한다.(Map 인스턴스를 공개 API인수로 넘기거나 반환 값으로 사용하지 않도록)

<경계 살피고 익히기>

  • 외부 패키지는 개발에 시간을 많이 줄여주지만, 사용할 때 외부 패키지라 하더라도 사용하는 부분에 대해서 직접 테스트를 해보는 것이 중요하다.

  • 간단한 테스트 코드를 작성해 외부코드를 익히는 방식을 학습 테스트라고 부른다: 프로그램에서 사용하려는 방식대로 외부 API를 호출하고 API를 사용하려는 목적에 초점을 둔다.

<log4j 익히기>

<학습 테스트는 공짜 이상이다>

  • 학습 테스트를 이용한 학습이 필요하든 그렇지 않든, 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다. 

  • 경계 테스트가 있다면 패키지의 새 버전으로 이전하기가 쉬워짐.

<아직 존재하지 않는 코드를 사용하기>

<깨끗한 경계>

  • 경계에 위치하는 코드는 깔끔히 분리한다.

  • 9장

<TDD 법칙 세 가지>

  1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

  2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

  3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

-> 이론상으로 이렇게 할 때, 실제 코드를 전부 테스트하는 테스트 케이스가 나온다. 하지만! 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 겪기도 한다.

<깨끗한 테스트 코드 유지하기>

  • 테스트 코드는 실제 코드 못지 않게 중요하며, 이를 짤때는 사고, 설계 그리고 주의가 필요하다.

    • 테스트는 유연성, 유지보수성, 재사용성을 제공: 버팀목은 단위테스트. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 테스트 커버리지가 높을수록 코드 변경이 쉬워진다.

<깨끗한 테스트 코드>

  • 가장 필요한 건 ‘가독성’, 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 중요하다. 테스트 코드는 최소한의 표현으로 많은 것을 나타내야 하기 때문이다.

    • 도메인에 특화된 테스트 언어: 이 테스트 언어는 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 언어로서 역할을 한다.

    • 이중 표준: 테스트 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 다르다. (실제 코드만큼 효율적일 필요는 없다.) 

<테스트 당 assert 하나>

  • assert문이 단 하나인 함수는 결론이 하나이기 때문에 코드를 쉽고 빠르게 이해할 수 있다. -> 이것 때문에 테스트를 분리하면, 중복되는 코드가 많아진다는 단점은 있다.

  • TEMPLATE METHOD 패턴을 사용해 중복을 제거할 수 있다.

    • 테스트 당 개념 하나: 테스트 함수마다 한 개념만 테스트하라. ‘개념 당 assert문을 최소로 줄이고, 테스트 함수 하나는 개념 하나만 테스트 하라’

<F.I.R.S.T>

  • 깨끗한 테스트 규칙 5가지

  1. Fast(빠르게): 테스트는 빨리 돌아야한다.

  2. Independent(독립적으로): 테스트는 서로 의존하면 안된다.

  3. Repeatable(반복가능하게): 테스트는 어떤 환경에서도 반복 가능해야 한다.

  4. Self-Validating(자기검증하는): 테스트가 스스로 성공과 실패를 가늠할 수 있도록 해야한다.(Boolean)

  5. Timely(적시에): 텍스트는 적시에 작성해야 한다. 테스트 하려는 실제 코드를 구현하기 직전에 구현한다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

  • 이번엔 경계 부분이 어려웠다 ㅠㅠ 이 스터디를 통해서 책 겉핥기를 한 것에 만족해야 할 것 같다. 아무래도 두 번, 아니 그 이상으로 읽으면서 내가 아는 언어의 코드와 함께 학습해보는 게 좋겠다. 챌린지 첫째날 자바스크립트로 읽는 클린 코드 레포를 포크 해놨는데, 책 읽는데만 급급해서 그 레포는 아직 보지 못했다. 아마도 코드가 자바이기 때문에 더 눈에 안 익숙한 탓도 있을거라고 (책을 읽을때마다) 생각해본다.

  • 테스트 당 개념 하나라는 소제는, 앞서 읽었던 ‘함수 하나당 하나의 역할만 하라’라고 했던걸 다시금 떠올리게 한다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

  • 소프트웨어 경계: 인터페이스 제공자와 사용자 사이에서 발생하는 입장차이로 인해 문제가 발생할 수 있는 부분(경계)를 의미한다.

  • 경계 인터페이스: 어떠한 메서드에서 map, list와 같은 자료구조를 반환하거나 공개 api 인수로 넘겨 클라이언트에서 해당 인터페이스를 사용하는 경우를 말한다. (참고 사이트 )

  • DSL(Domain-Specific Language, 도메인 특화 언어): 응용 프로그램 도메인 내의 특정 문제를 해결하도록 설계된, 제한된 범위의 컴퓨터 언어 유형.

  • GPL(General-purpose language, 일반 목적 언어): 도메인 전반에 걸쳐 다양한 문제를 해결하도록 설계된 언어. 특정 도메인에 대한 특수 기능이 부족.

  • Java에서 assert: assert구문은 프로그램에 대한 가정 테스트를 할 수 있게 한다. 프로그램의 오류를 감지, 수정하는 효과적인 방법을 제공한다.

  • 템플릿 메소드 패턴 (Template method pattern): 소프트웨어 공학에서 동작 상의 알고리즘의 프로그램 뼈대를 정의하는 행위 디자인 패턴이다. 알고리즘의 구조를 변경하지 않고 알고리즘의 특정 단계들을 다시 정의할 수 있게 해준다.(위키)

나의 최애 북 TIL

  • charminggw님의 TIL: 이전에 읽은 틸이었는데, 중간에 코드를 색깔로 표현해 실제 책과 다르게 가독성을 좀 더 높인 정리가 마음에 들었다. 그리고 궁금한 내용을 사이트와 함께 정리해 두어 많은 도움이 된 TIL.

  • Leeq님의 TIL: 지난번 잡학사전 할때 최애 틸 할때도 읽었는데, (잡학사전 필터 없이 틸을 찾다보니…) 이번에 클린코드를 하면서 다시 또 보게 됐다. leeq님은 추천 틸에도 많이 올라오는데 읽은 소감이 수필의 한 구절을 읽는 느낌이 들어서 항상 볼때마다 신선하다.

  • Pub0836님의 TIL: 정리의 끝판왕인 틸. 노션, velog에 정리한 틸들도 많이 봤지만, 개인용 블로그에 이렇게 깔끔하게 정리된 틸은 처음보는 것 같아 재미있게 읽고 도움도 많이 됐다.