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

  • 추이적 탐색을 피하라(395p)
    • 일반적으로 한 모듈은 주변 모듈을 모를수록 좋다.
      => A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알아야 할 필요는 없다는 뜻이다.
    • 디미터의 법칙이라 부른다.
    • 내가 아는 모듈이 연이어 자신이 아는 모듈을 따라가며 시스템 전체를 휘저을 필요가 없다는 의미다.

  • 서술적인 이름을 사용하라(399p)
    • 이름은 성급하게 정하지 않는다.
    • 소프트웨어 가독성의 90%는 이름이 결정한다.
      => 시간을 들여 현명한 이름을 선택하고 유효한 상태로 유지한다.
    • 신중하게 선택한 이름을 보고 독자는 모듈 내 다른 함수가 하는 일을 짐작한다.

  • 적절한 추상화 수준에서 이름을 선택하라(401p)
    • 구현을 드러내는 이름은 피하라.
    • 작업 대상 클래스나 함수가 위치하는 추상화 수준을 반영하는 이름을 선택하라.

  • 커버리지 도구를 사용하라!(404p)
    • 커버리지 도구는 테스트가 빠뜨리는 공백을 알려준다.
    • 커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다.

 

 

 

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

  1. 이전 프로젝트에서 커버리지 도구에서 테스트가 불충분한 모듈도 포함을 시켰었던 게 생각났습니다.
    • 카카오 로그인 API 였었는데 예전에는 그것을 포함시켜야 하나 고민이 되었었습니다.
      이 책을 읽고 불필요한 테스트는 제외해도 된다는 걸 알게 되었습니다.

 

 

 

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

  • 코드 커버리지란?
    • 코드 커버리지는 소스 코드를 기반으로 수행하는 화이트 박스 테스트를 통해 측정한다.
      • 블랙박스 테스트
        => 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식
        => 올바른 입력과 올바르지 않은 입력을 입력하여 올바른 출력이 나오는지 테스트하는 기법
        => 사용자 관점의 테스트 방법이라 볼 수 있다.

      • 화이트 박스 테스트
        => 응용 프로그램의 내부 구조와 동작을 검사하는 테스트 방식이다.
        => 소프트웨어 내부 소스 코드를 테스트하는 기법이다.
        => 개발자 관점의 단위 테스트 방법이라 볼 수 있다.

 

 

 

👀 소감 3줄 요약

  • 일군의 규칙만 따른다고 깨끗한 코드가 얻어지지 않는다.
  • 휴리스틱 목록을 익힌다고 소프트웨어 장인이 되지는 못한다.
  • 전문가 정신을 가진 개발자가 되자!!

 

 

 

 

 
반응형

+ Recent posts