[책] 실용주의 프로그래머 2장 실용주의 접근법

**

3월 19일 토요일 정신 못차리고 쉬다가 2일차 분량의 책을 늦게 읽었고 TIL을 작성하지 못하였다.

3~4일차(2장) 분량은 빠른 TIL 정리를 위하여 중간중간 적고 싶은 내용과 내 생각을 함께 작성 해본다.

**

실용주의 프로그래머

The Pragmatic Programmer

 

2장. 실용주의 접근법(p37)

A PragmaticApproach

 

Topic 8. 좋은 설계의 핵심(p38)

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

ETC(easier to change)는 규칙이 아니라 가치.

소스를 언제 누가 보더라도 바꾸기 쉽도록 작성하자.

 

Topic 9. DRY: 중복의 해악(p41)

프로그래머로서 우리는 지식을 수집하고, 조직하고, 유지하며, 통제한다.

우리는 지식을 명세로 문서화하고, 실행 코드를 통해 그 지식에 생명을 부여한다.

그리고 그 지식으로부터 테스트 중에 점검할 사항들을 얻는다.

유지보수는 출시되었을 때 시작하는 별개의 활동이 아니라 전체 개발 과정의 일상적인 부분이다.

유지보수를 쉽게 만드는 길은 DRY 원칙을 따르는 것이라 생각한다.

모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.

Tip 15. DRY: 반복하지 말라 (Don't Repeat Yourself)

DRY는 코드 밖에서도

이것은 단지 소스 코드에서만 국한되는 것은 아니다.

DRY는 지식의 중복, 의도의 중복에 대한 것이다.

코드의 중복

(코드는 추후 추가필요..)

코드 한곳을 수정할 때 다른 여러곳을 수정해야 한다면

최대한 중복을 없애보자 (고객사 요청에 따라 100% 없애지는 못할지도..)

모든 코드 중복이 지식의 중복은 아니다

동일한 코드라 할지라도 각각 서로 다른 것을 검증하고 있다면,

그것은 우연이지 중복이 아니다.

문서화 중복

주석에 모든 내용을 담는다고 해서 좋은 것은 아니다.

소스 코드에서 특정 상수를 수정할 때 주석에서도 수정해야 한다면

언젠가 주석과 코드간 격차가 생길 것이다.

함수 이름이 함수가 하는 일을 잘 알려줄 수도 있다.

데이터의 DRY 위반

개발을 진행하다 보면 나중에는 성능상의 이유로 DRY 원칙을 위배할 수도 있을 것이다.

모듈을 통해 제공되는 모든 서비스는 일관된 표기법(notation)으로 사용할 수 있어야 한다. 저장한 값으로 구현되었건, 계산을 통해 구현되었건 상관없이. - 버트런드 마이어(Bertrand Meyer)

표현상의 중복

내부 API에서 생기는 중복

외부 API에서 생기는 중복

데이터 저장소와의 중복

개발자 간의 중복

똑같은 일을 하는 코드가 서로 다른 곳에서 몇년이 지나고서야 발견될 수 있다.

많은 의사소통으로 유대가 돈독한 팀을 만들어서 대처해야 한다.

서로 정보 공유를 할 수 있는 소프트웨어를 사용하고

짧은 일일 회의를 생활화 하거나

정보를 정리하고 공유할 수 있는 인원을 주기적으로 정하는 등

여러 방안을 생각해볼 필요가 있다.

Tip 16. 재사용하기 쉽게 만들어라.

뭔가를 직접 만드는 것보다

기존의 것을 찾아내고

재사용하기 쉬운 환경을 조성해야 한다.

단, 어려운 방법은 실패할 확률을 높일 것이다.

 

Topic 10. 직교성(p54)

직교성이란

일종의 독립성이나 결합도 줄이기(decoupling) ?!

비직교적인 시스템 - 헬리콥터 조종

직교성의 장점

Tip 17. 관련 없는 것들 간에 서로 영향이 없도록 하라.

직교적인 시스템은 생산성 향상과 리스크 감소라는 두 가지 큰 장점이 있다.

생산성 향상

리스크 감소

설계

모듈식, 컴포넌트 기반, 계층(layer).

시스템은 서로 협력하는 모듈의 집합으로 구성되어야 하고,

각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다.

특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?

> 답은 하나여야 한다.

>> 말 자체는 이상적이지만..가능한 하나의 모듈에만 영향을 미쳐야한다)

자신의 힘으로 제어할 수 없는 속성에 의존하지 말아라.

툴킷과 라이브러리

외부에서 만든 툴킷이나 라이브러리를 도입할 때 시스템의 직교성을 해치지 않는지 주의 깊게 살펴보자.

코딩

코드의 결합도를 줄여라.

전역 데이터를 피하라.

유사한 함수를 피하라.

자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라.

테스트

직교적으로 설계하고 구현한 시스템은 테스트하기 더 쉽다.

문서화

정말 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있을 것이다.. (?! 흠)

직교적으로 살아가기

앞서 말한 원칙들을 지킨다면 개발하고 있는 시스템이 더 유연하고 이해하기 쉬워질 것이다.

디버깅, 테스트, 유지 보수 또한 쉬워질 것이다.

(연습 문제 1~2 는 추후 기재)

 

Topic 11. 가역성(p66)

당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다.

- 에밀 오귀스트 샤르티에(Emil-Auguste Chartier), <Propos sur la religion(종교론)>

가역성

Tip 18. 최종 결정이란 없다.

유연한 아키텍처

Tip 19. 유행을 좇지 말라.

Topic 12. 예광탄(p71)

준비, 발사, 조준 ...... - 미상 (?!?)

어둠 속에서 빛을 내는 코드

Tip 20. 목표물을 찾기 위해 예광탄을 써라.

예광탄 코드 접근 방법에는 여러 장점이 있다.

사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.

개발자가 들어가서 일할 수 있는 구조를 얻는다.

통합(Integration) 작업을 수행할 기반이 생긴다.

보여줄 것이 생긴다.

진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

예광탄이 언제나 목표물을 맞히는 것은 아니다.

예광탄 코드 대 프로토타이핑

Topic 13. 프로토타입과 포스트잇(p79)

프로토타이핑 대상

아키텍처

기존 시스템에 추가할 새로운 기능

외부 데이터의 구조 혹은 내용

외부에서 가져온 도구나 컴포넌트

성능 문제

사용자 인터페이스 문제

Tip 21. 프로토타이핑으로 학습하라.

프로토타입을 어떻게 사용할 것인가?

정확성

완전성(completeness)

안정성

스타일

아키텍처 프로토타이핑

 

주요 영역의 책임이 잘 정의되었고 적절한가?

주요 컴포넌트 간의 협력 관계가 잘 정의되었는가?

결합도는 최소화했는가?

중복이 발생할 만한 곳이 있는가?

정의된 인터페이스와 제약 사항은 수용할 만한가?

각 모듈이 실행 중에 필요한 데이터에 접근할 수 있는 경로를 갖고 있는가?

모듈에 데이터가 필요한 시점에 데이터 접근이 가능한가?

프로토타입 코드를 사용하지 않도록 하려면?

(연습 문제 3 은 추후 기재)

Topic 14. 도메인 언어(p85)

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

- 루트비히 비트겐슈타인(Ludwig Wittgenstein)

Tip 22. 문제 도메인에 가깝게 프로그래밍하라.

실세계 도메인 언어의 예

(몇가지 사례 추후 기재)

RSpec (Ruby용 테스트 라이브러리) - 코드에서 기재(expect)하는 동작을 테스트에 표현하도록 만들어졌다.

(https://rspec.info)

큐컴버(Cucumber) - 프로그래밍 언어에 종속되지 않은 테스트를 정의할 수 있다.

(https://cucumber.io)

피닉스 라우터(Phoenix router) - 들어오는 HTTP 요청을 코드의 핸들러(handler) 함수로 전달하는 라우팅 도구.

(https://phoenixframework.org)

앤서블(Ansible) - 소프트웨어를 설정하는 도구

(https://www.ansible.com)

도메인 언어의 특성

내부와 외부 언어의 장단점

손쉽게 만드는 내부 도메인 언어

(연습 문제 4~8 은 추후 기재)

Topic 15. 추정(p94)

Tip 23. 추정으로 놀람을 피하라

얼마나 정확해야 충분히 정확한가?

추정치는 어디에서 나오는가?

무엇을 묻고 있는지 이해하라.

시스템의 모델을 만들어라.

모델을 컴포넌트로 나눠라.

각 매개 변수에 값을 할당하라.

답을 계산하라.

여러분의 추정 실력을 기록하라.

프로젝트 일정 추정하기

불확실성을 줄이는 두 가지 기법을 살펴보자.

미사일에 페인트칠하기

프로그램 평가 검토 기법(Program Evaluation Review Technique, PERT)

 

코끼리 먹기

점증적 개발(incremental development)

요구 사항 확인하기

위험을 분석하고 위험도가 높은 부분을 우선 하기

설계, 구현, 통합

사용자와 함께 검증하기

Tip 24. 코드와 함께 일정도 반복하며 조정하라.

누군가 추정해 달라고 하면 뭐라고 대답해야 할까?

 

(연습 문제 9~10 은 추후 기재)