[실용주의 프로그래머]를 읽고 #9. 4장. 실용주의 편집증. Topic 23, 24

실용주의 프로그래머라는 책을 읽으며, 삼색볼펜 독서법을 적용. 줄 친 내용에 대한 단상을 정리합니다.
삼색볼펜 스터디란? 책에서 중요하다고 생각되는 문장을 빨강 > 파랑 > 검정 순으로 줄을 치며 공부하는 방식.
🔴 가장 중요한 문장
🔵 그래도 꽤 중요한 문장
⚫ 그럭저럭 내 마음에 와닿은 문장
🤔 짧은 생각 (단상은 단상일뿐!!)
볼드체 중요한 문장은 아니지만 단락 구분 표시

---

4장. 실용주의 편집증
🔴 여러분은 완벽한 소프트웨어를 만들 수 없다.
🤔 묘하게 위안이 되는 문장. 완벽해보일수는 있어도 아직 문제가 발생하지 않았을 가능성이 높은게 이쪽 분야인듯 하다.

⚫ 우리는 문제가 생기기 전에 주의하고, 일어나지 않을 법한 일에 대비하며, 절대 자신을 모면하기 힘든 곤경으로 몰아넣지 않는다.
🤔 방어운전에 대한 이야기이지만, 코딩에도 적용된다. 이 장의 제목처럼, 때론 편집증환자나 강박증 환자처럼 매달려야할 떄가 있다.

🔴 실용주의 프로그래머는 자기 자신 역시 믿지 않는다.
🤔 오! 좋다! 난 나를 믿지 못한다. 

⚫ 우디 앨런이 말했듯이 “모든 사람이 실제로 당신을 잡으려고 한다면, 편집증도 좋은 생각이다.”
🤔 뭐 일상을 매분 매초 편집증으로 살면 상당히 피곤하겠지만…소프트웨어개발을 할때 편집증으로 생각하면 (역시 피곤하겠지만) 무슨 일이 닥쳤을 때 다행이라고 생각될 수 있다. 실제로 그런 경험도 몇 번 겪기도 했고…

Topic 23. 제약에 의한 설계
DBC(Design By Contract)
🔵 정확한 프로그램이란 무엇인가? 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램이다. 이 주장을 문서화하고 검증하는 것이 ‘계약에 의한 설계’의 핵심이다.
🤔 말이 거창하긴 한데…함수가 되었건 메소드가 되었건, 모듈이 되었건, 미리 약속한 바와 기대하는 바를 제공해야 한다는 의미. 그 약속한 내용을 되도록 명문화하여 증거로 남길 필요도 있는 것으로 보인다. 하지만 이 토픽에서 설명하는 DBC가 잘 이해가 가지는 않는다…내가 익숙한 언어는 자바나 코틀린이라 낯설어서 그럴까

- 선행 조건
  - ⚫ 루틴이 호출되기 위해 참이어야 하는 것. 즉, 루틴의 요구사항이다.
  - 🤔 루틴을 함수라 치면, 파라미터로 들어오는 값들에 대한 기본적인 검증이 필요한 것으로 이해했다.
- 후행 조건
  - ⚫ 루틴이 자기가 할 것이라고 보장하는 것. 즉, 루틴이 완료되었을 때 세상의 상태다.
  - 🤔 루틴을 함수라 치면, 기대하는 결과를 보장해야한다는 걸로 이해했다.
- 클래스 불변식
  - ⚫ 호출자의 입장에서 볼 때는 이 조건이 언제나 참인 것을 클래스가 보장한다.
  - 🤔 이게 무슨 소린지 이해가 잘 안간다…음…클래스가 내가 아는 그 클래스가 맞다면, 클래스가 가지고 있는 상태들은 불변하다는 걸 보장하는걸로 이해했다. 불변 객체 그런 느낌일지…

🔴 만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이 되는 것을 보장한다.
🤔 위 3가지 조건을 만족한다면 DBC에 규합한다고 할 수 있다. 읽다보니, DBC는 일종의 책임과 역할을 분명하게 하는 설계 기법이 아닐까 싶었다. 선행, 후행조건과 클래스 자체가 어떤 책임과 역할을 할 것 인지 믿고 간다는 느낌..?

⚫ 무슨 일이 벌어지든지 확실한 점은 계약에 부응하지 못하는 것은 버그라는 것이다.
🤔 너무나 책임이 분명하고 엄중하기 때문에, 그냥 선행조건에서 놓친 검증을 다른 곳에서 하는 것도 버그라고 하는 것 같다. 법치주의 같은 느낌이다.

클래스 불변식과 함수형 언어
⚫ 이 용어가 진짜로 의미하는 것은 상태다.
🤔 오 다행히 내가 이해한게 맞았나보다. 상태를 유지할것..!!

DBC와 테스트 주도 개발
⚫ DBC와 테스트는 프로그램의 정확성이라는 보다 넓은 주제에 속하는 서로 다른 접근 방법이다.
🤔 TDD는 그야말로 개발 방법론이고, DBC는 설계 기법이라 동일한 목적을 가진, 서로 다른 결의 수단이라고 생각된다.

⚫ TDD는 멋진 기법이다. 하지만 다른 많은 기법과 마찬가지로 ‘정상 경로’에만 집중하도록 유도하기도 한다. 그러나 바깥세상은 나쁜 데이터와 나쁜 사람들, 나쁜 버전, 나쁜 명세로 가득차 있다.
🤔 TDD에 매료되서 한창 시도하던 때가 있었다. 하지만 아무리 테스트 커버리지를 높인다고해서, 잠재된 버그가 없어지진 않았다. 도메인 지식에 해박한 내가, 지금 당장 100% 커버리지를 자랑하는 테스트코드를 잔뜩 짜며 TDD로 돌린다고 하더라도, 미래의 누군가가 외부 의존성과 관련된 기능을 새로 구현하다 보면 예상치 못한 런타임에러가 발생하기 마련인니까. 

DBC 구현
⚫ 코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹시 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다.
🤔 입력값의 검증을 하면 좋기야 한데…이런 저런 핑계로 잘 안하는게 현실이기 하다. 경계조건 또한 그냥 믿고 가거나 테스트코드로 검증하는 정도이고… 대신 전달 및 반환하는 것에 대한 주석은 넣기 시작했다. 특히 인터페이스의 경우엔!

🔵 DBC는 결국 설계 기법이다.
🤔 DBC를 직접적으로 지원하는 언어도 있나보다. 그렇지 않은 언어를 주로 사용한다고 제쳐두지 말고 어떻게 이 설계방식을 써먹을 수 있을지 고려해봐야겠다.

누구의 책임인가?
⚫ DBC 지원을 내장하지 않은 언어에서는 계약을 검사하는 단정문으로 호출되는 루틴 앞뒤를 감싸줘야 할 것이다.
🤔 네 알겠습니다.

 

🔴 의미론적 불변식은 무언가가 품은 진짜 의미의 중심이 되어야 하며, 훨씬 역동적으로 변하는 비즈니스 규칙처럼 일시적인 정책에 영향을 받으면 안 된다. 
🤔 단순히 비즈니스적인 요구사향말고 정말 본질적으로 의미를 가져서 천지개벽하지 않는 이상 변하지 않을 것들만 불변하다고 가정해야 한다. 가령,

 

⚫ 오류 발생 시 소비자의 입장을 우선하라.
🤔 이런거. 이건 베짱장사가 아닌바에야 대부분 소프트웨어가 따라야할 조치이다.

 

Topic 24. 죽은 프로그램은 거짓말을 하지 않는다
⚫ 우리 프로그램에서 뭔가가 잘못되기 시작했는데 그걸 먼저 잡아내는 것은 라이브러리나 프레임워크의 루틴인 경우가 종종 있다.
🤔 우리는 이상적인 케이스에 대해서만 테스트하고 다른 일은 일어날 수가 없거나, 일어날 확률이 적으니 그때 가서 생각하자고 곧잘 말하곤 한다. 물론 일어날 확률이 적은 문제에 지나친 관심을 쏟는 것도 그리 현명한 선택이 아닐지 모르나, 이 주제의 핵심은 시스템은 거짓말 하지 않는 다는 것!!

🔴 ‘그런 일은 절대 일어날 리 없어.’라는 사고에 빠지기 쉽다.
🤔 ‘이상하다’, ‘그럴 일 없다.’, ‘도대체 이유를 모르겠다.’라고 말 할때가 종종 있다. 이리 저리 검색도 해보고 AI에도 물어봐도 도통 모를 때가 있는 데…보통 그런 경우 해답은 의외로 가장 간단한 부분, 특히 첫 단추를 잘못 꿰멘 경우가 많았다. 그래. 시스템은 거짓말 하지 않아.

🔵 일단 그놈의 오류 메시지 좀 읽어라.
🤔 넵…

잡은 후 그냥 놓아주는 것은 물고기뿐
🔴 일찍 작동을 멈춰라.
🤔 예외가 발생했을 때 그 예외를 전파해서, 어떻게든 세세한 로그를 각 분기별로 남기려는…시도를 하기보단 그냥 문제가 발생한 지점에서 에러를 발생시키는게 낫다는 문장. 물론 비즈니스 상에서 오류를 추적하기 위해서 세세한 로그가 도움이 될 수는 있지만, 그만큼 코드가 오염될 수 있으니 적절한 밸런스 추구가 필요하다. 아예 코드에서는 작동을 멈추고 추상화한 영역에서 예외를 잡아 처리하는 게 나을지도.

망치지 말고 멈춰라.
🔵 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다.
🤔 괜히 질질 끌지말고 확실하게 잘못했다!! 하고 퇴장할 수 있는 프로그램을 만들자.

 

실용주의 프로그래머(20주년 기념판)

《실용주의 프로그래머》는 당신이 읽고, 또 읽고, 수년간 또다시 읽게 될 몇 안 되는 기술 서적이다. 당신이 이 분야에 처음 발을 디딘 사람이건, 경험 많은 전문가이건 매번 새로운 통찰을 얻게 될 것이다. 데이비드 토머스와 앤드류 헌트는 소프트웨어 산업에 큰 영향을 미친 이 책의 1판을 1999년에 썼다. 고객들이 더 나은 소프트웨어를 만들고 코딩의 기쁨을 재발견하도록 돕기 위해서였다. 이 책의 가르침 덕분에 한 세대에 걸친 프로그래머들이 어떤 언어

저자

데이비드 토머스, 앤드류 헌트

출판

인사이트

출판일

2022.02.24