[Week] 4주차 진도

[ChoMk]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @ChoMk

진도

• chapter 7 : 오류처리
• chapter 8 : 경계

발표자료

• 발표자료 링크는 여기에!
• 7장
• 8장

[KimYealynn]

Chapter07. 오류처리

• 미확인 예외를 사용하자. : 확인된 예외는 OCP를 위반한다. 하위 메서드에서 코드를 변경하면 상위 메서드에서도 해당 예외를 정의해야한다.

  • [ 확인된 예외(checked exception) ] 잘못된 코드가 아닌 잘못된 상황에서 발생하는 예외파일 열기와 같이 정확한 코드로 구현했음에도, 외부 환경(파일이 없는 상황 등)에 따라 발생 가능예외처리를 구현하지 않으면 컴파일 에러 발생 (컴파일 시 확인해서 확인된 예외) RuntimeException 이외의 예외들
  • [ 미확인 예외(unchecked exception) ] 런타임 시 잘못 구현된 코드로 인해 발생하는 예외컴파일 에러가 나지 않지만 적절한 예외처리가 없을 경우 프로그램이 강제 종료컴파일 시 확인하지 않기 때문에 미확인 예외RuntimeException에 포함된 예외들

• 예외를 대응하는 방식이 예외 유형과 무관하게 동일 하므로 간단히 class로 감싸 줌으로서 코드를 간결하게 고칠 수 있다. 외부 API를 감쌈으로서 의존성을 크게 줄여 이후 다른 라이브러리로의 전환 비용도 적다.

• try { A } catch { a } A가 안 될 때 비슷한 동작 혹은 기본 값을 이용해 A에서 못 한일을 대체 하는 a라는 로직은 논리를 따라가기 어렵게 만든다. 대신 A가 안되면 a를 하는 함수를 만들어 try/catch를 제거하자.

• null을 반환하지 마라...........(가능한 일인가.................ㅜ)

• 읽기 좋은 것과 안정성이 높은 것은 상충하는 목표가 아니다. 오류 처리를 프로그램 논리와 분리해 독자적으로 고려하면 안정적이고 유지보수성이 높아진다.

Chapter08. 경계

• 외부 인터페이스를 사용 할 때 향후 인터페이스 업데이트 시 수정할 코드가 많아 질 수 있으며 오용할 여지가 있다. 이 때 클래스 안으로 숨겨 유지보수와 사용이 용이하게 할 수 있다. 외부 인터페이스를 사용할 때 마다 캡슐화를 하란 것이 아니라 이를 이용하는 클래스나 클래스 계열 밖으로 노출 되지 않도록 한다.

• 외부코드를 익히고 통합시키는 것은 어렵다. 먼저 우리 코드를 작성하고 외부코드를 호출하기 전 간단한 테스트 케이스를 통해 외부 코드를 먼저 익히는 것을 학습 테스트라고 한다.

• 학습 테스트를 통해 API 를 사용하는 방법을 익히고 독자 적인 클래스로 캡슐화 한 다면 이후 프로그램 작성시에는 해당 API를 몰라도 된다.

• 새버전이 나온다면 학습 테스트를 돌려 차이를 바로 확인 할 수 있어 새 버전으로 이전하기 쉬워진다.

[minSW]

[Chapter 7] 오류 처리

📖 기억에 남는 부분 & 느낀점

깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 깨끗하고 튼튼한 코드를 위한 우아하고 고상하게 오류를 처리하는 기법을 소개

오류 코드보다 예외를 사용하라

• 던질까 말까~ 던질까 말까~ 🤾🏻 던 던 던 던 던져! 던져!
• + 로직적인 알고리즘과 오류를 처리하는 알고리즘을 분리

Try-Catch-Finally 문부터 작성하라

• 예외에서 범위를 정의하다
• 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법 (=> 자연히 try 블록의 트랜잭션 범위부터 구현)
  • 📌한번 시도해보고 싶은 TDD

미확인(unchecked) 예외를 사용하라

• 확인된 오류가 치르는 비용의 손익을 따져볼 것 (ex. OCP 위반)
• 유용한 케이스도 있지만 일반적으로는 이익보다 의존성이란 비용이 더 크다.

정상 흐름을 정의하라 / null을 반환・전달하지 마라

• => 특수 사례 패턴 (Spectial Case Pattern)
  • 클래스를 만들거나 객체를 조작해 (예외적인 상황을 캡슐화하여) 특수 사례를 처리하는 방식
• NullPointerException, InvalidArgumentException
  • null을 반환하거나 인수로 null을 넘기는 코드는 문제가 있음
  • Assert 문 사용
  • Assertion은 프로그램이 올바르게 실행되도록 해주는 효과적인 도구
  • 출처 - Assertion vs Exception (by. javacan)

결론

• 오류 처리를 프로그램 논리와 분리하여 독자적인 사안으로 고려하라
  • => 독립적인 추론 가능 (코드 유지보수성 ↑)
• 항상 오류 처리는 IDE에서 알려주는 warning 해결 & NPE 방어 용도로만..
  • 가독성과 처리를 위해서 'vavr' Try 사용 정도?
  • 앞으론 예외처리 로직 분리나 특수 사례 패턴도 적용해볼 수 있을 듯

[Chapter 8] 경계

📖 기억에 남는 부분 & 느낀점

외부 코드를 우리 코드에 깔끔하게 통합하기 위하여 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 소개

경계 살피고 익히기 / 학습 테스트는 공짜 이상이다

• 외부 코드를 익히는 것 & 외부 코드를 통합하는 것 => 둘 다 어려움
• 학습 테스트 (Learning Test) _ Jim Newkirk
  • 테스트 케이스를 통해 외부 코드(외부 API)를 익히는 방법
  • (외부) 패키지가 새 버전이 나왔을 때 예상대로 도는지 검증 => 부지런한 버전업 가능

깨끗한 경계

• 경계에 위치하는 코드는 깔끔히 분리하고, 기대치를 정의하는 테스트케이스도 작성
• 통제 불가한 외부 패키지에 의존하는 대신, 통제 가능한 우리코드에 의존하는 편이 좋다.
  • 잘... 안돼요... 🥺🥺
  • => 외부 패키지를 호출하는 코드를 최소화하여 경계 관리 (ex. 새 클래스로 감싸기, Adapter 패턴 사용 등...)

따로 찾아본 부분

• ADAPTER 패턴
  • 참고 - [디자인패턴] 어뎁터 패턴 (by. gdtbgl93)
• p.151 [WELC] 참고
  • WELC (Working Effectively with Legacy Code (Feathers, Michael C.), 레거시 코드 활용 전략)

🤔 질문

• (p.146) Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다에 대한 의견
  • 경계 인터페이스를 여기저기 노출시키지 말라는 의미로 말한거지만..

[DaehunGwak]

07. 오류 처리

• 무언가 잘못될 가능 성은 존재한다. 그 잘못됨을 잡을 책임은 프로그래머에게 있다.
• 오류 처리 코드 때문에 실제 코드가 하는 일이 무엇인지 파악하기 어려워지는 일을 막아볼 수 있게 가이드 하는 장

느낀점

• 외부 API는 try-catch 로 감싸보자
• 지금 새로운 프로젝트 시작하고 있는데, 로깅에 대해 한번더 생각하게 되는 좋은 공부였음

요약 정리

• 오류 코드보단 예외를 사용하라 (if 덕지 덕지 보다 깔끔)

• Try-Catch-Finally 문부터 작성하라

  • TDD 로 접근한다는 것이 흥미로움

• 미확인 예외를 사용하라

• 예외에 의미를 제공하라

  • 오류 메세지에 정보를 담아 예외와 함께 던짐

• 호출자를 고려해 예외 클래스를 정의하라

  • 오류를 정의할 때 가장 중요한 포인트는 오류를 잡아내는 방법
  • 실제로 외부 API 호출할 때 예외로 감싸는게 최선
  • 한 가지로 추상화 가능한 예외라면 하나의 예외로 감싸는 예외 클래스를 만들자

• 정상 흐름을 정의하라

  • 앞을 지키다 보면 오류 감지가 프로그램 언저리로 밀려나기 마련
  • 기본 값을 메인 기능 메소드 내에서 정의한다면, 호출 하는 서비스 메서드에서 굳이 예외를 적용할 필요가 없음

• null 을 반환하지 마라

  • 해당 행위는 호출자에게 책임을 맡기는 행위
  • null 대신
  • 예외를 던지거나
  • 특수 사례 객체를 반환
    • ex) 리스트를 반환하는 메서드에서, null 대신 size가 0인 리스트로 반환

• null 을 전달하지 마라

미확인 예외를 사용하라

• 확인된 예외 vs 미확인 예외 (자바 기준)

C++, C#, python, ruby 는 미확인 예외밖에 없음

출처: https://codevang.tistory.com/140

[ 확인된 예외(checked exception) ]

• 잘못된 코드가 아닌 잘못된 상황에서 발생하는 예외
• 파일 열기와 같이 정확한 코드로 구현했음에도, 외부 환경(파일이 없는 상황 등)에 따라 발생 가능
• 예외처리를 구현하지 않으면 컴파일 에러 발생 (컴파일 시 확인해서 확인된 예외)
• RuntimeException 이외의 예외들

[ 미확인 예외(unchecked exception) ]

• 런타임 시 잘못 구현된 코드로 인해 발생하는 예외

• 컴파일 에러가 나지 않지만 적절한 예외처리가 없을 경우 프로그램이 강제 종료

• 컴파일 시 확인하지 않기 때문에 미확인 예외

• RuntimeException에 포함된 예외들

• 확인된 예외는 OCP (Open Closed Principle) 을 위반한다

  • 연쇄수정 발생
  • 하위 메서드에서 확인된 예외를 던지면 상위 메서드에 모두 해당 예외를 정의해야 함

08. 경계

소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살필 예정

느낀점

• 학습 테스트 해봐야겠다
• 외부 콜 되는 부분을 Adapter 패턴 적용해봐야겠다

요약 정리

• 외부 코드 사용하기

  • Map 은 누구든 삭제 및 갱신을 할 수 있음
  • 누구든 삭제 및 갱신하지 못하게 관리하려면, 클래스를 하나 만들어 Map interface를 캡슐화 함
  • 물론 사용할 때마다 캡슐화 하는 것이 아니라, Map 과 같은 인터페이스를 여기저기 넘기지 마세요

• 학습 테스트 는 공짜 이상이다

  • 학습테스트: 외부 코드를 사용하기 전, 학습 겸 외부 코드 호출 테스트를 작성

• 아직 존재하지 않는 코드를 사용하기

  • 구현이 되지 않은 것을 미리 짜야할 경우가 생김 (ex. API 개발 안되었는데 프론트에서 미리 개발해야되는 상황)
  • Adapter 패턴으로 실제 API 구현이 완료되었을 때 interface를 상속받아 API call 부분을 wrapping 해서 구현

[jin5335]

느낀점

• 예외(exception)을 사용해서 오류 처리와 코드 로직 분리
• wrapping 을 통한 코드 추상화를 잘하자(이전 챕터들에서 부터 한결 같이 하고 있는 이야기)
  • 외부 라이브러리는 필히 wrapping 할 것.
  • 외부 api가 null을 반환한다면, 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환
• 학습 테스트를 통해 외부 API 익히기
  • 코드를 짜면서 외부 api를 익히지 말고, 통제된 환경에서 익히기
  • 학습 테스트는 단위 테스트 케이스로 만들어서 남겨두기

Ch.07 오류 처리

오류 코드보다 예외를 사용하라.

• 오류 코드 or 플래그 사용 -> 함수를 호출하고, 바로 오류를 확인해야 해서 코드가 더러워지며 오류 코드 처리와 프로그램의 logic이 섞인다.

Try-Catch-Finally 문부터 작성하라

• 범위를 정의한다 - 강제로 예외를 일으키는 테스트를 작성한 후, 테스트를 통과하게 코드를 작성하는 방법을 권장 ( 자연스럽게 try 블록의 transaction 범위부터 구현)
• try 블록은 transaction과 유사, try 블록에서 무슨 일이 생기든 catch 블록에서 프로그램의 상태를 일관성 있게 유지시켜야 한다.

미확인(unchecked) 예외를 사용하라

• 확인된 예외
  • 최상위 함수에서 최하위 함수의 확인된 예외의 종류를 알게하여, 캡슐화를 깨뜨린다.
  • 최하위 함수의 예외가 추가되면, 그 위에 모든 함수에 새로운 예외를 추가해야 한다. (OCP 위반)

예외에 의미를 제공하라.

• 자바는 모든 예외에 호출 스택을 제공하지만, 오류 메세지에 정보를 담아 예외와 함께 던지면 오류 원인 파악에 도움이 된다.
  • 자바에서 오류 코드만 사용하면, 호출 스택을 제공하지 않아서 오류 원인 파악이 어려움 -> 한번 잔소리 들음 ㅜㅜㅜ

호출자를 고려해 예외 클래스를 정의하라

• 오류를 잡아내는 방법에 최대한 관심을 두어라
• 중복 코드 및 함수에 로직을 clear하게 하는 것에는 wrapping 만한 것이 없는 것 같다. -> 딴 함수로 빼라.
  • 특히 외부 라이브러리를 wrapping을 하게 되면, 외부 라이브러리에 대한 의존도도 분리할 수 있어서 외부 라이브러리가 변경 되어도 유연하게 대처 가능.

정상 흐름을 정의할 것

null을 반환 하지 마라

• null을 반환하는 경우, 호출자에게 일을 떠넘기게 된다. -> 차라리 예외 or 특수 사례 객체(special case pattern) 반환해라.

null을 전달하지 마라

• 대다수의 프로그래밍 언어는 호출하기 실수로 넘기는 null을 적절히 처리하는 방법이 없다. -> 애초에 null을 넘기지 못하도록 금지해라.

Ch08. 경계

• 외부 코드를 우리 코드에 깔끔하게 통합하는 방법

외부 코드 사용하기

• 외부 코드를 바로 사용하지말고, 중간 단계로 클래스로 추상화 해라
  • 클래스의 클래스 사이에 인수나 반환값으로 주고 받을 경우
  • ex) map -> sensors

경계 살피고 익히기

• 우리쪽 코드를 작성하면서 외부 코드를 익히지 말고, 테스트 케이스를 작성하여 외부 코드를 익혀라.
• Jim Newkirk는 이를 학습 테스트라고 부른다.

Log4j 익히기

• 삽질 후 단위 테스트 케이스로 만들기

학습 테스트는 공짜 이상이다.

• 통합된 이후에, 외부 라이브러리의 코드가 바뀌었을 때 학습 테스트를 통해 변한 부분을 빠르게 확인하고 대응 가능하다.

아직 존재하지 않는 코드를 사용하기

• 아는 코드와 모르는 코드를 분리하는 경계
• 아직 구현되지 않았다면, 중간 인터페이스를 정의하자
  • fe와 back end 사이에 mock api 정의하듯?

깨끗한 경계