[노개북 챌린지] 실용주의 프로그래머 2

김발자·2022년 4월 19일
0
post-thumbnail

실용주의 프로그래머 2장 < 실용주의 접근법 >

Today reading range

- 오늘 읽은 범위


실용주의 프로그래머 2장 < 실용주의 접근법 >

Impressive content

- 인상 깊었던 내용


좋은 설계의 핵심

어떤게 잘 설계되었다는 말은 그 물건이 사용하는 사람에게 적응하여 맞춰진다는 것이다. 이 말을 코드에 적용해보면, 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다. 그래서 우리는 ETCeasy to change원칙을 따른다.
교체가 가능하다면 미래에 어떤 일이 일어난든 이 코드가 앞길을 가로막지 않을 것이다.

DRY: 중복의 해악

사람들은 대부분은 유지 보수란 버그를 고치고 기능을 개선하는 것을 의미하기 때문에, 애플리케이션이 출시되었을 때 비로소 유지보수가 시작된다고 믿는다. 우리는 이들이 틀렸다고 생각한다. 프로그래머는 늘 유지 보수 모드에 있다. 우리의 이해는 날마다 바뀐다.
DRY(Don't repeat yourself) 는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안된다는 것이다.
여러분은 뭔가를 직접 만드는것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다. 사람들은 쉽지않으면 하지 않을 것이다. 그리고 재사용에 실패한다면 지식 중복의 위험을 감수해야한다.

직교성

컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기decoupling를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향샹과 리스크 감소이다.

생산성 향상

  • 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다...
  • 직교적인 방법은 재사용도 촉진한다...
  • ...컴포넌트 하나가 M가지 일을 하고 다른 하나가 N가지 일을 한다고 가정하자. 만약 두 컴포넌트가 직교적이라면 결합했을때 MNM☓N 가지 일을 한다.

직교성을 유지하기 위해 사용할 수 있는 몇 가지 기법이 있다.

  • 코드의 결합도를 줄여라
  • 전역 데이터를 피하라
  • 유사한 함수를 피하라

가역성

중요한 결정이 많이 내려졌을 즈음엔 목표가 너무 작아져서 목표가 움직이거나, 바람의 방향이 바뀌거나, 도쿄의 나비가 날갯짓을 한다면 여러분의 겨냥을 빗나갈 것이다. 아마 매우 큰 차이로 빗나갈 것이다. 문제는 중요한 결정은 쉽게 되돌릴 수 없다는데 있다.

결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

예광탄

우리는 소프트웨어 개발을 과녁 맞히기에 비유하고는 한다.

시스템을 정의하는 종요한 요구사항을 찾아라. 의문이 드는 부분이나 가장 위허이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 우선순위를 정하라.

예광탄 코드에는 아직 모든 기능이 들어있지 않을 뿐이다. 하지만 시스템을 구성하는 요소를 모두 연결해 놓은 후라면 목표물에 얼마나 근접했는지 확인 할 수 있으며, 필요하다면 조정도 할 수 있다.

프로토타입

프로토타이핑으로 조사할 대상은 무엇인가? 위험을 수반하는 모든 것이다.

도메인언어

언어의 한계가 곧 자기 세계의 한계이다.

  • 루트비히 비트켄슈타인(Ludwig Wittgenstein)

Thoughts I had while reading the book

- 오늘 책을 읽으면서...


2장 내용은 아직 개발 경험이 많지 않은 저에게 요점정리같은 내용이이였습니다. 특히 제가 그동안 개발뿐만 아니라 다른 업무를 하면서 느꼈던 답답함의 원인도 알 수 있었습니다. DRY와 직교성 이야기는 정말 중요한 이야기 인것같습니다. 특히 저 같은 초보 개발자가 흔히 실수하기 쉬운 부분이라 더 집중적으로 읽었습니다. 두 코드 작성법이 아직은 추상적으로 다가오지만 지금 진행중인 프로젝트에 적용해봐야겠습니다. 사실 더 흥미로웠던건 예광탄 개발에 관한 이야기였는데 제가 처음 팀 프로젝트를 시작할때 가장 고민됬던 부분이 바로 백엔드 작업을 언제 시작해야되는지에 대한 것이였기 때문입니다. 초보자들이 모여서 하는 만큼 프론트엔드 작업중에 변경사항이 많아 고민했던것이였는데 이 개발법을 알았더라면 팀원들과 서비스에 대해서 좀 더 나눌 수 있는게 많았을거란 생각에 아쉬움이 많이 들었습니다. 책을 읽으면 읽을수록 왜 그렇게 많은 개발자들이 이 책을 추천했는지 알게되는것 같습니다. 꼭 개발자가 아니더라도 일을 효율적으로 하고 싶은 사람이라면 꼭 추천할만 책인것같습니다.

Things you're curious about, things you don't understand.

궁금한 내용, 이해되지 않았던 내용


  • 데이터 저장소와의 중복
  • 외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라.
  • 도메인 언어
profile
매일 글적글적 거리고 싶은 김발자

0개의 댓글

관련 채용 정보