실용주의 프로그래머(1~2장)

실용주의 프로그래머

실용주의 철학

이 부분은 큰 틀에서 실용주의를 위해 기본적으로 갖춰야 할 철학들이 담겨있다.

Topic 1 당신의 인생이다

이 토픽에서는 주도적으로 행동해야 함을 강조한다.

Topic 2 고양이가 내 소스코드를 삼켰어요

실용주의 철학의 초석인 책임에 대해서 이야기한다. 책임을 진다는 건 기본적으로 솔직해야 하고 결과를 내가 감당해야 하는 것이다. 따라서 할 수 있는 일과 할 수 없는 일을 구분할 줄도 알아야 한다.

예전에 나는 책임진다는 게 나에게 주어진 일은 어떻게든 내가 해야 한다고 생각했다. 물론 이것도 맞는 말이지만 집단에서 일이라는 것은 결국 내가 한 일이 집단 전체에 영향을 주기 때문에 나의 한계를 명확히 알고 알릴 줄도 알아야 했다. 그렇게 상황을 공유하고 조율하는 것도 내 일에 책임이 있기에 해야 되는 일이다.

Topic 3 소프트웨어 엔트로피

깨진 창문에 대한 이야기. 관리하지 않은 대상은 결국 더 망가지게 되어있다. 집단에서 심리는 이미 지저분한 것에 대해 신경 쓰지 않게 된다. 그래서 최대한 건강한 상태를 유지하는 게 좋다

Topic 4 돌멩이 수프와 삶은 개구리

천천히 상황이 호전되는 경우와 악화되는 경우의 예시. 삶은 개구리와 깨진 창문의 경우 차이가 있는데, 깨진 창문은 다른 사람들이 아무도 주의를 기울이지 않는다는 걸 알기에 사람들이 엔트로피에 대항해 싸울 의지 자체가 없는 거고, 개구리의 상황은 인지를 못하게 서서히 안 좋아진다는 것이다.

그렇기에 항상 주변을 살피고 의식하는 습관을 들이는 게 좋다.

Topic 5 적당히 괜찮은 소프트웨어

완벽한 소프트웨어와 요구사항을 달성한 적당한 소프트웨어 간의 비교라 보았다. 현실 세계에서는 품질을 완벽히 통제할 수 없다. 소프트웨어는 결국 사용자의 니즈 충족이 중요하다 본다. 프로젝트에서 제품을 완성시키고 피드백을 빠르게 받는 게 더 나을 수 있다. 그래서 쓸데없는데 시간 계속 쓰면서 완벽을 생각하는 게 오히려 독이 될 수 있음

 

Topic 6 지식 포트폴리오

실제 투자하는 것처럼 나 자신의 성장을 위해 투자하는 전략과 원칙 중요성을 정리했다.

• 주기적인 투자
• 다각화
• 리스크 관리
• 싸게 사서 비싸게 팔기
• 검토 및 재 조정

구체적인 방식으로는

• 매년 새로운 언어를 최소 하나는 배워라
• 기술 서적을 한 달에 한 권씩 읽어라
• 기술서적이 아닌 책도 읽어라
• 수업을 들어라
• 다른 환경에서 실험해 봐라
• 최신흐름을 항상 체크해라

마지막으로 비판적 사고에 관한 강조

• 왜냐고 다섯 번 묻기
• 누구에게 이익이 되는가
• 어떤 맥락인가
• 언제 혹은 어디서 효과가 있는가
• 왜 이것이 문제인가

Topic 7 소통하라!

이번 장의 마지막 토픽은 내가 가장 약하고 중요하다고 생각하는 커뮤니케이션을 위한 토픽이다.

여기에 문서화도 소통에 포함되는데 시간이 지나면서 이 중요성을 많이 느껴서 웬만하면 다 기록하려고 한다.

의사소통에 관한 요약은 다음과 같다

• 청중을 알라
  • 상대방에 따라 내용은 많이 달라진다. 기술적인 내용을 아예 무관한 사람한테 백날해도 지루할 뿐
• 말하고 싶은 게 무언지 알라
  • 내가 말하려는 걸 내가 가장 잘 알아야 한다. 쓰기 전 줄거리를 생가해보자
• 때를 골라라
  • 대화의 대상은 사람이다. 언제 말하는지도 굉장히 중요한 요인이다.
• 스타일을 골라라
  • 말하는 대상을 생각해서 이해하기 쉽게 얘기하는 게 효율적이겠지?
• 멋져 보이게 하라
  • 멋져 보이게만 하는 게 아니다. 내용물만큼 데코레이션도 중요한 법
• 청중을 참여시켜라
  • 결국 의사소통도 목적이 있는 행위다. 청자가 있는 행위 따라서 피드백을 받으면 좋겠지?
• 경청하라
• 응답하라
• 코드와 문서를 함께 둬라

위의 내용은 막상 보면 당연하다 볼 수 있지만 저걸 다 지키기는 너무 어렵다. 따라서 천천히 습관적으로 하도록 노력해야겠다.

실용주의 접근법

2장에서는 개발하면서 쓰이는 프로세스, 아이디어, 접근법에 대해 이야기한다.

Topic 8 좋은 설계의 핵심

여기서는 딱 한 가지를 강조한다 ETC라고 Easier to change. 이게 전부라고 한다. 소프트웨어라는 틀에서 생각하면 ETC는 선택의 갈림길에서 도움을 주는 안내자라 한다. 그니까 뭐 작업을 하다가 고민이 되면 일단 지금 하는 행동이 시스템을 바꾸기 쉽게 했냐? 어렵게 했냐? 를 생각하면 된다고 한다.

왜 단일책임원칙이 유용한가? 요구사항이 바뀌더라도 모듈하나만 바꾸면 되니까 결국 ETC

왜 이름 짓기가 중요한? 왜 읽기 좋은 코드가 좋은 코드인가? 코드 바꾸려면 코드 읽기가 쉬워야 하니까 이것도 결국 ETC

아무튼 ETC

Topic 9 DRY: 중복의 해악

여기서는 중복의 문제를 전반적으로 살펴보고 중복을 다루는 일반적인 전략을 제시하는데, 그냥 코드의 중복이 아니라 지식의 중복을 이야기한다. 그니까 코드의 중복보다 더 큰 집합이다.

그래서 한 가지 기억에 남는 부분은 검증 코드를 작성할 때 검증하는 내용은 다른데 검증하는 코드의 형태가 유사하다고 단순히 줄여버리면 안 된다는 거다. 두 함수가 표현하는 지식이 다르기 때문이다.

def validate_age(value):
	validate_type(valie, :integer)
	validate_min_integer(value,1)

def validate_quantity(value):
	validate_type(value, :integer)
	validate_min_integer(value,1)

	// 코드 형태는 똑같은데 내용이 다름 굳이

다음으로는 문서화 중복이야기를 하면서 코드에 주석 다는 예시가 나오는데, 코드에 쓸데없는 주석 달면 괜히 나중에 고칠게 더 많아지니까 코드 자체로 이해하기 쉽기 함수명이나 변수를 잘 써야 한다고 한다. 이 부분은 다른 책에서도 자주 나오는 내용이다.

나중에 작업한 일들에 대해 문서화할 때 코드에 대한 부분보다는 작업할 때 고민한 부분위주로 적어야겠다.

데이터 저장소와의 중복이라는 파트에서는 영속성 프레임 워크에 대해 나오는데 장고 ORM 이 이런 일을 하는 게 아닌가 라는 생각이 든다.

Topic 10 직교성

직교성은 독립적 시스템이 갖는 특징인데, 설계, 빌드, 테스트 확장을 쉽게 해준다고 한다. 객체지향 공부하면 볼 수 있는 의존성 개념과도 연관이 있다. 의존성 주입하는 이유도 이런 직교성을 높이기 위함이라고 보인다. 강한 결합을 갖는 모듈들은 직교성이 낮다고 볼 수 있다.

읽어보면 직교성을 높이면 좋은 점 밖에 없다. 그도 당연한 게 컴포넌트, 모듈 간 독립성이 높아지니 테스트하기도 편하고 유지 보수 하기도 편할 것이다. 코딩에 있어서 몇 가지 기법을 소개해 준다.

• 코드의 결합도를 줄여라
  • 객체의 상태를 바꿀 필요가 있다면 객체가 직접 상태를 바꾸게 하라(캡슐화)
• 전역 데이터를 피하라
  • 불필요한 싱글톤 패턴도 결합력을 높인다.
• 유사한 함수를 피하라
  • 중간에 알고리즘만 다른 패턴의 코드는 전략 패턴으로 바꿀 수 없는지 고민해 봐라

Topic 11 가역성

이 부분은 예전에 가끔 생각했던 문제들이다. 결국 개발이 현실 세계의 문제를 푸는 작업이다 보니까 당연히 복잡계의 특성을 보여주는 거 같다.

프로젝트가 시간이 지나면서 여러 결정들을 통해 많이 변했을 텐데 그 과정에서 앞에서 소개했던 유연하고 적응 가능한 소프트웨어를 만들지 않았다면 되돌리기 힘든 상황을 많이 만날 것이다. 현실적으로 최선의 결정을 늘 내릴 수 없기 때문에 최대한 유연한 소프트웨어를 설계하려고 노력해야 한다.

책에서 현실은 계속 변화하기 때문에 결정이 바뀌지 않을 것이라고 가정하고 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다고 한다. 이 부분은 ‘안티프래질’이 생각이 많이 났다. 결국 복잡계에서는 특정 상황에 최적화된 답은 결국 시간이 지나면서 프래질 하게 되어있기 때문에 결합력을 낮춘 유연함은 안티프래질함을 추구하는 것 같다.

Topic 12 예광탄

예광탄이란 사수가 지금 잘 맞추고 있는지 직관적으로 알 수 있게 해 준다. 가역성에서 언급되었던 문제들을 해결하기 위한 접근 방식으로 처음부터 모든 걸 완벽하게 작업하기보단 일단 빠르게 요구사항을 파악하고 작업을 하면서 애프리케이션이 전체적으로 어떻게 연결되는지를 알 수 있게 해 준다. 사용자에게는 애플리케이션이 어떻게 상호작용 하는지 보여주고, 개발자에게는 아키텍처의 골격을 제시한다.

여기서 내가 이해한 바로는 애플리케이션의 골격을 만드는데 정말 필요한 골격을 만든다는 느낌을 받았다. 책상을 만들 때 일단 다리랑 판자를 결합해서 책상처럼 보이게 하는 것과 비슷하다고 이해했다.

또한 여기서는 프로토타입과는 다르다고 이야기하는데 프로토타입은 특정 측면을 미리 알아보기 위해 작업하는 것이다. 프로토타입은 본체가 될 수 없다. 하지만 예광탄 코드는 계속 사용될 코드다.

프로토타입에 대한 자세한 내용은 다음 장에서 이어진다.

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

여기서는 프로토타입에 대해 더 자세하게 나오는데, 프로토타이핑의 목적은 전체적으로 시스템이 어떻게 동작할지에 대해 감을 잡는 것이다. 프로토타입은 꼭 코드일 필요는 없다. 화이트보드나 포스트잇 또한 대상에 따라 다른 툴을 사용해도 좋다. 여기서 대상에 대해 간단히 정리했다.

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

또한 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜 프로토타입을 만드는 게 맞는지 자문해 보고 이때는 예광탄 방식의 개발에 더 적절할 것이라고 한다.

Topic 14 도메인 언어

DSL 예시와 함께 특징에 대해서 알려준다. 도메인 언어 개념에 익숙하지 않아서 뒤에 연습문제가 도움이 되었다. 외부 도메인, 내부 도메인을 쓸 거냐 당연히 간단한 문제도 아니고 정해진 게 당연히 없다. 여기서는 도메인 언어를 만들면 어느 정도 추가비용이 발생하니까 그걸 절감할 수 있는 확신이 있어야 된다고 한다. 그러면서 기본적으로는 Yaml, JSON, CSV, 처럼 외부 도메인을 사용하는 게 낫고 그게 아니면 내부 도메인을 사용하라고 한다.

파이썬에서는 내부 도메인 언어의 예시를 하나 찾아보자면 데코레이터 기능을 사용해서 데코레이터 패턴을 구현한것을 볼 수 있다. 또한 이런 데코레이터 기능은 장고나 플라스크에서 URL 경로와 함수를 연결하는 라우터를 구현하는 데 사용되는 걸 볼 수 있다.

Topic 15 추정

이 파트도 나에게 새롭게 할 일을 만들어 주었다. 나는 뭔가를 추정한다는 걸 이렇게 까지 생각을 안 해봤다. 근데 읽고 보니 상당히 중요한 작업이라는 걸 알게 되었다. 결국 여기서 제안하는 추정의 단계가 보통 문제를 만났을 때 하는 사고방식과 비슷하기 때문에 책에서 말하는 추정 실력을 기록하는 연습을 계속해야 할 거 같다.

추정을 하기 전에 일단 비슷한 일을 한 사람에게 물어보던가 비슷했던 일을 찾아봐야 한다. 그럼 훨씬 수월하게 추정치를 찾을 수 있다고 한다.

추정하는 단계 마지막 답을 계산하는 단계에서 언뜻 이상해 보이는 답을 얻는다면 그 답을 쉽게 버리면 안 된다고 한다. 왜냐면 만약 계산이 정확하다면 문제를 잘못 이해했거나 모델이 잘못되었을 가능성이 있기 때문에 굉장히 중요한 정보라고 말한다.

참고 및 출처: <실용주의 프로그래머(20주년 기념판)> (데이비드 토머스, 앤드류 헌트 지음, 정지용 옮김, 김창준 감수 인사이트 , 2022)