![클린 코드 : 오류 처리 , 경계 , 단위 테스트, 클래스](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcLINAK%2FbtsIy1PlpQq%2FBSXEta4kkb0wlQLEVcJiY0%2Fimg.png)
오류 처리
오류 코드보다 예외를 사용하라
- 예외를 사용하는 것이 오히려 더 깔끔할 수 있다.
Try-Catch-Finally문부터 작성하라
- 예외 발생할 코드를 작성할 때는 try-catch-finally 서식을 쓰자
미확인 예외를 사용하라
미확인 예외(Unchecked Exception)란?
미확인 예외는 프로그램 실행 중 발생할 수 있는 예외 상황을 나타냅니다.이러한 예외는 반드시 처리하지 않아도 되며, 프로그램이 계속 실행될 수 있습니다.대표적인 미확인 예외로는 NullPointerException, ArrayIndexOutOfBoundsException, ArithmeticException 등이 있습니다.
예외에 의미를 제공하라
- 오류 메세지에 정보를 담아 예외와 함께 던져라
- 예외 던질 때는 전후 상황을 충분히 덧붙여라
정상 흐름을 정의하라
- 클래스를 만들거나 객체를 조작하여 예외를 처리
null을 반환하지 마라
- null을 반환하는 코드는 일거리를 늘리고 호출자에게 문제를 떠넘김
- null이 누락되는 경우도 있음
null을 전달하지 마라
- 메서드로 null 전달하는 것도 나쁨..
- null은 인수로 전달하면 에러가 날 가능성이 생김
경계
경계 살피고 익히기
- 외부 코드 사용하면 보다 적은 시간으로 코드를 만들 수 있다.
- 먼저 간단한 테스트를 통해 외부 코드가 작동하는지 확인 후 우리 코드를 작성하자
학습 테스트는 공짜 이상이다
- 학습 테스트 비용은 없다
- 학습 테스트는 패키지가 예상대로 동작하는지 검증하고 호환성을 확인 할 수 있다
아직 존재하지 않는 코드를 사용하기
- 아는 코드와 모르는 코드를 구분하는 경계
- 인터페이스를 구분하고 구현하여 구현을 먼저 하도록 설계
깨끗한 경계
- 가능하다면 코드의 경계는 외부 말고 우리쪽 코드에 치우치도록
- 경계에 위치하는 코드는 분리를 하여 유지보수성을 높이자
단위 테스트
TDD 법칙 세가지
- 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
- 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다
- 셋째 법칙 : 현재 실패하는 테스트 코드 통과할 정도로만 실제 코드를 작성한다
깨끗한 테스트 코드 유지하기
- 테스트 코드 또한 돌아가는 거에 중점을 두기 보다는 깨끗하게 유지보수할 생각으로 작성하자
- 테스트 코드는 실제 코드 못지 않게 중요하다
테스트는 유연성, 유지보수성, 재사용성을 제공한다
- 단위 테스트 : 코드의 유연성과 유지보수성 재사용성을 제공하는 버팀목 , 단위 테스트가 있다면 변경을 해도 금방 테스트 하고 코드를 검증할 수 있으니까 변경이 두렵지 않다
깨끗한 테스트 코드
- 가독성이 좋은 것이 깨끗한 것
이중 표준
- 테스트 API에 적용하는 표준은 실제 코드 표준과 다르다
테스트 당 assert 하나
- 함수 당 assert문은 하나만 사용해야한다
테스트 당 개념 하나
- 테스트 함수마다 한 개념만 테스트하라
FIRST
- F: fast 테스트는 빨라야한다
- I : independent 각 테스트는 서로 의존하면 안 된다 한 테스트가 다른 테스트의 실행환경을 준비하는 것도 안 된다
- R : repeatable 어떤 환경에서도 반복 가능하도록
- S : self-validating 테스트는 참 거짓으로 결과를 내야한다 성공이 아니면 실패
- T : timely 단위 테스트는 테스트 하려는 실제 코드 구현 직전에 구현하자
클래스
클래스 체계
- 상수 , 비공개 변수 , 비공개 인수턴스 변수 순으로 나옴
- 변수 후에는 공개 함수 , 비공개 함수가 나옴
클래스는 작아야 한다
- 클래스는 작아야한다
- 클래스 하나당 책임은 하나만! SRP
- SRP는 지키기 힘들다 보통 돌아가게 만들려고 코드를 작성하다 보니 관심사 분리를 잘 하지 않음
- 작은 클래스 여러개로 이루어진 시스템이 더 바람직하다
응집도
- 클래스 인스턴스 변수 수가 작아야한다
응집도를 유지하면 작은 클래스 여럿이 나온다
- 작은 클래스 여럿으로 나누어도 알고리즘과 동작 원리를 같으며 더 논리적으로 코드를 작성할 수 있따
변경으로부터 격리
- 요구사항은 변한다 즉 코드 수정이 필요하다
- 시스템 결합도를 낮추면 유연성과 재사용성이 더욱 높아짐
참고
https://product.kyobobook.co.kr/detail/S000001032980
Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고
Clean Code(클린 코드) | 프로그래머, 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가에게 도움이 될 더 나은 코드를 만드는 책『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의
product.kyobobook.co.kr
'도서' 카테고리의 다른 글
클린코드 : 점진적인 개선 (0) | 2024.07.27 |
---|---|
클린코드 : 시스템, 창발성, 동시성 (0) | 2024.07.21 |
클린코드 : 객체와 자료 구조 (0) | 2024.07.07 |
클린코드 : 형식 맞추기 (0) | 2024.07.07 |
클린 코드 : 주석 (0) | 2024.07.07 |
하고 싶은 걸 하고 되고 싶은 사람이 되자!
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!