2/21

Checked Exception, Unchecked Exception

Checked Exception

• Checked Exception : Exception을 상속. compiled time에 catch 가능함. try catch를 사용하지 않으면 컴파일 에러가 발생한다.
• exception이 발생하는 메서드가 throws 예약어로 Exception을 호출 메서드에 전달해야 한다.

Unchecked exception

• Run Time Exception이라고 한다.
• 컴파일 시점에 Exception을 catch하는지 확인하지 않는다. 컴파일 시점에 Exception이 발생할 것인지의 여부를 판단할 수 없다.
• Exception이 발생하는 메서드에서 throws 예약어를 활용해 Exception을 처리할 필요가 없지만 처리해도 무방하다.

Checked Exception, Unchecked Exception 선택 방법

• (코틀린은 checked exception이 없다고 한다)
• 호출하는 메서드가 Exception을 활용해 뭔가 의미있는 작업을 할 수 있다면 Checked Exception을 사용하라.
• 호출하는 메서드가 Exception을 catch해서 예외 상황을 해결하거나 문제를 해결할 수 없다면 Unchecked Exception을 사용하라.
• 명확하지 않다면 Unchecked Exception을 사용하라.
• 내 생각: checked Exception을 사용하지 않아도 될 것 같다. 낮은 수준에서 checked exception을 사용한 경우 그 함수를 사용하는 모든 함수에서 throws를 사용하게 되어 함수를 사용하기 어렵다. (후추의 추가 의견 : checked exception이 안정성을 완벽히 보장하는 것이 아니다. 사용하는 쪽에서 예외처리를 어떻게 하느냐에 달려있기 때문이다.)

Exception 처리

• 메소드에서 여러 개의 Exception을 throw 하는 경우 쉼표로 구분할 수 있다.
• 메서드에서 여러 개의 Exception을 throw할 때 부모 클래스로 예외를 전달하는 방법도 있다. (ObjectStreamException, UnknownHostException을 Exception으로 통합해서 던지는 것)
• 메서드를 호출할 때 예외를 처리한 후, 예외를 재전달(rethrow)하는 것도 가능하다.

복구

• 예외가 발생한 문제를 정상 상태로 돌려놓는다. (파일 등에 저장을 해두는 등)
• 재처리 또한 복구에 해당된다.

int readTryCount() {
  try {
      return Integer.parseInt(InputView.read());
        } catch (final NumberFormatException e) {
	    return readTryCount();
      }
  }

회피

• 직접 예외를 처리하지 않고 호출한 쪽으로 회피할 수 있다.
• 고민없는 회피는 외면하는 것과 같다. 회피를 할 때는 많은 고민 후 결정한다.

무시

• catch에 아무런 로직도 없는 경우
• 진짜 외면하는 경우도 있다. 무시를 하는 경우는 더 많은 고민이 필요하다.

전환

• Checked Exception을 Unchecked Exception으로 전환할 수 있다.
• DbException 같은 경우 도메인 계층까지 전달되기 전에 추상화 계층에 맞는 예외로 변경 하거나 적절한 시점에 예외를 처리할 수도 있다.

List

• 데이터 저장 방식: ArrayList와 LinkedList
• ArrayList: 데이터의 추가, 삭제를 위해 아래와 같이 임시 배열을 생성해서 데이터를 복사하는 방법을 사용
• LinkedList: 데이터를 저장하는 각 노드가 이전 노드와 다음 노드의 상태만 알고 있다.

2/22

슬기로운 우테코 생활

• 절망의 골짜기. 내가 재작년~작년에 경험했었는데 지금은 좀 더 올라가는 중인 것 같다. 아직 절망의 골짜기이지만 기울기가 양수가 되어가는 시점이 아닐까?
• 레벨1: 경쟁의식 버리기. 옆 크루와 같이 학습하고 성장하는 방법을 찾는다. 주변과 비교하지 않고 '나의' 배움과 성장에 집중한다. 내 가장 큰 라이벌은 옆의 크루가 아니라 어제의 나라는 것을 잊지 말기.
• 레벨2, 3: 꾸준함, 소프트스킬. 난이도가 높아지고, 성장은 더디고, 흥미는 떨어지는 단계. 자신만의 학습 방법을 찾고, 학습 속도를 유지하면서 꾸준히 학습하는 습관을 만든다. 기술적인 역량 외에 소프트스킬 역량을 향상시키는데도 관심을 가져야 한다. 특히 팀플에서 사람들 만날 때 더 어려움을 느낄 때가 많으니 소프트스킬을 향상 시킬 수 있는 좋은 기회라고 생각해보자.
• 레벨4: 멘탈 관리. 수박 겉핥기 식의 다양한 지식 습득이 아닌 깊이 있는 지식 습득. 주변 상황 (기업 채용, 크루들의 취업 준비 등)에 휘둘리지 않고 꾸준히 학습에 집중하는 멘탈 관리. 나만의 철학 만들기.
• 꾸준히 성장하는 크루들은 어제의 나와 경쟁하면서 꾸준히 배움과 성장에 집중한다. 기존의 학습 방법, 틀을 빨리 깨트리는, 버릴 수 있는 용기를 가진 크루가 꾸준히 성장할 수 있다. 주변에도 이런 사람이 있는데 나도 오로지 내 성장에만 집중하는 사람이 되어야겠다. 어차피 시간 들이면 내가 더 잘한다는 마인드로!
• 뭔가 다 하는 것은 어렵지 않다. 그냥 하면 된다. 그렇지만 남들이 하고 있는데 나는 아직 할 준비가 되지 않아서, 부족하다고 생각해서 내 공부에 집중하는 것도 정말 중요하다. 그럴 수 있어야 한다. 그 길이 더 빠른 길이라는 믿음이 있어야 한다.
• 알고리즘... 나도 해야 하긴 하는데 나 또한 지금은 아닌 것 같다. 우테코에 들어오려고 했던 건 알고리즘을 하는 게 아니라 협업과 백엔드 경험을 하기 위해 들어왔기 때문에 알고리즘은 나중으로 미루는게 좋을 것 같다.

어떻게 살아야 할까

• 필요한 것은 권위에 도전할 수 있는 용기
• 권위에 도전하는 과정이 내가 진정 좋아하는 일, 잠재력을 찾는 과정
• 변화를 만들려고 할 때 가장 작은 것부터라도 시작해보기. 당연시 하던 학습 방법, 책을 읽는 방법 등 내가 변화를 만들 수 있는 가장 작은 시도부터 시작해보자. 하다가 안 되어 힘들 때는 주변 사람들을 활용하자. 주변 사람에게 위로와 에너지를 받아 다시 시도해보자. 또 안 되면 잠깐 쉬어도 괜찮다. 도전했다는 것 자체가 좋은 거다.
• 변화를 만들기 위해서는 의지력보다는 환경이 더 중요하다. 변화하기 좋은 환경을 만들자. 나도 우테코에 와서 생각보다 다른 사람과 이야기도 많이 하고, 나와 다른 사람을 일부러 만남으로써 다양한 관점으로 바라볼 수 있는 것 같다.
• 주변 환경을 정리해서 꾸준히 학습할 시간을 확보한다.
• 다른 사람의 경쟁/비교보다 어제의 나와 비교해서 성장했는지에 집중한다.

2/24

사다리 타기 피드백

접근 방식

• Out->In 접근 방식: 도메인 지식이 없거나 요구사항을 객체로 도출할 수 없는 경우. tdd 구현시 특정 상태를 분리해 시작하는 것이 중요하다. 작은 단위부터 tdd 시작하기.
• In->Out 접근 방식: 도메인 지식이 있거나 요구사항을 객체로 도출할 수 있는 경우. 가장 작은 단위의 객체(In)부터 기능을 추가하면서 Out 방식으로 완성해나간다. 그러나 시작 단계에서 가장 작은 단위의 객체를 찾는 것이 쉽지 않다.
• 둘 중에 하나만 사용하지는 않는다. 핑퐁하듯이 사용한다.
• 객체 설계 사이클: 테스트 실패 -> 테스트 성공 -> 리팩터링

객체 설계 방식

• Out -> In으로 시작한다. 도메인 지식으로 설계할 수 있는 부분까지 설계
• 요구사항을 분석한다. 도메인 설계에서 Object graph 중 가장 마지막 노드(의존성을 가지는 객체가 하나도 없는 객체)부터 구현을 시작하는 것이 TDD로 접근하기 수월하다.
• 요구사항 기반으로 객체를 도출한다.