제 2장 실용주의 접근법

 

" 우리는 모두 시간과 자원이 제한된 세상에서 일한다. "

 

TIL (Today I Learn)

• Assignment 03
• 2022-03-20 ~ 2022-03-21

 

---

오늘 읽은 범위

• 2장 실용주의 접근법

---

3줄 요약

• 바꾸기 더 쉽게 Easier to Change. ETC. 이게 전부다. 규칙이 아니라 가치.
• DRY: 반복하지 말라 Don’t Repeat Yourself
• 목표물에 맞을 때까지 조준을 옮겨야한다.

---

책에서 기억하고 싶은 내용을 써보세요

Topic 8 좋은 설계의 핵심 

• 어떤 게 잘 설계되었다는 건 그 물건이 사용하는 사람에게 적응하여 맞춰진 다는 것이다.
• 바꾸기 더 쉽게 Easier to Change. ETC. 이게 전부다. 규칙이 아니라 가치.

 

 

Topic 9 DRY: 중복의 해악 

 

" 우리의 이해는 날마다 바뀐다. "

 

• DRY: 반복하지 말라 Don’t Repeat Yourself
  • 이것은 기억하느냐 마느냐의 문제가 아니다. 단지 언제 잊어버릴 것인가 하는 문제다.
• 함수 이름이 함수가 하는 일을 알려준다. 더 자세한 것을 알고 싶다면 소스코드를 보면 된다.
• 언제나 객체의 속성을 읽고 쓸 때 접근자 accessor 함수를 사용하라.
  • 모듈을 통해 제공되는 모든 서비스는 일관된 표기법 notation으로 사용할 수 있어야 한다.
• 몇 가지 대책
  • 개발자 간에 적극적이고 빈번한 소통을 장려
  • 일일 스크럼 스탠드업 미팅을 운영
  • 팀원 한 사람을 프로젝트 사서로 임명

Y2K8 호환성검사

Y는 Year, 2K는 2000을 뜻하는데, 연도를 끝 두 자리 숫자만 저장한 탓에 1900년대에 개발한 프로그램이 2000년 이후에는 제대로 동작하지 않는 문제다. 마이어는 Y2K 문제 역시 일 관된 액세스 원칙을 지키지 못해서 생겼다고 말한다.

 

 

 

Topic 10 직교성

• 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. 
• 우리가 설계하고 싶은 것은 단일하고 잘 정의된 목적을 가진 독립적인 컴포넌트다.
• 계층 구조는 직교적 시스템을 설계하는 강력한 방법이다. 
• 놀랍게도 직교성은 문서에도 적용할 수 있다. 내용과 표현이라는 두 개의 축이 있다. (like Markdown)

 

" 우편 번호, 이메일 주소, 도메인 이름 등은 모두 외부의 식별자다. 
즉, 여러분이 제어할 수 없고, 언제 어떤 이유로든 바뀔 수 있다.
자신의 힘으로 제어할 수 없는 속성에 의존하지 말라. "

 

 

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

• 코드의 결합도를 줄여라 
  • 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라. (like 부끄럼쟁이)
• 전역 데이터를 피하라
  • 싱글턴을 사용할 때는 주의를 기울여라. 싱글턴은 불필요한 결합을 만들 수 있다.
• 유사한 함수를 피하라
  •   전략 패턴 strategy pattern을 사용하여 더 낫게 구현할 수는 없는지 고민 해 보기 바란다.

 

 

 

Topic 11 가역성*

• 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 
• 최종 결정이란 없다.
• 유행을 좇지 말라.

*가역성 : 물질이 어떤 상태로 변하였다가 본래 상태로 되돌아갈 수 있는 성질.

 

 

" 여러분의 코드는 몇 가지 가능한 미래를 지원할 수 있는가?
어떤 미래가 일어날 가능성이 클까?
그 미래가 닥쳤을 때 이를 지원 하는 것이 얼마나 어려울까?
상자를 열 용기가 있는가? "

 

 

Topic 12 예광탄*

• 우리는 소프트웨어 개발을 과녁 맞히기에 비유하고는 한다. 
  • 어떻게 하면 과녁을 맞힐 수 있을지 생각해 보는 것은 흥미로운 일이다
  • 정답은 여러분이 조준하고 있는 무기의 특성에 따라 다르다는 것이다. 
• 움직이는 목표물을 맞히려면 실제 조건하에서 즉각적인 피드백을 받아야 한다. 
  • 목표물에 맞을 때까지 조준을 옮겨야한다.
• 소프트웨어 판 예광탄
  • 시스템을 정의하는 중요한 요구 사항을 찾아라.
  • 의문이 드는 부분이나 가 장 위험이 커 보이는 곳을 찾아라.
  • 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라
• 예광탄 vs 프로토타입
  • 프로토타입은 나중에 버리는 코드를 만든다.
  • 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격 중 일부가 된다. 

 

 

* 예광탄 : 탄자 뒷부분에 불빛을 내는 예광제가 들어있어 날아가는 궤적이 보이는 총알 또는 포탄

 

 

 

Topic 13 프로토타입과 포스트잇

• 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토타입을 만들고 있는 게 맞는지 자문해 보라.
  • 아마도 이런 경우에는 예광탄 방식의 개발이 더 적절할 것이다
• 프로토타이핑으로 조사할 대상은 무엇인가? 위험을 수반하는 모든 것이다.
  •    증명되지 않았거나, 실험적이거나, 의심이 가는 것, 마음이 편하지 않은 것
• 프로토타이핑은 학습 경험이다.
  •   프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다. 

 

무시해도 좋은 세부 사항

• 적절히 가짜 dummy 데이터를 사용할 수 있다.
• 제한된 방식으로만 작동하기도 한다.
• 오류 검사를 빼먹거나 아예 무시할 수도 있다.
• 주석이나 문서가 많지 않아야 한다. 
  •   결과를 문서로 많이 작성할 수는 있다.
• 실제로 사용하는 언어보다 추상화 수준이 높은 언어를 쓰는 것이 더 수월할 때도 있다.

 

 

 

 

Topic 14 도메인 언어

• 모든 언어는 제각기 일련의 특징들을 내세운다. 이런 특징들은 모두 어떤 해결 방안을 제시하기도 하지만 가려 버리기도 한다.
• 전통적인 소프트웨어 개발 방식이 제대로 동작하지 않는 이유 중 하나는 이 방법이 우리가 요구 사항을 알고 있다는 전제에 기반 하기 때문이다. 실제로는 잘 모른다. 
  (사실 이것도 우리의 존재 가치 중 하나다. 우리는 직관적으로 그들의 의도를 이해해서 코드로 바꿔 낸다.)

 

내부 도메인 언어 & 외부 도메인 언어

• 내부 : RSpec, 피닉스 라우터
  • 특징
    • 구현하는 호스트 언어인 루비와 엘릭서로 원하는 내용을 쓴다.
    • 여러분이 실행시키는 코드 안으로 들어간다.
  • 장점
    • 호스트 언어의 기능을 쓸 수 있다 (공짜강화좋아)
  • 단점
    • 호스트 언어의 문법과 의미론을 따라야만 한다
    • 원하는 언어와 구현할 수 있는 언어 사이에서 어느 정도 타협해야하만 한다
• 외부 :  큐컴버, 앤서블
  • 특징
    • 그들 자체의 언어를 사용한다.
    •  별도의 코드가 이 언어를 읽어 들여서 사용할 수 있는 형태로 바꾼다.
  • 장점
    • 호스트 언어의 제약이 없다.
  • 단점
    • 프로젝트에 어느 정도 추가 비용이 발생한다. 절약하는 것보다 더 많은 시간을 쏟지는 말라.
  • 가능하다면 YAML이나 JSON, CSV처럼 널리 통용되는 외부 언어를 사용하라. 그게 아니라면 내부 언어를 고려하라.
    (외부 언어는 애플리케이션의 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천한다.)

 

" 언어의 한계가 곧 자기 세계의 한계다.
- 루트비히 비트겐슈타인(Ludwig Wittgenstein) "

 

 

 

Topic 15 추정

• 모든 답은 추정치다. 단지 어떤 답이 다른 답보다 좀 더 정확할 뿐이다.
• 여러분이 전달하려는 정확도를 고려하여 답변의 단위를 선택하라. (일/주/월 등) 
• 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러야 한다.  종종 여러분이 선택한 조건은 답변의 일부가 되기도 한다.
• 우리는 간결함과 정확 성을 맞교환하고 있다.
• 의뢰인의 요청을 이해한 후에는 간단하게 기본적인 것만 갖춘 개략적인 모델을 만들어 보라.
• 모든 PERT* 과업은 낙관적 추정치와 가장 가능성이 높은 추정치, 비관적 추정치를 갖는다.
  • 값을 범위로 추정하는 건 추정 오류를 피할 수 있는 훌륭한 방법이다.
  • 하지만 실제로 이 프로젝트를 수행해 본 적은 없으므로 추정치가 정확할 리는 없다.

*PERT : 미 해군이 ‘폴라리스’라는 잠수함 발사용 탄도 미사일 개발 프로젝트 계획 을 세울 때 ‘프로그램 평가 검토 기법Program Evaluation Review Technique’ 혹은 줄여서 PERT라고 부르는 방법론을 만들면서 이런 추정 방식을 도입했다

 

점증적 개발 incremental development

• 요구 사항 확인하기
• 위험을 분석하고 위험도가 높은 부분을 우선 하기
• 설계, 구현, 통합
• 사용자와 함께 검증하기

반복 주기 iteration

• 초기의 계획은 어림짐작에 불과하다.
• 초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복 주기의 끝으로 삼아라. 코드와 함께 일정도 반복하며 조정하라. 한 번에 한입씩.

 

 

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• ETC. 참 중요하다고 느낀다. 예전에 다른 팀에서 db 접근 로직 바꾼다고 2년이 걸렸다는 얘기를 들은 적이 있다.
• 객체 접근 시 getter/setter를 꼭 사용하는 편인데 일관된 표기법으로써도 의미가 있다니 꽤 유의미하다.
• 불과 1년 전만중복에 대해서 깊게 고민해본적이 딱히 없었다. 당시 담당 모듈의 유지보수를 1년 동안 대부분 혼자 했으니.
  • 그런데 그 1년 만에 팀원들이 정말 많이 늘었다.(현재 진행형이다.) 그 분들과 기존 로직을 고도화하며 리팩터링하는 과정에 있는데 가끔 내부에 심어둔 값을 또 외부에서 가져오려고 하거나, 다른 패키지에 있는 함수가 추가된 것이 보일 때가 있었다. 코드 리뷰를 하면서 최대한 정리하긴 했지만 100% 깔끔하냐면 글쎄. 하지만 최선은 다했다.
  • 동료가 많아지면 배움의 폭도 넓어지지만 확실히 신경쓰고 경계할 포인트가 많아지는건 어쩔 수 없나보다.
• 싱글턴 패턴을 자주 사용하는 편인데 전역 데이터처럼 쓰고 있진 않은지 문득 확신이 서지 않는다. 소개해준 링크를 추가로 정독해보자.
• 예광탄 개발이라는 용어가 실제로 있다니 신박하다고 생각한다. 이번에 프로토타입과의 차이를 명확히 알았다.
  • 나는 예광탄 개발을 선호하는 편인 것 같다. 
• 언어의 한계가 곧 자기 세계의 한계라는 인용글이 꽤 뼈아프다. 물론 이번 장의 도메인 언어는 조금 다른 얘기긴 했지만 나는 프로그래밍 언어 풀이 별로 넓지 않은 편이다. 1장에서처럼 1년에 새로운 언어 하나는 습득하라는데 꽤 많은 시간이 지났으니… 당장 올해부터 2-3개는 시도해봄직하다.
  
  • 코코아 클론 졸업했는데 html/css도 카운트 할까 말까.... 양심의 문제이니 연말로 선택을 미루겠다 :)

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

• '그리고 여러분이 헬리콥터 조종사라면 생선을 먹지 말라.......' 뭔소리야
• '문제 도메인 domain의 언어가 어떤 프로그래밍 해결 방안을 제안하기도 하는데, 우리 생각에는 이것이 프로그래밍 언어의 사고방식보다 더 중요하다. 문제 도메인에 가깝게 프로그래밍하라.'
  • 문제 도메인이 뭔지 아직 잘 이해가 안간다.
  • 문제가 생길 여지는 많지만 쓸모있는 도메인 언어라는 소리인가?