[실용주의 프로그래머] TIL (2022.03.20)

실용주의 프로그래머 (The Pragmatic Programmer)

오늘 TIL 3줄 요약

• 코드는 수정 가능하게
• 중복은 피하고 재사용 쉽게
• 프로젝트 단계별 진행을 더 좋게 더 구체적으로 분명하게

TIL (Today I Learned) 날짜

2022.03.20

오늘 읽은 범위

2장. 실용주의 접근법 (A Pragmatic Approch)

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

ETC 원칙 Easier to Change
바꾸기 더 쉽게

좋은 설계는 나쁜 설계보다 바꾸기 쉽다.


단일 책임 원칙 Single Responsibility Priciple
하나의 모듈은 한 가지 책임만 져야한다는 설계원칙 (SOLID 5가지 설계 원칙 중 S)

(p.39)

극단적으로 보이겠지만 사실 여러분은 모든 코드를 교체할 수 있게 작성해야 한다. 교체 가능하게 작성하라는 말은 코드의 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다. (p.40)

프로그래머는 늘 유지보수 모드에 있다. 유지보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다. (p.42)


DRY 원칙 Don't Repeat Yourself
반복하지 말라.
모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위있게 표현되어야 한다.
지식의 중복, 의도의 중복! 똑같은 개념을 다른 곳 두군데에서 표현하면 안된다는 것이다.
(p.44)


직교성 Orthogonality
그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 말한다. 두개의 선은 독립적이다.컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기 decoupling을 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
(p.55)

직교성 장점 : 생산성 향상과 리스크 감소

직교성 설계 : 모듈식, 컴포넌트기반, 계층

(p.58)

직교성 유지 기법 : 결합도를 줄이기, 전역 데이터를 피하기, 유사 함수를 피하기

싱글턴 패턴 sigleton pattern
특정 클래스 객체가 단 하나의 인스턴스만을 갖도로고 보장해준다. (GoF 디자인 패턴)
(p.63)

데이터베이스라는 개념을 올바르게 추상화하여 영속성을 하나의 서비스로 제공하도록 만들었다면 달리는 도중에 말을 갈아탈 수 있는 유연성이 생길 것이다.
(p.68)


예광탄 Tracer Bullet
총알이 공기 중에 밝은 줄무늬의 궤적을 남기는 것
전에 만들어진 적이 없는 전혀 새로운 것을 만들고 있다면 더욱 그렇다. 움직이는 목표물을 맞히려면 실제 조건하에서 즉각적인 피드백을 받아야한다. 예광탄 개발

시스템을 정의하는 중요한 요구사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커보이는 곳을 찾아라.
(p.73)


프로토타입
최종 시스템의 어떤 특정한 측면을 탐사해보는 것이 목표다. 진짜 프로토타입 방식을 따른다면 프로토타입은 어떤 개념을 실험해보느라 대충 끼어 맞추어 구현한 것이므로 모두 버려야 한다. 그리고 실험과정에서 얻은 교훈을 바탕으로 코드를 새로 작성한다.
(p.78)

소프트웨어 프로토타입도 위험요소를 분석하고 노출시킨 후, 이를 매우 저럼한 비용으로 바로 잡을 기회를 얻는 것이다.
(p.80)

프로토타입 대상 : 아키텍쳐, 기존 시스템에 추가할 새로운 기능, 외부 데이터의 구조 혹은 내용, 외부에서 가져온 도구나 컴포넌트, 성능문제, 사용자 인터페이스 설계

프로토타입 무시할 세부사항 : 정확성 (dummy 데이터 사용가능), 완전성 (작동만 하면 된다), 안정성 (오류 무시 가능), 스타일 (문서 많이)
(p.82)

프로토타입 --> 결국에는 폐기처분할 코드, 나무로 만든 자동차같은 것 (p.84)


도메인언어
실용주의 프로그래머라면 어떤 경우에는 한 차원 더 나아가서 그 도메인의 실제 어휘와 문법, 의미론을 사용해서 프로그래밍할 수 도 있다.
(p.85)

절약하는 것보다 더 많은 시간을 쏟지는 말라. 도메인 언어를 만들려면 프로젝트에 어느정도 추가 비용이 발생한다. 그럼에도 이를 상쇄할 만큼 비용을 절감할 수 있으리라는 확신이 있어야한다. 아마 길게 보고는 따져야 할 것이다.

내부 언어를 고려하라. 단, 외부 언어 도입은 애플리케이션 사용자가 직접 도메인 언어로 코드를 작성하는 경우에만 추천한다.

호스트 언어의 문법이 노출되어도 상관없다면 사용할 수 있는 편접이 있다. 메타 프로그래밍을 남발하는 대신 그냥 함수를 써서 구현하라.
(p.91)

추정 하는 법을 배우고 추정 능력을 계발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법같은 능력을 발휘할 수 있게 될 것이다.
(p.94)

추정에서 한 가지 재미있는 사실은 사용하는 단위가 결과의 해석에 차이를 가져온다는 것이다. 여러분이 전달하려는 정확도를 고려하여 답변의 단위를 선택하라.
(p.96)

요청 ->모델로 만들기 -> 모델을 컴포넌트로 분해 -> 매개변수를 찾고 값을 할당 -> 추정치 계산 -> 기록 -> 불확실성 줄이기
(~p.99)

프로그램 평가 검토 기법 Program Evaluation Review Technique PERT
모든 PERT 낙관적 추정치와 가장 가능성이 높은 추정치, 비관적 추정치를 갖는다. 과업을 의존성에 따라 네트워크 형태로 배열한 후, 간단한 통계 기법을 사용하여 전체 프로젝트의 예상 최소 및 최대 소요 시간을 계산한다. 값을 범위로 추정하는건 추정 오류를 피할 수 있는 훌륭한 방법이다.
(p.100)

점증적 개발 Incremental Development
기능을 매우 작은 단위로 나누어 아래 단계들을 반복
요구사항 확인, 위험분석/ 위험도가 높은 부분 우선,설계/구현/통합, 사용자와 함께 검증

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

' 파일을 저장할 때마다 "ETC?"라는 내용의 팝업을 띄우도록 설정하라. 그리고 팝업을 볼 때마다 방금 작성한 코드에 대해 생각해보라. 이 코드가 바꾸기 쉬운가? ' 적용해보기

'shy code' 이렇게 긍정적인 shy 라니!

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

• 믹스인, 이른 바인딩 대 늦은 바인딩
• 하스켈 사고 방식
• 내부 도메인언어 : 호스트 언어의 기능을 쓸 수 있는 장점, 호스트 언어의 문법과 의미론을 따라야하는 단점
• 외부 도메인 언어 : 제약이 없는 장점

오늘 읽은 다른사람의 TIL