본문 바로가기
실용주의 프로그래머

2장. 실용주의 접근법

by 아토로 2022. 3. 21.

오늘 읽은 범위

  • 2장. 실용주의 접근법

기억하고 싶은 내용

  • 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
    • 결합도를 줄이는 이유: 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다.
    • 단일 책임 원칙: 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다.
    • 이름 짓기의 중요성: 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.
    • ETC는 규칙이 아니라 가치이다.
  • DRY: 반복하지 말라.
    • DRY를 따르지 않으면 똑같은 것이 두 군데 이상에 표현될 것이다.
    • 하나를 바꾸면 나머지도 바꿔야 함을 기억해야 한다.
    • DRY는 지식의 중복, 의도의 중복에 대한 것이다.
    • 문서화 중복: 주석 대신 코드로 의도를 나타내자.
    • 데이터의 DRY 위반: 가능하다면 중복되는 필드 대신 메서드로 구현하자.
    • 개발자 간의 중복: 개발자 간에 적극적이고 빈번한 소통을 장려해야 한다.
  • 재사용하기 쉽게 만들어라.
    • 사람들은 쉽지 않으면 하지 않을 것이다.
  • 관련 없는 것들 간에 서로 영향이 없도록 하라.
    • 직교적인 시스템을 작성하면 생산성 향상과 리스크 감소의 장점이 있다.
    • 자신이 제어할 수 없는 속성에 의존하지 말라.
    • 단위 테스트를 작성하는 행위 자체가 직교성을 테스트해 볼 수 있는 기회다.
  • 최종 결정이란 없다.
  • 유행을 좇지 말라.
  • 목표물을 찾기 위해 예광탄을 써라.
    • 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
    • 개발자가 들어가서 일할 수 있는 구조를 얻는다.
    • 통합 환경을 수행할 기반이 생긴다.
    • 보여줄 것이 생긴다.
    • 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.
    • 목표물에 맞을 때가지 조준을 옮겨야 한다.
  • 예광탄 코드 대 프로토타입
    • 프로토타입: 나중에 버리는 코드를 만든다.
    • 예광탄 코드: 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격 중 일부가 된다.
  • 프로토타이핑으로 학습하라.
    • 적절히 가짜(dummy) 데이터를 사용할 수 있다.
    • 제한된 방식으로만 작동하기도 한다.
    • 오류 검사를 빼먹거나 아예 무시할 수도 있다.
    • 주석이나 문서가 많지 않아야 한다.
  • 문제 도메인에 가깝게 프로그래밍하라.
  • 추정으로 놀람을 피하라.
  • 코드와 함께 일정도 반복하며 조정하라.

소감 및 생각

  • 실용주의 프로그래머를 위한 프로그래밍 접근법에 대해 잘 정리된 챕터이었다. 기본적으로 좋은 설계를 하는 것이 중요하고 이를 위해서 다양한 것들을 고려해야 했다. 그중에 “반복하지 말라”와 “재사용하기 쉽게 만들어라”는 다른 책에서도 여러 번 강조했던 부분이었고 그만큼 중요하다는 것을 의미한다고 생각한다.
  • 목표물을 찾기 위해 예광탄 코드를 작성한다는 것은 새롭게 알게된 개념이었다. 프로토타입처럼 무언가를 검증하고 버리는 코드가 아니라, 실제 최종 시스템에 사용될 코드이며 사용자가 원하는 것, 즉 개발을 하려는 목표에 맞는 구조를 찾기 위한 과정이라는 것에서 정말 의미 있는 방법이라는 생각이 들었다.

새롭게 배운 개념

  • ETC 원칙: 바꾸기 더 쉽게(Easier to Change)
  • DRY 원칙: 반복하지 말라(Don’t Repeat Yourself)
  • 직교성(orthogonality): 그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 말한다. 컴퓨터 과학에서 이 용어는 일종의 독립성이나. 결합도 줄이기(decoupling)을 의미한다.

'실용주의 프로그래머' 카테고리의 다른 글

4장. 실용주의 편집증  (0) 2022.05.19
3장. 기본 도구  (0) 2022.03.23
1장. 실용주의 철학  (0) 2022.03.19

댓글