클린 코드 독서일지 - Day 43

N7: 이름으로 부수 효과를 설명하라

함수, 변수, 클래스의 이름에 부수 효과를 숨기지 않는다.
=> 여러 작업을 수행하는 함수일 경우, 하는 일을 모두 기술하는 이름을 사용한다.

테스트

T1: 불충분한 테스트

테스트 케이스는 잠재적으로 깨질 만한 부분을 모두 테스트해야 한다.
=> 테스트 케이스가 확인하지 않는 조건이나 검증하지 않는 계산이 있다면 그 테스트는 불완전하다.

T2: 커버리지 도구를 사용하라!

커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다.
대다수 IDE는 테스트 커버리지를 시각적으로 표현하여 테스트가 빠뜨리는 공백을 알려준다.

T3: 사소한 테스트를 건너뛰지 마라

사소한 테스트는 짜기 쉽고, 제공하는 문서적 가치는 구현에 드는 비용을 넘어선다.

T4: 무시한 테스트는 모호함을 뜻한다

불분명한 요구사항은 테스트 케이스를 주석으로 처리하거나 테스트 케이스에 @Ignore를 붙여 표현한다.

T5: 경계 조건을 테스트하라

경계 조건은 실수하는 경우가 흔하므로 각별히 신경 써서 테스트한다.

T6: 버그 주변은 철저히 테스트하라

버그는 서로 모이는 경향이 있으므로 한 함수에서 버그를 발견했다면 그 함수를 철저히 테스트하는 편이 좋다.

T7: 실패 패턴을 살펴라

때로는 테스트 케이스가 실패하는 패턴으로 문제를 진단할 수 있다.

T8: 테스트 커버리지 패턴을 살펴라

통과하는 테스트가 실행하거나 실행하지 않는 코드를 살펴보면 실패하는 테스트 케이스의 실패 원인이 드러난다.

T9: 테스트는 빨라야 한다

느린 테스트 케이스는 실행하지 않게 되고 일정이 촉박할 때 제일 먼저 건너뛴다.

결론

이 장에서 소개한 휴리스틱과 냄새 목록을 통해 가치 체계를 알도록 한다.

동시성 2

225쪽에서 소개한 동시성을 좀 더 자세히 설명하고 보완한다.

클라이언트/서버 예제

• 클라이언트/서버 코드의 성능이 만족스럽지 않을 경우, 먼저 애플리케이션이 어디서 시간을 보내는지 알아야 한다. 가능성은 다음 두 가지이다. (특정 연산을 살펴보면 대개 둘 중 하나가 지배적이다.)
  1. I/O - 소켓 사용, 데이터베이스 연결, 가상 메모리 스와핑 기다리기 등에 시간 소모
  2. 프로세서 - 수치 계산, 정규 표현식 처리, 가비지 컬렉션 등에 시간 소모
• 만약 프로그램이 프로세서 연산에 시간을 보낸다면 새로운 하드웨어를 추가해 성능을 높이는 방식이 적합하다.
  => 프로세서 연산에 시간을 보내는 프로그램은 스레드를 늘인다고 빨라지지 않음 -> CPU 사이클에 한계가 있기 때문
• 만약 프로그램이 I/O 연산에 시간을 보낸다면 동시성이 성능을 높여주기도 함 => 시스템 한쪽이 I/O를 기다리는 동안에 다른 쪽이 뭔가를 처리해 노는 CPU를 효과적으로 활용할 수 있다.

스레드 추가하기

• 서버의 process 함수가 주로 I/O 연산에 시간을 보낸다면 스레드를 추가하여 성능을 높일 수 있다.
• 다중 스레드 프로그램을 깨끗하게 유지하려면 스레드 관리 코드를 한 곳에 모아야 한다. => 스레드를 제어하는 동시성 정책을 바꾸기 쉽게 하기 위함
• 스레드를 관리하는 코드는 스레드만 관리해야 한다. -> 동시성 문제는 그 자체만으로도 추적하기 어렵기 때문
• 소켓 연결 관리, 클라이언트 처리, 스레드 정책, 서버 종료 정책의 각 책임마다 클래스를 만들어 책임을 분리하는 것이 좋다.