실용주의 프로그래머 읽어보기 7주차

들어가며

이 포스트는 데이비드 토머스, 앤드류 헌트의 「실용주의 프로그래머」 Topic42 ~ 45까지 읽고 개인적으로 학습한 내용을 정리한 글입니다.

• 책: 실용주의 프로그래머
• 저자: 데이비드 토머스, 앤드류 헌트
• 출판사: 인사이트
• 챕터: Topic 42 ~ Topic 45

핵심 내용 정리

Topic 42. 속성 기반 테스트

계약, 불변식, 속성

Tip 71 속성 기반 테스트로 가정을 검증하라

• 불변식
  • 함수 실행 전후로 계속 어떤 부분의 상태에 대해 참이 되는 조건
  • 예를 들어 리스트 정렬 시 정렬 전 후로 리스트 원소 수는 변하지 않음

속성 기반 테스트는 우리를 자주 놀래킨다

• 속성 기반 테스트가 강력한 이유는 입력을 생성하는 규칙과 출력을 검증하는 단정문만 설정한 채 제멋대로 작동하도록 놔두기 때문
• 테스트가 통과하거나, 단정문이 실패하거나 코드가 중간에 멈출 수도 있음
• 단위 테스트의 역할
  • 속성 기반 테스트의 여러 가지 다른 수행 결과와 상관없이 문제가 발생하는 상황에 집중할 수 있게 함
  • 회귀 테스트 역할 수행

속성 기반 테스트는 설계에도 도움을 준다

• 속성 기반 테스트는 코드를 불변식과 계약이라는 관점에서 바라보게 함
• 어떤 것이 변하지 않아야 하고, 어떤 조건을 만족해야 하는지 생각해야 한다
• 속성 기반 테스트는 단위 테스트를 보완한다

Topic 43 바깥에서는 안전에 주의하라

나머지 90%

• 코딩을 할 때 “된다” & “왜 안 되지?”를 오가며 가끔은 “그런 일이 일어날 리 없어” 상태도 된다
• 다음은 코드가 잘못될 수 있는 경우를 찾고, 각 경우에 대한 단위 테스트를 추가하는 것
• 내부에서 발생하는 오류 & 외부에서 시스템을 망가트리려 하는 시도도 고려해야함

기본 보안 원칙

• 언제나 명심해야 하는 기본 원칙
  1. 공격 표면을 최소화하라
  2. 최소 권한 원칙
  3. 안전한 기본값
  4. 민감 정보를 암호화하라
  5. 보안 업테이트를 적용하라

공격 표면을 최소화하라

• 시스템의 공격 표면 영역은 공격자가 데이터를 입력하거나, 데이터를 추출하거나 서비스를 실행시킬 수 있는 모든 접근 지점을 합한 것

코드의 복잡성은 공격 매개체를 유발한다

• 복잡한 코드는 예상 외의 부작용을 일어날 확률을 높이고, 결과적으로 공격 표면을 넓힌다

입력 데이터는 공격 매개체다

• 외부의 데이터를 절대 신뢰하지 말라

인증이 없는 서비스는 공격 매개체다

• 본질적으로 인증이 없는 서비스는 전 세계 누구든지 호출할 수 있다. 따라서 별도로 처리하거나 제한을 두는 조치를 하지 않으면 최소한 ‘DDos’ 공격이 가능해진다

인증을 요구하는 서비스도 공격 매개체다

• 인증 받은 사용자의 수를 언제나 최소로 유지하라
• 쓰이지 않거나, 오래되고, 유효하지 않은 사용자나 서비스를 정리하라

출력 데이터는 공격 매개체다

• 응답이 들어 있는 데이터가 사용자의 권한에 적절한지 늘 확인하라

디버깅 정보는 공격 매개체다

최소 권한 원칙

• 최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라

안전한 기본값

• 자신의 애플리케이션 혹은 웹 사이트 사용자의 기본 설정은 가장 안전한 값이어야 한다

민감 정보를 암호화하라

• 개인 식별 정보, 금융 데이터, 비밀번호, 다른 인증 정보를 일반 텍스트로 남기지 말라
• 암호, API 키, SSH 키, 암호화 비밀번호, 그 밖의 다른 인증 정보를 소스코드용 버전 관리 시스템에 넣지 말라

보안 업데이트를 적용하라

Tip 73 보안 패치를 신속히 적용하라

상식 대 암호

• 암호화의 규칙
  • 비밀번호를 직접 만들지 말라
  • 신뢰할 수 있는 것에만 의지하라. 많은 검토, 철저한 검사, 좋은 유지 보수, 자주 업데이트되는 라이브러리와 프레임워크를 사용하라

Topic 44. 이름 짓기

• 우리는 이름을 붙인다. 애플리케이션, 서브시스템 모듈, 함수, 변수 등 새로운 것을 끊임없이 만들고 그것에 이름을 부여한다. 이름은 아주 중요하다. 이름이 개발자의 의도와 믿음을 잔뜩 드러내기 때문이다

문화를 존중하라

• 해당 프로그래밍 언어, 환경의 문화를 따라야 한다

일관성

• 반드시 팀의 모든 사람이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다
  • 이를 위해선 많은 의사소통 수행(ex. 페어 프로그래밍)

이름 바꾸기는 더 어렵다

Tip 74 이름을 잘 지어라. 필요하면 이름을 바꿔라

Topic 45. 요구 사항의 구렁텅이

Tip 75 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.

Tip 76 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다

요구 사항 미신

• 사람들은 자신이 원하는 것을 정확히 알 때만 자동화를 시도하게 되었다
  • 초기 컴퓨터는 기능이 충분치 않아 컴퓨터로 해결할 수 있는 문제의 폭도 제한적이라, 전체 문제를 먼저 다 이해한 후 작업을 시작하는 것이 실제로 가능

요구 사항은 과정이다

Tip 77 요구 사항은 피드백을 반복하며 알게 된다

• 우리는 mockup이나 프로토타입을 만들어 의뢰인이 직접 다루어 볼 수 있도록 한다
• 실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다
• 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다

의뢰인의 입장에서 보라

Tip 78 사용자처럼 생각하기 위해 사용자와 함께 일하라

• 많이 활용되지는 않지만 의뢰인의 머릿속 깊숙이 들어갈 수 있는 단순한 기법이 있다. 의뢰인이 되어 보는 것이다

요구 사항 대 정책

Tip 79 정책은 메타데이터다

요구 사항 문서화

• 우리는 최고의 요구 사항 문서, 아마 유일한 요구 사항 문서는 작동하는 코드
• 의뢰인이 원하는 바를 자신이 어떻게 이해했는지 문서로 정리하지 않아도 되는 것은 아니지만, 문서는 목표가 아니고, 의뢰인에게 승인해 달라고 들이밀 수 있는 것도 아니라는 뜻이다

요구 사항 문서는 의뢰인을 위한 것이 아니다

• 의뢰인은 자신이 원하는 것을 처음에는 잘 모른다 -> 이를 기반으로 한 문서는 사상누각에 불과하다

요구 사항 문서는 계획을 위한 것이다

• 요구 사항 설명을 짧게 제한하면 개발자들이 명확하지 않은 점을 물어보도록 유도할 수 있다

지나치게 자세한 명세

• 요구 사항 문서를 만들 때 생기는 또 다른 심각한 문제는 지나치게 자세히 서술하는 것
  • 좋은 요구 사항은 추상적이다
  • 밑에 깔려 있는 의미론적 불변식을 요구 사항으로 잘 갈무리하고, 구체적인 작업 방식이나 현재의 작업 방식은 정책으로 문서화해야 한다

용어 사전 관리하기

• 프로젝트 용어 사전을 만들고 관리하라
  • 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 한다