[TIL 4] 실용주의 프로그래머 #4. 실용주의 편집증

오늘 TIL 3줄 요약

• 망치지 말고 멈춰라.
• 단정하지 말자.
• 적절한 곳에 예외를 사용하자.

TIL (Today I Learned)

2022.03.24

오늘 읽은 범위

4장. 실용주의 편집증

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

계약에 의한 설계

• 컴퓨터 시스템을 다루는 것은 어렵다. 사람 문제는 더 어렵다.
• 계약은 상대편은 물론 자신의 권리와 책임을 정의한다.
• 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈들의 권리와 책임을 문서화하는 데에 초점을 맞춘다.
• 만약 호출자가 루틴의 모든 선행조건을 충족한다면, 해당 루틴은 종료시 모든 후행조건과 불변식이 참이 될 것을 보증해야한다.

=> 함수를 선언할 때, 요구사항(매개변수)을 위반하지 않고(의도하지 않은 null을 보낸다던지) 호출하도록 하자. 함수는 호출하는 쪽이 의도한 대로 데이터를 가공하여 내려주어야 한다. 그리고 반드시 끝이 있어야 한다. 함수를 호출했는데 무한반복되면 얼마나 난감하겠는가.. 함수가 내부 로직을 처리하던 중, 비정상적인 종료를 하지 않았다면 다시 권한을 호출자에게 넘겨주자.

의미론적 불변적

• 어떤 종류의 실패가 발생하든 간에, 에러가 있다면 트랜잭션을 처리하지 않아야지, 트랜잭션을 중복 처리하면 안 된다는 말이다.
• 요구사항에서 직접 도출된 이런 간단한 법칙이 복잡한 에러 복구 시나리오를 해결하는 데에 큰 도움이 되는 것이 입증되었으며, 여러 분야에서 상세 설계와 구현에도 지침이 되었다.
• 불변식은 어떤 것의 바로 그 의미의 중심이 되어야 하며, 일시적인 정책(좀 더 동적인 비즈니스 법칙)에 영향을 받으면 안 된다.
• 오류 발생시 소비자의 입장을 우선하라.

=> 시스템에서 오류가 발생하면, 개발자의 입장에서 해당 문제를 수정하지 않고, 사용자의 입장에서 생각해보고 수정하자. 솔직히 나는 개발하고 배포한 기능에서 오류가 발생하면 사용자의 입장은 생각지 않고, 내가 더 편한 방법으로 문제를 수정하곤하였다. 하지만 그동안 얼마나 잘못된 행동을 해왔는지 느끼게 되었다. 내가 만든 프로그램을 사용하는 사용자가 없다면 나는 개발할 이유가 없는 것이다. 다시 한번 더 강조한다! 사용자가 없다면 내가 만든 프로그램은 죽은 것과 다름 없다.

망치지 말고 멈추라

• 가능한 한 빨리 문제를 발견하게 되면, 좀 더 일찍 시스템을 멈출 수 있다는 이득이 있다.
• 프로그램을 멈추는 것이 할 수 있는 최선일 때가 많다.
• 해제되지 않은 자원resource이 남아 있을 수도 있고, 로그 메시지를 기록할 필요가 있을 수도 있고, 열려있는 트랜잭션을 청소해야 하거나, 다른 프로세 스들과 상호작용해야 할 필요가 있을지도 모른다.
• 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.

=> 프로그램에서 문제가 발생했다. 문제가 발생한 부분을 찾기 위해 기존 코드를 들쑤시던 중, 원인을 발견하였다. 원인을 해결하기 위해서는 상당히 많은 부분을 고쳐야하고 그 부분을 고친다고 프로그램이 정상적으로 돌아갈 것이라는 확신도 없다. 확신 없이 고친 프로그램은 결국 다른 모듈까지 건드리며 문제를 일으킬 것이고, 그땐 정말 해결할 방법이 없을 수도 있다. 때론 과감하게 버리는 것도 하나의 방법이다. 내가 확신이 없다면 버리자. 어설프게 수정해서 더 큰 문제를 만들지 말구!

단정적 프로그래밍

• 이런 일은 절대 일어날 리 없어
• "하지만 물론 그건 절대 일어나지 않을거야"라는 생각이 든다면 그걸 확인하는 코드를 추가하라.
• 실행 되어야만 하는 코드는 절대 assert 속에 두지 마라.
• 여러분이 실행하는 코드가 죽어가는 몇 밀리세컨드의 시간 동안은 처음 단정 실패를 촉발케 한 잘못된 정보에 다른 코드가 의존하지 않도록 하라.
• 첫째 방어선은 모든 가능한 에러를 체크하는 것이고, 둘째는 놓친 것들을 잡아내기 위해 단정문을 쓰는 것이다.

=> "그래.. 이런 일이 나에게 발생할리가 없어..." 나도 많이 하는 생각이다. "내가 만든 프로그램이 그럴리가 없지.." 정말 잘못된 생각이다. 기능이 완성되면 테스트 코드를 작성한다. 테스트 코드가 정상적으로 작동한다. 문제가 없는것을 확인했으니, 배포하고 며칠이 지나자 내가 만든 기능에서 문제가 발생했다. 그렇다 예외케이스를 테스트하지 않고, 정상적인 상황만을 단정하여 테스트했던 것이다. 그 뒤로 나는 기능을 테스트할 때, 일어날 수 있는 모든 상황에 예외케이스까지 테스트한다. 역시 경험에서 배우나보다. 절대로 정상적인 상황만을 단정지어 테스트하지 말자. 우리의 프로그램은 비정상적인 세상속에서 돌아가고 있다.

언제 예외를 사용할까

• 예외를 정상적인 처리 과정의 일부로 사용하는 프로그램은 고전적인 스파게티 코드의 가독성 문제와 관리성 문제를 전부 떠안게된댜.
• 에러 처리기는 에러가 감지되었을 때 호출되는 루틴이다. 특정 부류의 에러를 처리하기 위해 어떤 루틴을 등록하게 된다. 해당하는 에러가 났을 때 그 치리기가 호출될 것이다.

=> 코드를 작성할 때, try/catch 블럭을 사용하면 확실히 가독성이 떨어진다. 관리하기도 힘들다. 처음 개발자로 일할 때 있었던 일이다. 프로그램이 작동하다가 특정 예외가 발생할 것이라 예상되는 기능마다 try/catch 블럭으로 떡칠을 해놓았었다. 그렇게 코드리뷰를 받으러 갔는데 "이게 뭐냐"며 많은 꾸지람을 들었다. 물론 그 경험으로 많이 배웠다. 부디 아무 곳이나 try/catch 블럭을 사용하지 말고, 필요한 곳에 넣자. 만약 실행중에 의도한 예외가 있다면 따로 처리하자.

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

해당 챕터는 과거에 프로그램에 문제가 발생했을 때, 어떻게 처리할지에 대해 고민한 내용을 정확하게 짚어 가려움을 긁어주었다. 예외를 다루는 마음가짐에 대해 다시 한번 생각하게 만드는 내용이었다. 조금만 더 빨리 이 책을 읽었더라면 지금보다 더 성장해있을텐데 하는 아쉬움도 밀려온다. 하지만 이제라도 이 책을 읽게 되었고 성장할 수 있는 계기를 얻었다. 감사하다.

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

죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이라고한다. 프로그램을 멈추고 난 다음에 멈춘 기능을 어떻게 해야할까? 탄탄하게 새로 작성해야할까? 기능 자체를 다른 방향으로 변경해야할까?