이번에 회사에서 빌려 읽게된 이 책의 내용과 나의생각(🍏)을 정리해보려 한다.
20주년 기념판으로 현재 시대의 맞게 리뉴얼 된 것이 많다 한다. 테세우스의 배라고 언급한 점이 재미있다.

서문

실용주의 프로그래머는 어떤 사람일까

• 얼리 어댑터 또는 새로운 것에 빨리 적응하는 사람
• 호기심 많은 사람
• 비판적인 사고의 소유자
• 현실주의자
• 다방면에 능숙한 사람

라고 언급하고 있다. 요런 방면으로 사고할 수 있어야 오래오래 프로그래머로 살아갈 수 있을것 같다.
나는 아직 부족한 점이 눈에 띄는데 요런 방향으로 익숙해질 수 있도록 의식적으로 생각하며 부단히 노력해야한다.

• 자신의 기예(craft) 에 관심을 가져라
• 자기 일에 대해 생각하라. (IBM 의 표어 '생각하라!')
  • 항상 무엇을 하고 있는지 생각하고 비판적으로 평가해야한다.
  • 언제나 생각하고 자기 일을 비평하자.

🍏 카이젠은 오늘 읽은 짧은 글과 맞물리는 부분이 있다. 윗몸일으키기를 한다고 생각하자. 힘든 순간을 이겨내야 다음에는 더 익숙하게 해낼 수 있다. 그리고 생각해야한다. 무엇을 하고 있는지 왜 안되는지. 무엇이 문제인지.
개선할 수 있는 것이 발견되면 천천히 하나씩 개선해나가야 한다.

단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다.
프로젝트의 전체 구조 속에는 언제나 개성과 장인 정신을 발휘할 여지가 있다.

1.실용주의 철학

• 자신의 인생이다. 직접 환경을 바꾼다.
  • 당신에게는 에이전시가 있다. 스스로의 행동을 직접 결정할 수 있는 힘이 있다.
  • 기술이 뒤쳐진다면 여가 시간을 쪼개 재미있어 보이는 것을 공부해야한다.
  • 자신에게 투자해라.
• 자신이 하는 모든 일에 책임을 진다.
  • 실수나 무지 같은 단점도 인정해야한다.
  • 인정하고 해결책을 찾자.
  • 부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.
• 프로젝트가 방치된 채로 끝나는 것을 보고만 있지 않는다.
  • 엔트로피 (시스템 내의 무질서한 정도) 증가 -> 소프트웨어의 부패
  • 깨진 창문, 낙서 등을 방치하지 말자. 발견하자마자 바로 고쳐라.
  • 고칠 시간이 없다면 일다 판자로 덮는 것만이라도 하자.. '아직 구현되지 않았음...'
  • 엔트로피가 우리를 지배하도록 내버려 두지 말자.
  • 아무도 주의를 기울이지 않는다면 엔트로피에 점철되고만다.주변을 살피고 의식하는 습관을 들여라
• 변화를 부추기는 전략.
  • 시작 피로(start-up fatigue) 로 자신의 자원을 지키려고 하는 경향이 있다.
  • 이룬것을 보여주고 놀라게 한 후 더 필요한 것을 말하라.
• 넓은 기반 지식과 경험을 가진다.
  • 새로운 것을 배우는 능력은 가장 중요한 전략 자산이다.
  • 성공적인 경력을 위해서 지식 포트폴리오에 투자해야 한다.
  • 여러 가지를 알수록 자신의 가치는 더욱 높아진다. 많은 기술에 익숙하다면 변화에 더 잘 적응할 수 있다.
• 끊임없이 계속 배워야 한다.
  • 매년 새로운 언어를 최소 하나는 배워라. 다른 언어는 동일한 문제를 다르게 푼다.
  • 몇 가지 서로 다른 접근법을 알면 사고를 확장할 수 있다.
  • 기술 서적을 한달에 한 권씩 읽어라. 깊이 있는 지식은 긴 글 형식의 책을 읽어야 한다.
  • 기술 서적이 아닌 책도 읽어라. Soft 스킬을 익히자.
  • 수업을 들어라. 지역 사용자 단체나 모임에 참여하라. 다른 환경에서 실험해 보라. 요즘 흐름을 놓치지 말라.
  • 답을 모른다면 알아봐라.
• 비판적 사고
  • 왜냐고 다섯 번 묻기.
  • 누구에게 이익이 되나?
  • 어떤 맥락인가?
  • 언제 혹은 어디서 효과가 있을까?
  • 왜 이것이 문제인가?
• 타인과 상호 작용하며 보낸다.
  • 뭘 가졌느냐 만이 아니라 어떻게 포장하느냐도 중요하다.
  • 소통하며 청중에 대한 지식을 쌓아 나가라.
  • 말하고 싶은 게 무언지 알라, 말하기 적절한 때를 골라라, 전달하는 스타일을 조정하라. 멋져 보이게 하라
  • 청중을 참여시켜라, 경청하라, 응답하라, 문서화(코드와 문서를 함께 둬라.)
  • 소통을 돕는 서적: <<맨먼스 미신>>, <<피플웨어>>
  • 작업 환경으로 갖고 오는 감정적 태도를 논의 하는 서적: <<파충류의 뇌: 일터에서 만나는 곤란한 사람 상대하기>>

🍏 끊임없이 배우고 비판적으로 바라보아라. 항상 보게 되는 문장이지만 참 실천하기 쉽지않다. 상대적으로 소통능력 보다는 자신에 투자하여 넓은 지식과 경험을 가지는 것에 주의를 기울여야겠다.
내 주변의 것들 내가 하고 있는 것에 호기심을 가지고 깊게 살펴볼 수 있는 연습을 하겠다.

2.실용주의 접근법

좋은 설계의 핵심

좋은 설계?

• 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.(ETC: Easier to Change)
• 결합도를 줄인다. 응집도는 높인다. 이름을 잘 잣는다.
• 스스로 묻는다. 파일을 저장할 때마다 물어보라. 테스트할 때도, 버그를 수정할 때도.

  내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?

• 파일 저장할 때 특정 명령을 실행하게 하여 ETC? 묻도록 설정하라..!

DRY 원칙을 따르자

• DRY: Don't Repeat Yourself! 반복하지 말라
• 필자는 '실용주의 프로그래머' 의 툴박스 중 가장 중요한 툴 중 하나라고 한다.
• 지식의 중복, 의도의 중복에 대한 것. 똑같은 개념을 다른 곳에서 표현하면 안 된다는 것.

  • 어떻게 판단하나?
    • 하나를 바꿔야 할 때 여러 곳을 바꾸고 있나?
    • 코드도 바꾸고 문서도 바꾸는가? 데이터베이스 스키마와 스키마를 담고 있는 구조 등도?
    • 그렇다면 DRY 하지 않다.

• 코드의 중복
  • 말 그대로 같은 의도의 코드가 여러번 반복되는 것 -> 공통된 함수를 만든다.
• 의도의 중복
  • 의미를 담은 코드에 주석을 추가한 것. 코드를 수정하면 주석도 수정해야함.
  • 함수 이름에 정확한 의미를 담으면 주석을 따로 추가하지 않아도 된다.
• 데이터의 중복
  • Point Start, End 가지고 Lenght 도 따로 캐싱하여 사용하는 경우
  • 모듈을 통해 제공되는 모든 서비스는 일관된 표기법으로 사용할 수 있어야 한다.저장한 값으로 구현되었건, 계산을 통해 구현되었건 상관없이.
• 표현상의 중복
  • 내부/외부 코드 에서의 정보 중복
  • API 정의를 중앙 저장소에 넣어두자. 공개 API 를 불러와서 사용하자.
• 개발자 간의 중복
  • 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다.

직교성 Orthogonality

독립적임을 말함. 결합도 줄이기를 의미.

• 잘 설계된 시스템에서는 데이터베이스 코드가 사용자 인터페이스와 서로 직교할 것.

비직교적인 시스템

• 본질적으로 변경과 조정이 더 복잡하다.

직교적인 시스템

• 우리가 설계하려는 것은 자족적(self-containe) 컴포넌트
• 컴포넌트가 각기 격리되어있어면 다른 것들에 가는 영향을 걱정하지 않아도 된다.
• 생산성 향상과 리스크 감소라는 장점이 있다.
• 직교적으로 설계된 시스템은 테스트하기 더 쉽다.

직교함을 확인하는 방법

• 특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?
• 직교적인 시스템에서는 답이 '하나' 이어야함.

툴킷이나 라이브러리를 도입할 때

• 직교성을 해치지 않는지 주의 깊게 살펴보라.
• 직교성을 만족한다면, 미래에 라이브러리가 변경될 때를 대비할 수 있다.

코드의 직교성을 유지하는 기법

• 코드의 결합도를 줄여라
  • shy 코드를 작성하라. 다른 모듈의 구현에 의존하지 않는 코드를 작성하라.
• 전역 데이터를 피하라
  • 싱글턴은 불필요한 결합을 만들 수 있다.

자신이 작성한 코드를 항상 비판적으로 바라보는 습관을 길러라.
기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라. (리팩터링)

테스트

• 수정하고 나니 모든 것이 제대로 고쳐졌는가
• 생각지 못한 곳에서 새로 문제가 발생하는가
• 월 단위로 수정한 소스파일의 경향을 파악하여 리포트를 만들어볼 수도 있다.

직교적으로 살아가기

• DRY(Don't Repeat Yourself!)원칙으로 무장하고 직교성 원칙을 충실히 적용하면 더 유연하고 이해하기 쉬운 시스템이 될 것이다.

가역성

언제나 변화의 가능성은 존재한다.

• 데이터베이스를 추가하더라도, 올바르게 추상화하여 영속성을 제공하도록 만들었다면 도중에 데이터베이스를 변경할 수 있는 유연성이 생기는 것이다.
• 외부의 API 를 만들어놓은 추상화 계층 뒤로 숨겨라.

유행을 쫓지 말라

• 어떤 미래가 펼쳐질지 알 수 없다.
• 슈뢰딩거의 고양이에 빗대며 어떤 결과가 일어나기 전에 경우에 수 마다 우주가 복제된다. 당신의 코드는 몇 가지 가능한 미래를 지원할 수 있는가?

🍏 허 참 재미있는 책이다. 계속해서 말하려고 하는 점은 동일해보이긴 하다.
유연성 있는 코드를 만들어라! 예상하지 못하는 미래에 쉽게 대응할 수 있도록 만들어라! 요건 것 같다.
항상 교체될 수 있음. 가정하고 있던 전제가 변경될 수 있음에 주의해야한다.
ETC, DRY 를 마음에 새겨넣자.

실용주의 프로그래머는 소프트웨어 판 예광탄을 선호한다.

• 예광탄(발사 이전의 테스트)은 상대적으로 비용이 적게 드는 방법이다.
• 시스템을 정의하는 중요한 요구 사항을 찾고, 의문이 드는 부분, 위험이 커 보이는 곳을 찾아라.

예광탄(Tracer bullet)이란?

• 프로그래밍 언어를 배울때는 "Hello World" 를 출력하는 코드를 컴파일/실행하는 것
• 어떤 계층을 연결하려면 가장 쉬운 기능을 통합해봐라.단, 한번쓰고 버릴 코드가 아니라 계속 사용할 코드!!!
• 그 이후에 구조에 살을 붙여가며 만들어나가라.
• 장점
  • 사용자가 뭔가 작동하는 것을 일찍 보게 된다. 진행되고 있음을 보여줄 수 있다.
  • 개발자가 들어가서 일할 수 있는 구조를 얻는다. 채워넣으면 된다.
  • 통합작업을 수행할 기반이 생긴다.
  • 보여줄 것이 생긴다.
  • 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.
• 단, 예광탄이 언제나 목표물을 맞히는 것은 아니다.
• 프로토타이핑과의 차이점?
  • 프로토타이핑을 개념 실험을 위해 구현한 것이므로 대부분 버려진다.
  • 프로토타이핑은 대부분 UI 구현이 우선시된다.

도메인 언어

• RSpec: 테스트 라이브러리, 현대 언어와 유사
• 큐컴버: 테스트 방식을 읽을 수 있도록 표현한 것.
• 피닉스 라우터:
• 앤서블: 소프트웨어를 설정.
  => RSpec, 피닉스는 컴파일/실행 가능. 실행시키는 코드 안으로 들어감(내부 언어)
  => 큐컴버, 앤서블은 자체 언어를 사용, 별도의 코드가 이 언어를 읽어 사용할 수 있는 형태로 바꿔야함.(외부 언어)

🍏 도메인 언어? 호스트언어?

• 도메인 특화 언어 (DSL)
  • 비능통한 비 프로그래머가 사용하도록 제작되는 언어.프로그래머와 해당 분야의 전문가를 원활하게 연결.
  • 소형 언어라고 불리기도 한다.
  • 블루프린트도 여기에 속하는 것 같다.
  • GPL과 DSL 분리 방식
    • GPL 과 분리한 외부 DSL (e.g. SQL)
    • 동일한 프로그램 파일에 혼합하는 방식 -> 긴밀한 통합 가능.
  • MPS(Meta Programming System)는 무엇인가?
    • DSL 을 설계하기 위해 사용. Jetbrain 에서 만들어짐.
• 범용 언어 (GPL)

추정치

• 추정치는 이미 그 일 또는 비슷한 경험을 해본 사람에게 조언을 구해라.
• 추정치에 조건을 더해라. "다른 복수의 업무가 없고.. 통합에 문제가 없다면.. 3달이 걸릴 것 같습니다."
• 간략한 모델을 만들어서 요구사항에 부합하는지 확인한다.
  • 다 만든 모델을 컴포넌트 단위로 나누어 추정한다.
• 추정치는 회고를 통해 왜 추정치에 도달하지 못했을지 파악을 한다.
  • 50% 이상의 오차가 생겼을 경우..

프로젝트 일정 정히기

• PERT(Program Evaluation Review Technique) 추정치
  • 낙관적 추정치, 가능성 높은 추정치, 비관적 추정치를 가짐.
• 비교적 정확한 일정을 정하는 데에는 프로젝트를 경험해보는 수밖에 없다..
• 코끼리를 먹는 방법: 한 번에 한 입씩 먹는다!
  • 요구사항 확인 후 위험도가 높은 부분부터 개발을 한다.
  • 개발을 하며 반복 주기가 얼마나 필요할 지 가늠할 수 있다.
  • 요 부분은 프로젝트에 대한 대략적인 일정이 필요하다면 선호하지 않을 수 있으나, 팀의 생산성, 환경이 일정을 결정한다는 사실을 이해시켜야 한다.
  • 알려달라 하면 "나중에 알려드릴게요." 라고 말한다.허투로 말한 추정치는 여러분에게 해를 끼칠 것이다..!!!

🍏 일정과 관련된 추정치 판단은 회사에서 업무를 진행하며 참 어려움을 겪었던 부분이다.
연간 목표 설정을 위해 예상은 하게 되지만, 항상 엇나가는 부분이 있기에 점점 예측할 수 없어지곤 했다.
"코끼리를 먹는 방법" 이 부분이 참 현실적인 것 같다. 우선 시작해보고 정한다... 항상 연간 목표를 잡는것은 불가피하지만, 이 방법을 수행할 수 있는 과제도 있을 것 같기도 하다. 숙고해봐야할 것 같다.

3.기본 도구

목수처럼

• 자신의 도구 상자에 주기적으로 뭔가를 추가하게 될 것이라 예상하라.
• 일을 하는 데에 더 나은 방법이 없는지 살펴라
• 사용하던 도구로 해결할 수 없다면, 도움될만한 다른 것이나 강력한 것을 찾아보아야 한다는 것을 명심하라.
• 필요에 따라 도구를 취하도록 하다.

텍스트 에디터

• 메모와 같은 개인 자료도 버전 관리를 해라.
• 데이터를 저장할 때 텍스트로 저장되면 다양한 이점이 존재한다.
  • 복구의 용이성
  • 더 쉬운 테스트
  • diff, checksum 의 용이성
  • 다양한 시스템에서의 공통 표준이 될 수 있다.
  • 하지만 uasset 은 암호화되어있...

셸 Shell

• 텍스트 파일을 다루는 프로그래머의 작업대!
• 자주 수행하는 작업을 수행하는 매크로 명령도 만들 수 있죠
• GUI(WISIWYG) 의 단점은 보는 것으로만 얻을 수 있다.
• 셸에 익숙해지면 오르는 생산성을 보며 깜짝 놀라게 될 것이다.
• 자신만의 셸 만들기
  • 색깔 조합: 아주 중요하죠
  • 프롬프트 설정: 원하는 정보를 보여줄 수 있도록 설정할 수 있다.
  • 별칭: 자주 사용하나 헷갈리는 부분은 별칭을 만들어 사용. 위험한 명령어에 확인을 추가할 수도 있다.
  • 자동 완성: Tab 키를 이용하여 자동 완성 하라.
• 평소 GUI에서 수동으로 하는 작업이 있다면, Shell 을 사용하여 자동화 해보라!

에디터

• 에디터 사용에 능숙해져라.
• 유창하다는 것? 요것들을 모두 마우스, 트랙패드 없이 수행하는 것.
  • 텍스트 편집시 문자, 단어, 줄 단위로 커서 이동, 내용 선택, 그 단위로 삭제.
  • 코드 편집 시 반대 괄호로 이동, 함수 모듈 단위로 커서 이동
  • 코드의 들여쓰기 자동으로
  • 단축키로 주석 처리
  • 실행취소, 재실행
  • 에디터를 여러 구역으로 쪼개고 이동하라
  • 특정 줄 번호로 이동
  • 여러 줄 선택 후 가나다라 순으로 정렬
  • 문자열, 정규표현식으로 검색
  • 여러 커서를 만들어서 동시에 여러 곳의 텍스트 편집
  • 컴파일 오류 표시
  • 테스트 실행
• 유창해지기
  • 다 외우는 것은 쉽지 않다. 내가 에디터를 사용하는 모습을 관찰하라.
  • 분명 더 나은 방법이 있을 텐데.. 생가갛는 습관을 들여라.
  • 유능한 기능을 발견하면 몸이 기억하게 만들어라.
  • 잠시 트랙패드/마우스를 사용하지 않는 기간을 가져봐라.
• 에디터 확장
  • 에디터 확장을 위한 언어를 확인하여 반복적인 일을 자동화할 방법을 연구해라.

VCS

• 실수를 되돌리는 것만으로 큰 역할을 한다.(가역성)
• 그 외에도 다양한 기능을 할 수 있다.
  • 코드를 변경한 작업자 확인
  • 이번 릴리즈에 코드가 몇 줄이나 바뀌었는지 확인 가능
  • 어떤 파일이 자주 수정되는지.
  • 버그 추적, audit, 성능 관리, 품질 관리에 귀중함.
• 코드 뿐아니라 일상생활에서 사용하는 Shell, 텍스트, makefile, 에디터 설정, 책의 원고까지도 버전관리를 해라!!
• 브랜치 활용하기
  • 다른 브랜치에서 다른 작업을 할 수 있음
  • 브랜치는 프로젝트의 작은 복사본
• 응용하기
  -PC에 설치한 프로그램, 시스템 설정 등을 텍스트 파일로 표현하여 저장해두어 언제든 복구할 수 있도록 준비해보자
  

🍏 이번 단원에서 좀 본브레이킹을 당한 것 같다. IDE 나 텍스트 에디터를 단축키로만 사용하고 싶다는 마음은 있었으나, 항상 마우스를 사용하고 있었던 본인이다. 되도록 마우스나 트랙패드를 사용하지 않고 사용하도록 의식적으로 노력하겠다.
그리고 VCS 를 프로젝트에 많이 적용해보았지만, 개인적인 설정이나 메모를 관리하는데에는 활용해볼 생각조차 하고 있지 않았기에 좀 느끼는 바가 많았다. 항상 작업을 할 때 생각 정리를 위해 메모장을 열어 적곤 하는데 그 내용을 쌓아두면 그날 어떤 생각을 했는지 어떤 작업을 했는지 쌓아보기 좋을 것 같다.
이전의 내용과 좀 결합을 해보면, 의식적으로 기입하거나 정기적으로 입력을 받아 텍스트를 작성하고 하루의 특정 시간(아마 마무리가 되었을 새벽 4~5시 즈음)에 특정 자동화 스크립트를 실행하여 하루의 생각과 작업을 저장해보면 어떨까 한다. 그러면 업무 보고를 작성하는데도 더 적은 시간이 들 것으로 예상한다. 개인적으로 진행해봐야지 ㅎㅅㅎ

디버깅

'버그' 라는 단어는 14세기 이래 '공포의 대상'을 지칭하는 단어로 사용되어왔다

• 디버깅 심리
  • 비난대신 문제를 해결하는 데에 집중하라.
  • 디버깅 제1 법칙: 당황하지 마라
  • 항상 문제의 근본 원인을 찾으려노력하라.
• 실마리 찾기
  • 항상 빌드가 깨끗하게 되는지 확인하라. 컴파일러 경고 수준을 최고 높게!
  • 재현이 안될 때는 직접 테스터의 자리에 찾아가서 어떻게 했을 때 오류가 발생하는지 확인해봐야할 수도 있다.
• 디버깅 전략
  • 버그 재현하기
  • Read the damn error message.
  • 호출스택을 이동하여 변수가 어떻게 변화하는지 따라가라.
  • 특정데이터셋에서 문제가 발생한다면, 이진 분할(O(logn))을 활용하여 어떤 입력값이 범인인지 찾아내라.
  • 릴리즈에서 문제가 발생한다?, 커밋이 만개 정도있다? -> 바이너리 서치로 추적한다.
  • (java)스택 트레이스 확인: 여기에 어떻게 도달했는지 말해준다
  • 누군가에게 문제를 설명하는 방법
    • 단순하지만 꽤 유용한 방법!
    • 혼자 볼 때는 당연히 여기고 지나가는 것을 명시적으로 설명하다보니 새로운 통찰을 얻을 수 있는 것
    • 사람이 아니어도 된다 😆
  • 외부 제품에 버그가 있을 수도 있다.유닉스의 select 시스템콜에 문제가 있는 경우도 있었다.
  • 실패에 직면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들이고 증명하라.
    • 누군가의 잘못된 가정으로 발생한 버그라면, 팀 내에 공유/토론하자.
• 디버깅 체크 리스트
  • 보고된 문제가 직접적 결과인가 단순 증상인가
  • 버그가 어디에 존재하는가 (프레임워크? OS? 당신의 코드?)
  • 이 문제를 동료에게 어떻게 설명하겠는가?
  • 이 데이터로 테스트하면 무슨 일이 생기는가?
  • 이 버그를 야기한 조건이 다른 곳에도 존재하는가?

엔지니어링 일지

• 이야기 하는 도중 끄적이는 그것.
• 기억보다 더 믿을 만 하다.
• 진행중인 작업과 직접적 관계가 없어도 쌓아놓을 수 있는 곳이 생긴다.
• 무언가를 쓰면서 생각 정리가 된다.
• 수년 전에 어떤 생각을 하고 있었는지 돌아볼 수 있다.
• 유명해졌을 때 회고록을 쓰는 데 도움이 될 수 있다 😆

🍏 최근에 회사 내부 컨퍼런스에서 디버깅 관련 세션을 들었었는데, 거기에서 이야기 하던 내용들이 몇가지 공통적으로 나온 것 같다. 그리고 경험적으로 체감했던 이야기들도 있어서 공감이 많이 갔던것 같다. 분명한 것은 디버깅 즉 문제의 원인을 찾을 때 똑똑하게 들여다봐야한다는 것. 무엇이 잘못일지 어디서부터 잘못이 발생했을지 생각을 계속해서 해야한다.
엔지니어링 일지 부분은 내가 정말 공감하는 부분이고 항상 하고 있기도 하다. 회의나 강연을 들으면 계속해서 강연 내용이나 새로운 정보, 나의 생각 등 무언가 적어내린다. 뭔가 이 책에서 인정을 받은 것 같다. 계속해서 잘 써봐야겠다.

4.실용주의 편집증

삶의 공리.. 누구든 완벽한 소프트웨어를 만들 수 없다. 하지만 대비해야한다.

우리가 방어운전을 하는 이유..! 일어나지 않을 법한 일에 대비한다.

• 알 수 없는 입력들..
• 기대에 미치지 못하는 다른 사람들의 코드...

방어적 코딩의 예

• 단정(Assertion), 불신, 제약
• 자기 자신도 믿지 않는다.
  => 가정을 적극적으로 검증하는 코드를 작성해야한다.

계약에 의한 설계 (DBC: Design By Contract)

• 정직한 거래를 보장하는 방법. 계약.
• 정확한 프로그램: 자신이 하는 일 보다 적지도 많지도 않게 하는 프로그램.
• 계약
  • 선행 조건: 루틴 호출 이전에 참이어야 하는 것(요구사항)
  • 후행 조건: 루틴 완료 시 세상의 상태.
  • 클래스 불변식: 이 조건이 언제나 참이어야함. (루틴 이전/이후에는)
• 계약을 어기면? 예외, 종료 등 해결방법이 실행됨.

DBC 어떻게 할까

• Lazy 코드를 작성하자
  • 시작하기 전에 엄격하게 확인하고 약속하는 것.
• DBC 구현
  • 유효한 입력 범위, 경계조건, 루틴의 결과의 약속, 약속하지 않는 것 등을 나열한다
  • 주석이나 테스트로 넣어서 검사하도록 해도 좋다.
• 모든 오류는 정보를 준다. 절대 일어날일 없다고 무시하지 말아라.
• 문제를 발견하면 좀 더 일찍 시스템을 멈추는 것이 낫다.
• 기만하지 말아라. 리눅스에서 사용될 일은 절대 없을 텐데 뭐하러..? 이러지 말라는 소리
• 단정문으로 불가능한 상황을 예방하라
  • assert(result != null); // assert 에 대한 설명이 추가되면 더 좋다.
  • 단 오류로 처리해야하는 곳에서 assert 를 사용하지 말아라 바로 오류처리해라.
  • assertion 은 코드를 느리게 한다..하지만 성능 문제가 있더라도 정말 문제가 되는 단정문만 꺼버리자.
  • 단정문에 기능을 더하여 관련 데이터를 모아 보고하거나 사용자에게 UI로 보여주면 금상첨화!

리소스 사용의 균형

• 자신이 시작한 것은 자신이 끝내라.리소스 할당/해제에 책임을 져라.
  • file open 과 close 는 하나의 루틴에서 관리하도록 하라. 조건문에 의해 실행되지 않는 경우가 없도록 설계한다.
  • 현대 언어에는 open do end 문과 같이 리소스가 유효한 블록을 지정할 수도 있다.
• 중첩 할당 시에는, 할당 순서의 역순으로 해제하고 다른 곳에서 같은 자원을 얻으면 같은 순서로 획득하라.
• 균형을 체크하자
  • 어떠한 루틴을 실행할 때 요청을 처리할 때마다 리소스 사용량이 증가하지는 않았는지, 메모리가 새고 있는지
    확인하라.
  • 포인터 해제 이후 포인터 값을 NULL 로 설정하라.

헤드라이트를 앞서지 말아라

• 언제나 신중하게 작은 단계를 밟아라. 피드백을 받고 조정하라.
• 너무 과하게 앞서지는 말고, 여러분이 볼 수 있는 미래까지를 고려하자.

🍏 요 부분도 내가 새겨들어야할 내용이었다. 편집증이 필요하다!!
이 함수에서 어떤 전제를 가져야하는지, 결과가 전제를 망치지 않는지. 항상 예외를 고려한다던지.
할당에 대한 마무리를 잘 설계하고 의도한 결과가 나올 수 있도록, 예외를 현명하게 처리해놓을 수 있도록 노력해야한다.

5.구부러지거나 부러지거나

🍏 🍏 🍏 🍏