오늘 TIL 3줄 요약
- Easier To Change 변경은 쉽게. 요구사항은 변할 수 있으니까!
- Don't Repeat Yourself 중복을 없애고, 관련없는 것들은 분리시키기! 쉬운 변경을 위해서!
- 예광탄코드, 프로토타입, 프로젝트에 대한 추정... 피드백을 받아 개선시켜나가자!
TIL (Today I Learned) 날짜
2022.03.20 ~ 2022.03.21
오늘 읽은 범위
2장 실용주의 접근법
책에서 기억하고 싶은 내용을 써보세요.
Topic 8 좋은 설계의 핵심
Easier to Change. ETC.
- 왜 결합도를 줄이면 좋은가? 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다.
왜 단일 책임 원칙single responsibility principle1이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다. ETC.
왜 이름 짓기가 중요한가? 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다. ETC!
(p39) - 교체 가능하게 작성하라는 말은 코드의 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다.
엔지니어링 일지에 현재 상황과 여러분의 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라. 그리고 소스 코드에 이에 대한 표시를 남겨 둬라. 나중에 이 코드를 바꿔야 하는 시점이 왔을 때, 뒤를 돌아보고 자신에게 피드백을 줄 수 있을 것이다.
(p40)
Topic 9 DRY: 중복의 해악
- 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.
Tip 15 DRY: 반복하지 말라Dont Repeat Yourself
하나를 바꾸면 나머지도 바꿔야 함을 기억해야 한다.
(p43) - DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다. 경우에 따라서는 중복 표현이 두 가지 완전히 다른 방식으로 이루어질 수도 있다.
코드의 어떤 측면 하나를 바꿔야 할 때 여러 곳을 바꾸고 있나? 그것도 여러 가지 다른 형태를? 코드를 바꾸고 문서도 바꾸는가? 데이터베이스 스키마와 스키마를 담고 있는 구조 등도? 그렇다면 여러분의 코드는 DRY하지 않다.
(p44)
모든 코드 중복이 지식의 중복은 아니다.
(p47)
데이터의 DRY 위반
- 바깥세상에는 DRY 원칙 위배를 노출하지 않는다. 대신 클래스 내의 메서드가 좀 고생하면 된다.
(p49) - 모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자accessor 함수를 사용하라.
(p50)
내부 API에서 생기는 중복
- 언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아보라
외부 API에서 생기는 중복
- 공개 API를 OpenAPI 같은 형식으로 엄밀하게 문서화하는 경우가 점점 많아지고 있다. 이런 형식의 API 명세를 여러분의 API 도구로 불러와서 사용
(p51)
데이터 저장소와의 중복
- 저장된 데이터를 객체로 옮기기 위한 코드를 손으로 만드는 것이 아니라 스키마로부터 바로 생성해낼 수 있는 것이다. 이렇게 귀찮은 일을 줄여 주는 영속성 프레임워크persistence framework
- 코드에서 외부 데이터를 고정된 구조(예를 들어 구조체나 클래스의 인스턴스)로 표현하는 대신, 그냥 키-값 데이터 구조(언어에 따라 맵이나 해시, 사전dictionary이라고도 부른다. 자바스크립트처럼 일반 객체가 이런 역할을 하기도 한다.)에 밀어 넣는 것
개발자 간의 중복
- 우리가 느끼기에 최선책은 개발자 간에 적극적이고 빈번한 소통을 장려하는 것이다.
- 일일 스크럼 스탠드업 미팅
- 슬랙Slack 채널같이 공통의 문제를 다루기 위한 공간
- 소스 트리의 한가운데에 유틸리티 루틴과 스크립트를 모아둘 수 있는 장소를 마련
일상적으로든 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라. 다른 사람의 것을 기웃거리는 게 아니고, 거기서 배우는 것이다.
(p53)
Topic 10 직교성
- 직교성은 기하학에서 빌려 온 용어다. 그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 말한다.
(p54) - 컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기decoupling를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
(p55)
직교성의 장점
- 헬리콥터 예가 묘사하듯이 비직교적인 시스템은 본질적으로 변경과 조정이 더 복잡하다.
Tip 17 관련 없는 것들 간에 서로 영향이 없도록 하라.
생산성 향상
- 새로운 코드를 추가할 때마다 기존의 코드를 계속 바꾸지 않아도 된다.
- 예상하지 못한 방식으로 새로운 컴포넌트와 결합할 수 있다. 시스템이 더 느슨하게 결합되어 있을수록 재조합하고 개량하기 쉽다.
- 컴포넌트 하나가 M 가지 서로 다른 일을 하고 또 다른 컴포넌트 하나가 N 가지 일을 한다고 가정하자. 만약 두 컴포넌트가 직교적이라면 결합했을 때 결과물은 M *N 가지 일을 한다.
(p57)
리스크 감소
- 감염된 코드가 격리
- 문제가 생기더라도 문제점은 그 부분으로 한정될 것이다.
- 컴포넌트들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기
- 특정 업체나 제품, 플랫폼에 덜 종속
설계
- 직교적이라는 것을 설명할 때 모듈식, 컴포넌트 기반, 계층layer 같은 다른 용어를 사용하기도
(p58) - 특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가? 직교적인 시스템에서는 답이 하나여야 한다
(p59) - 또한 현실 세계의 변화와 설계 사이의 결합도를 얼마나 줄였는지도 확인
(p60)
코딩
- 코드의 결합도를 줄여라
부끄럼쟁이shy 코드를 작성하라. 즉, 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라. - 전역 데이터를 피하라
- 유사한 함수를 피하라
테스트
- 모듈 수준의 테스트나 단위 테스트가 통합 테스트보다 테스트 케이스를 만들고 수행하기 훨씬 쉬우므로 이는 좋은 소식이라 할 수 있다.
단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻
(p63)
문서화
- 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수
(p63)
Topic 11 가역성
- 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다.
(p68)
유연한 아키텍처
- 이렇게 아키텍처가 변덕스러운 환경에서 어떻게 계획을 세울 수 있겠는가? 못한다.
여러분이 할 수 있는 것은 바꾸기 쉽게 만드는 것이다. - 외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라.
- 여러분의 코드를 여러 컴포넌트로 쪼개라. 결국에는 하나의 거대한 서버에 배포하게 되더라도, 이 방식이 거대한 단일 모듈 애플리케이션을 가져다 쪼개는 것보다 훨씬 더 쉽다.
(p68 ~ p69)
Topic 12 예광탄
- 총알이 공기 중에 밝은 줄무늬의 궤적을 남기는 것을 볼 수 있는데, 이런 줄무늬는 예광탄tracer bullet이 만드는 것
- 군인들은 발사된 예광탄을 사용하여 조준을 재조정한다. 실제 상황에서의 실시간 피드백이기 때문에 매우 실용적이다.
(p72) - 코딩에서 동일한 효과를 얻으려면 우리를 요구 사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가를 찾아야 한다
- 시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.
(p73) - 예광탄 코드도 다른 제품 코드와 마찬가지로 오류 검사, 올바른 구조, 문서화, 자체 검사self-checking를 갖추어야 한다. 예광탄 코드에는 아직 모든 기능이 들어 있지 않을 뿐이다. 하지만 시스템을 구성하는 요소를 모두 연결해 놓은 후라면 목표물에 얼마나 근접했는지 확인할 수 있으며, 필요하다면 조정도 할 수 있다.
(p75)
예광탄 코드 접근 방법에는 여러 장점이 있다.
- 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다
- 개발자가 들어가서 일할 수 있는 구조를 얻는다
- 통합integration 작업을 수행할 기반이 생긴다
- 보여줄 것이 생긴다
- 진행 상황에 대해 더 정확하게 감을 잡을 수 있다
(p74 ~ p76) - 프로토타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격 중 일부가 된다. 프로토타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집과 같은 것이다.
(p79)
Topic 13 프로토타입과 포스트잇
- 프로토타이핑으로 조사할 대상은 무엇인가? 위험을 수반하는 모든 것이다.
프로토타이핑은 학습 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다.
(p81) - 사실 아키텍처를 프로토타이핑할 때는 코드를 작성하지 않고 화이트보드, 포스트잇, 인덱스카드 등을 사용해도 된다. 프로토타이핑의 목적은 전체적으로 시스템이 어떻게 동작할지에 대해 감을 잡는 것이다. 다시 말하지만, 세부 사항은 무시한다.
- 프로토타입을 코드로 만들 때는 시작하기 전에 항상 모든 사람에게 여러분이 폐기 처분할 코드를 작성하고 있다는 사실을 이해시켜야 한다.
(p83)
Topic 14 도메인 언어
- 실용주의 프로그래머라면 어떤 경우에는 한 차원 더 나아가서 그 도메인의 실제 어휘와 문법, 의미론을-즉, 그 도메인의 언어를-사용해서 프로그래밍할 수도 있다.
Tip 22 문제 도메인에 가깝게 프로그래밍하라.
(p85) - 내부 도메인 언어의 단점은 호스트 언어의 문법과 의미론을 따라야만 한다는 것이다.
외부 언어는 이런 제약이 없다. 여러분이 정의하려는 언어의 파서parser를 만들기만 하면 된다.
(p90) - 기본적으로는, 가능하다면 YAML이나 JSON, CSV처럼 널리 통용되는 외부 언어를 사용하라. 그게 아니라면 내부 언어를 고려하라. 단, 외부 언어 도입은 애플리케이션의 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천한다.
(p91)
Topic 15 추정
- 어떤 의미에서 모든 답은 추정치다. 단지 어떤 답이 다른 답보다 좀 더 정확할 뿐이다.
누군가 추정치를 물었을 때 스스로 물어보아야 할 첫 번째 질문은 여러분의 답변이 사용될 상황이 무엇인지다. 질문자가 매우 높은 정확도의 답을 요구하는가, 아니면 단순히 큰 그림만을 요구하는가?
추정치는 어디에서 나오는가
- 무엇을 묻고 있는지 이해하라
어떤 종류의 추정을 하건 첫 단계는 상대방이 무엇을 묻고 있는지 이해하는 것이다. 앞서 이야기한 정확도뿐 아니라 도메인에 존재하는 조건scope에 대해서도 감을 잡을 필요가 있다 - 시스템의 모델을 만들어라
- 모델을 컴포넌트로 나눠라
이렇게 대부분의 컴포넌트에는 각 컴포넌트가 어떻게 전체 모델에 기여하는지를 나타내는 매개 변수가 있다. 이 단계에서는 일단 매개 변수를 찾기만 하면 된다. - 각 매개 변수에 값을 할당하라
- 답을 계산하라
- 여러분의 추정 실력을 기록하라
(p96 ~ p99)
프로젝트 일정 추정하기
- 모든 PERT 과업은 낙관적 추정치와 가장 가능성이 높은가장 가능성이 높은 추정치, 비관적 추정치를 갖는다. 과업을 의존성에 따라 네트워크 형태로 배열한 후, 간단한 통계 기법을 사용하여 전체 프로젝트의 예상 최소 및 최대 소요 시간을 계산한다.값을 범위로 추정하는 건 추정 오류를 피할 수 있는 훌륭한 방법이다.
- 가끔은 프로젝트의 일정을 정할 수 있는 방법이 해당 프로젝트를 경험해 보는 것뿐일 때가 있다
Tip 24 코드와 함께 일정도 반복하며 조정하라.
(p100 ~ p101) - 누군가 추정해 달라고 하면 뭐라고 대답해야 할까? 나중에 연락드릴게요.나중에 연락드릴게요.라 말해야 한다. 잠시 손을 멈추고 시간을 내어 이번 항목에서 설명한 단계를 밟아 나간다면 대부분의 경우 더 좋은 추정치를 얻을 수 있을 것이다
(p102)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
- 처음부터 완벽한 것은 없다. 언제나 변화가능성을 염두에 두자. 고치기 쉬운 코드도, 중복을 줄이는 것도 더 나은 변화과정을 더욱 쉽게 거쳐가기 위한 것!
- 코드가 독립적인 모듈이 되도록 쪼개고 쪼개자!! 서로 영향을 주지 않는 코드들은 미래의 나를 더 편하게 할 것이다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 필요한 컨텍스트context를 모듈에 명시적으로 넘겨주면 코드를 이해하고 유지 보수하기 쉬워진다.
(p62) - 객체 지향 언어와 함수형 언어의 직교성은 어떻게 다를까? 이런 차이가 언어 자체에 내재된 것일까 아니면 사람들이 언어를 사용하는 방법이 다른 것일까?
(p66) - 스크립트 언어는 또한 저수준low-level의 요소들을 새로운 조합으로 엮어낼 때 접착제로 쓰기 좋다. 이러한 접근 방식을 취한다면 기존의 컴포넌트들을 빠르게 조합해 이들이 어떻게 동작하는지 볼 수 있을 것이다.
(p82)
오늘 읽은 다른사람의 TIL
pending...