🪴ㅤTIL (DAY - 2)
2022.03.22
오늘 읽은 범위
👉ㅤ클린코드 2장.실용주의 접근법
기억하고 싶은 내용ㅤ📕
좋은 설계는 나쁜 설계보다 바꾸기 쉽다. (p.39)
어떤 게 잘 설계되었다는건 그 물건이 사용하는 사람에게 적응하며 맞춰진다는 것이다. 이 말을 코드에
적용해 보면, 잘 설계된 코드는 바뀜으로써 사용하는 사람에가 맞춰져야 한다. 그래서 우리는 ETC 원칙을
따른다. 바꾸기 더 쉽게(Easier To Change). ETC. 이게 전부다. (p.39)
가치(Value)는 여러분이 결정을 내리게 도움을 주는 것이다. 이걸 해야 하나 아니면 저걸 해야 하나 같은
결정을 돕는다. (p.39)
ETC에는 암묵적인 전제가 있다. 바로 여러 길 중 어떤 길이 미래의 변경을 쉽게 만드는지 알 수 있다는
것이다. (p.40)
- 첫 번째로, 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 '바꾸기 쉽게'라는 길을 선택한다.
- 두 번째는 이러녀 경우를 여러분이 직관을 발전시키는 기회로 삼으라는 것이다.
소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길을
우리가 DRY라 부르는 원칙을 따르는 것이라 생각한다. DRY 원칙은 다음과 같다. 모든 지식은 시스템
내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다. (p.43)
우리는 DRY가 '실용주의 프로그래머'의 도구 상자에서 가장 중요한 도구 중 하나라고 생각한다. (p.43)
DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는
것이다. 경우데 따라서는 중복 표현이 두 가지 완전히 다른 방식으로 이루어질 수도 있다. (p.44)
함수 이름이 함수가 하는 일을 알려준다. 더 자세한 것을 알고 싶다면 소스 코드를 보면 안다.
이것이 DRY다! (p.49)
모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. (p.50)
여러분은 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다. 사람들은
쉽지 않으면 하지 않을 것이다. 그리고 재사용에 실패한다면 지식 중복의 위험을 감수해야 한다. (p.54)
'직교성'은 기하학에서 빌려 온 용어다. 그래프의 축과 같이 두 직선이 직각으로 만나는 경우를 직교한다고
말한다. 벡터 용어로 표현해 보면 두 개의 선은 독립적(independent)이다. (p.54)
관련 없는 것들 간에 서로 영향이 없도록 하라. (p.56)
우리가 설계하고 싶은 것은 자족적(self-contained)인 컴포넌트, 즉 단이랗고 잘 정의된 목적을 가진
독립적인 컴포넌트다. (p.57)
직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다. (p.57)
- 생산성 향상
- 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다.
- 직교적인 접근법은 재사용도 촉진한다.
- 직교적ㅇ니 컴포넌트들을 결합하는 경우 얻을 수 있는 꽤 미묘한 생산성 향상 요소가 있다.
- 리스크 감소
- 감염된 코드가 격리되어 있다.
- 시스템이 잘 깨지지 않는다.
- 직교적인 시스템은 그 안의 컴포넌트 들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기 때문에, 아무래도 테스트를 더 많이 하게 된다.
- 특정 업체나 제품, 플랫폼에 덜 종속될 것이다.
설계가 직교적인지 확인하는 손쉬운 방법이 있디. 컴포넌트들을 나누었을때 다음과 같이 스스로에게 물어보라.
'특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영항을 받는가?'
직교적인 시스템에서는 답이 '하나'여야 한다. (p.59)
자신의 힘으로 제어할 수 없는 속성에 의존하지 말라. (p.60)
직교성을 유지하기 위해 사용할 수 있는 몇 가지 기법이 있다. (p.61)
- 코드의 결합도를 줄여라
'부끄럼쟁이(shy)' 코드를 작성하라. 즉, 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라. - 전역 데이터를 피하라
코드가 전역(global) 데이터를 참조할 때마다 코드는 해당 데이터를 공유하는 다른 컴포넌트와 묶이게 된다. - 유사한 함수를 피하라
- 자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라
놀랍게도 직교성은 문서에도 적용할 수 있다. 내용과 표련이라는 두개의 축이 있다. (p.63)
당연한 말이겠지만 DRY 원칙으로 무장하고 직교성 원칙을 충실히 적용한다면 개발하고 있는 시스템이 더
유연하고 이해하기 쉬워질 것이다. 디버깅, 테스트, 유지 보수 또한 쉬워질 것 이다. (p.64)
여러분이 헬리콥터 조종사라면 생선을 먹지 말라 (p.64)
영원한 것은 없다. 여러분이 어떤 사실을 굳게 믿고 그 사실에 전적으로 의존하고 있다 하더라도
그 사실 역시 언젠가는 변할 것이 뻔하다. (p.66)
여기서 추천하는 방법들, 특히 DRY 원칙, 결합도 줄이기, 외부 설정 사용하기를 따른다면 중요하면서도
되돌릴 수 없는 결정의 수를 가능한 한 줄일 수 있을 것이다. (p.68)
결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를
지워버릴 수 있다. (p.68)
최종 결정이란 없다 (p.69)
여러분이 할 수 있는 것은 바꾸기 쉽게 만드는 것이다. 외부의 API를 여러분이 만든 추상화 계층 뒤로
숨겨라. 여러분의 코드를 여러 컴포넌트로 쪼개라. 결국에는 하나의 거대한 서버에 배포하게 되더라도,
이 방식이 거대한 단일 모듈 애플리케이션을 가져다 쪼개는 것 보다 훨씬 더 쉽다. (p.70)
누구도 어떤 미래가 펼쳐질지 알 수 없으며, 우리 분야는 특히 더 그렇다. 여러분의 코드가 로큰롤(rock-n-roll)을
할 수 있게 하라. 락을 할 수도 있고 필요한 경우 롤을 할 수 도 있게하는 것이다. (p.70)
미래에 대비하는 코드를 작성하는 것이 어려울 만하다. 하지만 코드의 진화를 슈뢰딩거 고양이들로 가득 찬 상자로
생각하라. 각각의 결정은 다른 버전의 미래를 야기한다. 여러분의 코드는 몇 가지 가능한 미래를 지원할 수 있는가?
어떤 미래가 일어날 가능성이 클까? 그 미래가 닥쳤을 때 이를 지원하는 것이 얼마나 어려울까?
상자를 열 용기가 있는가? (p.71)
시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라.
이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라. (p.73)
목표물을 찾기 위해 예광탄을 써라. (p.73)
예광탄 코드는 한 번 쓰고 버리려고 만드는 것이 아니다. 앞으로도 계속 사용할 코드다. 예광탄 코드도 다른
제품 코드와 마찬가지로 오류 검사, 올바른 구조, 문서화, 자체 검사(self-checking)를 갖추어야 한다. (p.75)
예광탄 개발 방법은 '프로젝트는 결코 끝나지 않는다.'는 견해와도 일맥상 통한다. 변경 요청과 기능 추가 요청은
언제나 계속 들어오기 마련이다. 예광탄 개발 방법은 점진적이 접근 방법이다. (p.75)
예광탄 코드 접근 방법에는 여러 장점이 있다. (p.75)
- 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다
- 개발자가 들어가서 일할 수 있는 구조를 얻는다
- 통합(integration) 작업을 수행할 기반이 생긴다
- 보여줄 것이 생긴다
- 진행 상황에 대해 더 정확하게 감을 잡을 수 있다
예광탄은 지금 맞히고 있는 것이 무엇인지 보여준다. 그러나 그것이 꼭 목표물이라는 보장은 없다. 그럴 경우
목표물에 맞을 때까지 조준을 옮겨야 한다. 이것이 핵심이다. (p.77)
지금 있는 것을 목표물에 더 가까워지도록 바꿔라. 그리고 가벼운 개발 방법론을 선택했다는 사실에 감사하라.
코드의 크기가 작으면 관성 역시 약하므로 빠르고 쉽게 바꿀 수 있다. (p.77)
프로토타입은 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것이 목표다. (p.78)
프로토타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템
골격 중 일부가 된다. 프로토타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집과 같은 것이다. (p.79)
프로토타이핑은 학습 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에
있다. 이것이 프로토타이핑의 진정한 핵심이다. (p.81)
프로토타이핑으로 학습하라. (p.81)
프로토타입을 어떻게 사용할 것인가? (p.81)
- 정확성
- 완전성(completeness)
- 안정성
- 스타일
프로토타이핑의 목적은 전체적으로 시스템이 어떻게 동작할지에 대해 감을 잡는 것이다. (p.83)
내부 도메인 언어의 단점은 호스트 언어의 문법과 의미론을 따라야만 한다는 것이다. (p.90)
외부 언어는 이런 제약이 없다. 여러분이 정의하려는 언어의 파서(parser)를 만들기만 하면 된다. (p.90)
모델을 작성하는 기술에 대해 깊이 파고들기 전에 항상 좋은 답을 알려주는 기본적인 추정의 비법을 하나
밝히겠다. 이미 그 일을 해본 사람에게 물어보라. (p.96)
여러분은 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러야 한다. 종종 여러분이 선택한 조건은
답변의 일부가 되기도 한다. "교통사고가 일어나지 않고, 연료가 떨어지지 않는다면 20분 이내에 도착할 겁니다." (p.96)
코드와 함께 일정도 번복하며 조정하라. (p.101)
누군가 추정해 달라고 하면 뭐라고 대답해야 할까?
"나중에 연락드릴게요."라 말해야 한다. (p.102)
여러분이 계산한 추정치를 기록으로 남겨라. 그리고 각 추정치가 얼마나 정확했는지도 기록으로 남겨라.
만약 오차가 50% 이상이라면 잘못된 추정치를 내게 된 원인이 무엇인지 찾아보라. (p.102)
오늘 읽은 소감ㅤ📙
이번 챕터는 지금 내 상황에 매우 도움이 되는 내용들이 대부분을 차지했다.
물론 프로토타입이나 파서같은 자주보지 않은 용어들이 섞여 있어서 오늘도 이해하기는 어려웠다.
특히 오늘 읽은 내용 중 양자역학에 비유한 부분이 가장 흥미롭고 좋았다.
물리학 중 양자역학을 가장 좋아하고 또 관심있어 하는 부분이기 때문이다.
난 여전히 코드를 치기가 겁이나고 두렵다. 완벽한 것이 없다고 머리는 이해를 하지만
막상 에러나는 나의 코드를 직관할때마다 마음도 아프고 내 자신이 매우 초라한 것처럼 느껴지기 때문이다.
'상자를 열어볼 용기가 있는가?'
과연 나는 이 용기를 가지고 있을까 ?
명언 || 궁금하거나 이해가 잘 가지 않는 내용ㅤ📘
🐘 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다.
에밀 오귀스트 샤르티에(Emil-Auguste Chartier)
🐘 언어의 한계가 곧 자기 세계의 한계다.
루트비히 비트겐슈타인(Ludwig Wittgenstein)
🦖ㅤ객체 지향 언어와 함수형 언어의 직교성은 어떻게 다를까? 이런 차이가 언어 자체에서 내제된 것일까?
아니면 사람들이 언어를 사용하는 방법이 다른 것일까?
👉ㅤ
ㅤ객체 지향 프로그래밍 :
하나의 모델이 되는 청사진(blueprint)을 만들고, 그 청사진을 바탕으로 한 객체 를 만드는 프로그래밍 패턴
ㅤ함수형 프로그래밍 :
자료 처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나
#코딩 #개발자 #노마드북클럽 #노개북
우주류는 내 안에 살아 있소
