코딩을 지탱하는 기술

출처 : YES24

독서진행 : 65-84p (종이책) 

 

오늘의 메모

- 예외의 이점은 '실패를 놓치지 않는 것'이다. 예를 들어 배열의 범위 밖에 접근이 발생하면 언어 처리계는 예외를 던져서 실패를 프로그래머에게 보고한다.
- 범위 밖의 접근은 '이상 상태'이기 때문에, 적당한 값을 반환해서 이상 상태 선언을 연장한다고 해도 이상 상태를 해결하지 못한다.
- 검사 예외는 좋은 기능처럼 보이지만 잘 채용되고 있지 않다. 그 이유는 귀찮기 때문이다. 기술하는 예외의 개수가 너무 방대해지거나, 어떤 메서드에서 던질 예외를 하나 추가하면 그 메서드를 호출하고 있는 모든 메서드를 수정해야만 한다. 이렇듯 참 불편하다
- 어려운 개념이나 복잡한 시스템, 익숙하지 않은 분야를 한 번에 모두 이해하는 것은 어렵다. 우선은 작은 정보 단위로 잘라서 하나씩 씹어 자신의 것이 되도록 흡입해야 한다
- 방대한 정보 중에서 무엇을 선택하면 좋을까? 어떤 정보가 중요하고 어떤 정보가 중요하지 않을까? 중요한지  판단을 하기 위해서는 대상을 깊이 이해할 필요가 있다
- 이럴 때 사용할 수 있는 3가지 전략이 있다.
- 첫 번째 필요한 부분부터 흡수한다
- 두 번째 대략적인 부분을 잡아서 조금씩 상세화한다
- 세 번째 끝에서부터 차례대로 베껴간다
- 필요한 부분부터 흡수할 때 목적이 명확하고, 목적 달성을 위해서 어디를 읽어야 할지 알고 있다면 다른 페이지는 신경 쓰지 말고 바로 그곳을 읽도록 한다. 전체 모두를 읽지 않은 것이 께름칙한가? 하지만 좌절하고 전혀 읽지 않는 것보다는 낫다. '전부 읽지 않으면'이라는 완벽주의가 배우고자 하는 동기를 짓누르고 있다면 버려버리는 것이 낫다.

 

이번 예외 파트에서 진짜 공감되는 부분이 있었다

예외를 만들다 보니까 코드가 주객전도 된 에피소드이다

분명 만들고 싶었던 게 있었는데 그걸 잊고 예외처리 하다가

보니까 예외가 주인이 되어있었다

또, 버릇처럼 하던 예외가 막상 작은 프로젝트에서 하니까

오히려 제 역할을 하지 못했었다 

코드만 길어졌었고 지금도 유지하는데 다른 사람들이 유용하게 쓰지 못하고 있었다..

나만 쓰는 오류 예외 모음..?

 

나한테 완벽주의는 먼 존재만 같았는데 사실하는 것 보면

완벽을 추구하고 싶어 한다 이왕 하는 거 잘하고 싶으니까?

마음은 좋다 하지만 주춤거리고, 생각만 하고, 구상만 하고

기획만 하고, 설계만 하고, 실천은 저 나중에~~

근데 이렇게해서 결과물이 마냥 완벽하냐 묻는다면

아니 쉽게 마음에 드냐? 물으면 그건 또 아니다

체력이 남아도는 지 이상한데 체력 쓰고 있다