개발자 온보딩 가이드 리뷰 -1

장애에 대비하기 위한 방어적 프로그래밍 방안

• 방어적 코드
  • 컴파일 타임의 유효성 검사를 통해 런타임 장애를 최소화한다.
• 안전한 코드
  • 컴파일 타임의 유효성 검사를 통해 런타임 장애를 최소화한다.
• 회복성 있는 코드
  • 권장되는 예외 처리 기법을 활용하며 장애를 적절하게 처리한다.

null 값 사용은 피하자

널 포인터 예외를 방지 하기위해서

• 널 객체 패턴
  • 널 값 대신에 객체를 사용하는 패
• 옵션 타입등을 사용

불변 변수를 사용하자

불변 변수

• 값이 한 번 대입되고 나면 그 값을 바꿀 수 없다.
• 의도치 않게 변수의 값이 바뀌는 상황을 미연에 방지
• 병렬 프로그래밍은 더 간단해짐
• 경우에 따라 컴파일러나 런타임은 더 효율적으로 동작할 수 있다.

타입 힌트와 정적 타입 검사를 사용하자

변수가 보관할 수 있는 값을 제한하자

• 가장 구체적인 타입을 사용
  • 몇 가지 문자열 값 중 하나만 가질 수 있는 변수는 String 타입보다는 Enum으로 선언 할 수 있다.
• 변수를 제한 하면, 예상치 못한 값을 대입해도 버그를 유발하지 않고 그 즉시 실패하게 된다.
• 파이썬, 소르베를 활용하는 루비, 자바스클비트 등 동적 언어에서도 견고한 타입힌트와 정적 타입검사기의 지원이 늘어나고 있다.
  • 타입 힌트는 기존의 코드베이스 점진적으로 추가할 수 있다.
  • 타입 힌트를 이용해서 코드가 실행되기 전에 버그를 찾아내는 정적 타입 검사기까지 도입하면 런타임 에러를 피할 수 있다.

입력값을 검사하자

코드로 전달되는 입력값은 절대로 신뢰하지 말자.

• 개발자, 결함이 발생한 하드웨어, 사람의 실수 등으로 입력 데이터가 훼손될 수 있기 때문이다.
• 제대로 된 입력값이 전달됐는지 확인해서 코드를 보호하자.
• 사전 조건, 체크섬 및 데이터 유효성 검사, 보안 관련 권장 기법, 보편적인 에러를 찾아주는 도구 등을 활용하자.
• 원치 않는 입력값이 전달되면 최대한 이른 시점에 실행을 거부하도록 조치해두자.
• 만약 내가 쓰는 타입이 유효한 변수값을 완전히 다룰 수 없는 경우라면 사전 조건을 이용해 유효성을 검사한느 라이브러리와 프레임워크를 사용하자.

예외를 활용하자

예외는 이름도 있고 스택 추적 정보, 줄 번호, 메시지 등 null이나 -1만으로 표현하지 못하는 훨씬 더 많은 정보를 담고 있다.

• 예를 들면ZeroDivisionError는 None리턴값이 제공하는 범위를 넘어서 훨씬더 풍부한 정보를 리턴한다

예외는 구체적으로 사용하자

예외를 구체적으로 정의하면 코드를 더 쉽게 사용할 수 있다.

• 가능하면 내장된 예외를 사용하고 포괄적인 의미를 담는 예외는 만들지 않게 하자.
• 예외는 애플리케이션 로직을 제어하는 용도가 아니라 실패를 처리할 때만 사용해야 한다.
• 대부분의 언어는 언어에 내장된 예외 타입을 제공한다.
• 언어에 내장된 예외 타입이 문제를 구체적으로 표현 할 수 있다면 임의로 예외를 정의하지는 말자.
• 예외를 직접 정의할 때는 너무 포괄적인 의미가 담기지 않게 하자.
• 개발자가 에러에 적절히 대응할 수 있도록 예외는 최대한 구체적으로 정해두자.
• 그리고 예외를 애프리케이션 로직에 사용해서는 안 된다.
  • 예외를 이용해 메소드를 분기하면 이해도 어려울 뿐더러 디버깅도 어려워진다.

예외는 일찍 던지고 최대한 나중에 처리하자

일찍 던지고 늦게 잡는 원칙을 따르자.

• 일찍 던진다는 말은 개발자가 관련 코드를 신속하게 찾을 수 있도록 에러가 발생한 지점으로부터 최대한 가까운 지점에서 예외를 던진다는 뜻이다.
• 에러가 발생했는데 예외를 던지기 전에 다른 코드를 실행하면 또 다른 에러가 발생할 위험이 있다.
• 만일 두 번째 에러가 발생해서 예외가 던져지면 첫 번째 에러는 발생했을지도 모르고 넘어가게 된다.
  • 왜나면 진짜 문제는 다른 곳에서 발생했다는 사실을 알아내야만 버그를 수정할 수 있기 때문이다.
• 예외를 늦게 잡는다는 말은 예외를 처리할 적절한 위치에 도착할 때까지 계속 호출 스택을 통해 전파시킨다는 뜻이다.
  • 애플리케이션이 데이터를 기록하려는데 남은 디스크 공간이 없는 경우
    • 실행을 중단하고 재시도를 한다거나
    • 비동기적으로 재시도하는 방법
    • 다른 디스크에 기록하거나
    • 사용자에게 경고 메시지를 보낼 수도 있다.
    • 심지어 크래시가 발생하도록 놔두는 것도 방법
  • 경우에 따라 어설프게 try-catch로 삼겨지기보다 예외를 상위 계층으로 전파는 방식이 맞다.
  • 따라서 경우에 따라서 상위 스택으로 전파하는 것도 하나의 스택이다.

재시도는 현명하게

• 가장 손쉬운 재시도 방식은 단순히 예외를 잡아서 그 즉시 작업을 다시 시도
• 백오프(backoff) 비선형으로 대기 시간을 늘리는 방법이다.
  • 천둥떼 현상이라고 부르는 재시도 요청이 동시에 몰리는 현상도 있다.
  • 이런 문제를 해결하기 위해 백오프 전략에 지터(jutter)를 추가해야 한다.
    • 특정 범위에서 임의의 값을 백오프 시간에 더하는 것인 것 같다.
  • 실패한 요청을 무턱대고 재시도하지는 말자
    • 특히 데이터를 기록하는 작업이나 비즈니스 절차를 시작하는 요청은 더욱 주의해야 한다.
    • 설계 시점에서 처리를 염두에 두지 않은 에러가 발생하면 차라리 애플리케이션이 크래시하도록 놔두는 편이 낫다.
    • 이런 방법을 빨리 실패하기 라고 한다.
      • 빨리 실패하면 더 이상의 피해가 없을 것이고 사람이 올바르게 대처할 방법을 찾을 수 있다.