클린코드 스터디 회고 - 002
클린코드 리뷰 - 002
오류처리에 대해
깨끗한 코드를 만들려면 오류처리를 잘 해야 한다.
오류코드를 반환하기 보다는 예외를 던지고 예외처리 함수에 예외처리를 맡긴다.
꼭 확인된 예외로 처리할 필요는 없다. 미확인 예외로도 소프트웨어 구현에 무리없다.
예외를 던질 때 연산 이름, 실패 유형 등 정보를 담아서 던진다.
프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이다.
비즈니스 로직과 오류 처리가 잘 분리된 코드는 깨끗하다.
오류로 null 을 반환하지 마라. 만약 API 가 null 을 반환하면 특수 사례 객체로 감싸서 반환해보라.
null 을 전달하지 마라.
클린 코드는 읽기도 좋아야 하고 안정성도 높아야 한다.
비즈니스 로직과 오류 처리는 분리되어야 유지 보수 효율성이 높다.
외부 라이브러리 사용할 때
외부 라이브러리를 선언한 별도의 클래스를 만들고 사용한다.
외부 라이브러리르 익히는 학습 테스트를 해보라.
학습 테스트를 하면 새 버전의 외부 라이브러리로 이전도 쉬움
아직 존재하지 않는 외부 코드를 사용해야 할 때는 어댑터 패턴을 사용하라.
소프트웨어의 설계가 우수하면 변경에 많은 투자와 재작업이 필요하지 않다.
외부 라이브러리를 새로운 클래스로 감싸거나 어댑터 패턴으로 우리가 원하는 인터페이스로 변환하여 사용해보자.
단위테스트
- 단위 테스트를 작성하기 전에는 실제 코드를 작성하지 않는다.
- 실행이 실패하는 정도의 단위 테스트를 작성한다.
- 단위 테스트를 통과할 정도로만 실제 코드를 작성한다.
테스트 코드도 깨끗하게 짜야한다.
테스트 케이스가 없으면 개발자는 변경을 주저한다.
테스트 케이스가 있어야 아키텍처나 설계의 개선이 가능하다.
- 테스트할 개념 당 assert 문 수를 최소한으로 하라
- 테스트 함수 하나에는 하나의 개념만 테스트하라
테스트 코드의 규칙
- 빠르게 돌릴 수 있는
- 각 테스트가 독립적인
- 어떤 상황에서드 반복 가능하게
- 성공/실패가 명확하게
- 실제 코드를 만들기 직전에
클래스
단일 책임 원칙 : 클래스나 모듈은 변경해야하는 이유가 하나뿐이어야 한다.
높은 응집도, 낮은 결합도를 추구해라
새로운 기능을 추가할 때 기존 코드 건드리는 것을 최소화 할 수 있어야 한다.
시스템을 구축할 때
소프트웨어의 제작 시점과 사용 시점의 관심사를 분리해야 한다.
제작 시점에는 팩토리 패턴을 이용한 의존성 주입을 검토해본다.
처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이다. 점진적으로 개선하라.
프록시, AOP 를 이용하여 관점에 의한 관심사를 분리하라.
시스템을 설계할 때는 실제로 돌아가는 가장 단순한 수단을 사용해야 한다.
창발성
착실하게 따르기만 하면 우수한 설계가 나온다는 켄트 벡의 단순한 설계 규칙 4가지
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
테스트가 불가능한 시스템은 검증도 불가능하고, 검증이 불가능한 시스템은 절대 출시하면 안된다.
테스트가 가능한 시스템을 만들어라.
테스트 케이스를 모두 작성했다면 코드와 클래스를 정리(리팩터링)해보라.
품질을 높이는 리팩터링
- 응집도를 높이고
- 결합도를 낮추고
- 관심사를 분리하고
- 시스템 관심사를 모듈로 나누고
- 함수와 클래스 크기를 줄이고
- 더 나은 이름을 선택하라
중복은 커다란 적이다.
나중에 코드를 유지보수할 사람의 이해를 돕도록 코드에 표현하라
- 좋은 이름을 선택하라
- 표준 명칭을 사용하라
- 단위 테스트 케이스를 꼼꼼히 작성하라.
- 주의를 더 기울여라
함수와 클래스 수를 가능한 줄이는 작업은 4개의 규칙중에 가장 우선순위가 낮다.
동시성
객체는 처리의 추상화, 스레드는 일정의 추상화
동시성은 무엇과 언제를 분리하는 전략이다.
동시성 코드는 다른 코드들과 분리한다.
자료의 사용범위를 제한하고, 공유하는 자료를 최대한 줄여라.
실행모델을 생각해보라
- 생산자-소비자
- 읽기-쓰기
- 식사하는 철학자들
스레드 코드를 테스트하기 위해 문제를 노출하는 테스트 케이스를 작성해보라.
동시성 코드는 실패를 재현하기가 쉽지 않다는 것을 알고, 일회성으로 치부하지 마라.