[TIL] "클린코드" 8일차

DAY 8

오늘 읽은 범위 : 7장, 오류처리

 

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

• 뭔가 잘 못될 가능 성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다.(p.130)
• 오류 코드보다는 예외를 사용하라. 오류가 발생하면 예외를 던지는 편이 낫다. (p.131)
• Try-Catch-Finally 문부터 작성하라. 예외에서 프로그램 안에다 범위를 정의한다는 사실은 매우 흥미롭다. try-catch-finally 문에서 try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어 갈 수 있다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야한다. 그러므로 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다.(p.132)
• 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. (p.133)
• 예외를 던질 때는 전후 상황을 충분히 덧붙인다. 오류가 발생할 원인과 위치를 찾기가 쉬워진다.(p.135)
• 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.(p.135)
• 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. 다른 라이브러리로 갈아타도 비용이 적다. 테스트 코드를 넣어주는 방법으로 프로그램을 테스트 하기도 쉬워진다. 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다. (p.137)
• null을 반환하지 마라. null을 반환하는 코드는 일거리를 늘릴 뿐 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다. (p.139)
• 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. (p.139)
• 메서든에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다.(p.140)
• 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다. 즉, 인수로 null이 넘어오면 코드에 문제가 있다는 말이다. 이런 정책을 따르면 그만큼 부주의한 실수를 저지를 확률도 작아진다.(p.142)

오늘 읽은 소감은? 떠오른 생각을 가볍게 적어보세요

• try-catch 문을 과거 부트캠프 시절에 배우긴 했었는데 수박 겉핥기 식으로 듣고 넘어간거여서 이런 방식으로 써야한다는 것을 이번에서야 처음 알았다. 그때 한번에 제대로 들었더라면 이번 부분을 더 깊게 이해할 수 있었을 텐데 그때의 나는 간절함이 부족했던 것 같다.
• 오류가 발생하면 어디서부터 고쳐야 할지 항상 막막했는데 만약 이런 상황이 펼쳐진다면 어떻게 대처하고 코드를 어떻게 구상할지에 대한 로드맵 같은 기분이라 조금 더 이해해보려고 노력하게 됐다.

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

• 트랜잭션이란?
• TDD란?
• 확인된 예외란?
• OCP란?
• 로깅기능이란?
• 특수 사례 패턴이란?
• NullPoinerException이란?

트랜잭션 # DB의 상태를 변경시키는 작업의 단위
트랜잭션은 쉽게 말해, 한꺼번에 수행되어야 할 연산을 모아놓은 것이다. 연산들을 모두 처리하지 못 한 경우에는 원 상태로 복구한다. 즉, 작업의 일부만 적용되는 현상이 발생하지 않는다. 이를 통해 트랜잭션은 작업의 완전성을 보장해준다.

TDD란 # 테스트 주도 개발(test-driven development, TDD)은 소프트웨어 개발 방법론 중의 하나로, 선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식의 프로그래밍 방법을 말한다.

체크 예외는 RuntimeException 클래스를 상속받지 않은 예외 클래스들이다. 체크 예외는 복구 가능성이 있는 예외이므로 반드시 예외를 처리하는 코드를 함께 작성해야 한다. 대표적으로 IOException, SQLException 등이 있으며, 예외를 처리하기 위해서는 catch 문으로 잡거나 throws를 통해 메소드 밖으로 던질 수 있다. 만약 예외를 처리하지 않으면 컴파일 에러가 발생한다.
출처: https://mangkyu.tistory.com/152 [MangKyu's Diary:티스토리]

개방 폐쇄 원칙 - OCP (Open Closed Principle) 개방 폐쇄의 원칙(OCP)이란 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계가 되어야 한다는 원칙을 말한다. 보통 OCP를 확장에 대해서는 개방적(open)이고, 수정에 대해서는 폐쇄적(closed)이어야 한다는 의미로 정의한다. 여기서 확장이란 새로운 기능이 추가됨을 의미한다. 따라서 해석하자면, 기능 추가 요청이 오면 클래스를 확장을 통해 손쉽게 구현하면서, 확장에 따른 클래스 수정은 최소화하도록 프로그램을 작성해야 하는 설계 기법을 말한다고 보면 된다.
출처: https://inpa.tistory.com/entry/OOP-💠-아주-쉽게-이해하는-OCP-개방-폐쇄-원칙[Inpa Dev 👨‍💻:티스토리]

로깅은 어떤 소프트웨어가 실행될 때 발생하는 이벤트를 추적하는 수단이다. 소프트웨어 개발자는 코드에 로깅 호출을 추가하여 특정 이벤트가 발생했음을 나타낸다. 이벤트는 선택적으로 가변 데이터 (즉, 이벤트 발생마다 잠재적으로 다른 데이터)를 포함할 수 있는 설명 메시지로 기술된다.

특수 사례 패턴 간단 설명 ✔클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다. 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하므로 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.
출처: https://doosicee.tistory.com/entry/경계-외부-API를-대하는-방법-실전편 [I move forward every day.:티스토리]

NullPointerException은 실제 값이 아닌 null을 가지고 있는 객체/변수를 호출할 때 발생하는 예외다.