실용주의 프로그래머(the pragmatic programmer) 20주년 기념판을 읽었다.
출퇴근길에 가볍게 1 회독했고 한번 정도 더 읽어볼 생각이다.
책에서는 저자의 개발에 대한 전반적인 팁을 서술한다.
대체로 white paper 스러운 느낌을 주지만 특히 인상 깊게 느낀 부분을 몇 개 적어본다.
예광탄(tracer bullet)은 불빛을 통해 총알이 날아가는 궤적이 보이는 탄환이다.
예광탄 개발 방법은 마치 예광탄이 타깃을 관통하듯 핵심적인 부분을 먼저 개발하고
점점 살을 붙여 나가는 개발 방법론이다.
이는 근본적으로 문제를 쪼개고 점진적 개발을 추구하는 현대적 아키텍처와 일맥상통한다.
MSA(micro service architecture), Agile, 기타 등등..
인간이 유지할 수 있는 컨텍스트는 유한하기에 이를 작은 단위로 쪼개고
차근차근 문제를 해결해 나가는 것 이다.
다음은 Topic 30 변환 프로그래밍이다.
이 토픽의 핵심적인 철학은 모든 프로그램은 입력을 출력으로 바꾸는 작업이라는 것이다.
위대한 엔지니어들은 데이터에 큰 의미를 가진다.
대표적으로는 1973년 튜링상 수상 강연인 Programmer as Navigator(항해자로서의 프로그래머)를 볼 수 있다.
자기 테이프 시대에서 하드 디스크 시대로 넘어오며 극초기의 데이터베이스 설계자인 Charles W. Bachman은
이 발표에서 순차적 디스크 접근시대를 벗어나며 관찰자에서 항해자로 프로그래머의 역할이 바뀌었다고 말한다.
Topic 30 변환 프로그래밍에서는 이런 순수성을 다시 일깨워준다.
우리가 다루어야 할 문제는 결국 데이터의 인풋과 아웃풋 사이의 현상이란 것이다.
데이터의 이동에 비즈니스 로직을 맞추면 프로그래머가 설계에 있어 이를 더 쉽게 이해할 수 있게 만든다.
Topic 44 이름 짓기는 우리가 이름을 어떻게 지어야 하는지에 대해, 이름의 의미에 대해 말한다.
코드를 짤 때 최대 난제인 변수명 짓기.. 요즘은 생성형 AI들이 아주 잘해준다지만 컨텍스트를 이해하지 못하면
아직도 답답한 경우가 많고, 남의 코드를 읽을 때에는 큰 도움이 되지 않는다.
어쩔 땐 과도한 이름 짓기가 불편하게 느껴지기도 한다. 예를 들어 요즘은 Ops가 너무 많다.
- DevOps
- SecOps
- DevSecOps
- DataOps
- FinOps
- GitOps
- AIOps
- MLOps
- ChatOps
그것만으로 문제가 되는가? 아니다. 용어는 우리가 소통하는 데 있어
DRY(Don't Repeat Yourself) 원칙을 지키게 해 준다.
하지만 용어라는 틀에 갇히는 순간 행위는 틀에 종속된다.
"우리는 GitOps라서 이렇게 하면 안 돼"
"우리는 AIOps를 실현하기 위해서 어떻게 해야 해"
용어의 등장은 그저 창시자가 정의하고픈 어떤 것에 붙인 이름일 뿐임에도
이에 갇혀 능동적인 행위를 막는다. 일종의 Cargo cult인 것이다.
사실은 용어도 어떤 요구사항에서 나왔으며, 조직에 따라 달라져야 한다.
전반적으로 무난하게 좋은 책이었고
꽤 흥미롭게 읽었다. 철학서에 가깝기에 가벼운 마음으로 읽었다.
다만 기술 용어들은 한글과 영어를 좀 더 크게 병용하면 더 좋았을 것 같다.
한글로 번역되어 익숙하지 않은 용어들은 오히려 책을 읽을 때 이물감을 느끼게 했다.
수많은 챕터 중에서도 적은 챕터에 대한 간략한 리뷰와 총평을 써봤는데
이 책을 볼까 말까 고민된다면 책에서 제공하는 수록 팁을 보길 바란다.
취향에 맞는 책인지 아닌지 판단할 수 있을 것이다.
수록 팁
- 자신의 기예(craft)에 관심을 가져라
- 자기 일에 대해 생각하라.
- 당신에게는 에이전시(agency)가 있다.
- 어설픈 변명 말고 대안을 제시하라.
- 깨진 창문을 내버려 두지 말라.
- 변화의 촉매가 돼라.
- 큰 그림을 기억하라.
- 품질을 요구 사항으로 만들어라.
- 지식 포트폴리오에 주기적으로 투자하라.
- 읽고 듣는 것을 비판적으로 분석하라.
- 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.
- 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
- 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
- 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
- DRY: 반복하지 말라 Don’t Repeat Yourself
- 재사용하기 쉽게 만들어라.
- 관련없는것들간에서로영향이없도록하라.
- 최종 결정이란 없다.
- 유행을 좇지 말라.
- 목표물을 찾기 위해 예광탄을 써라.
- 프로토타이핑으로 학습하라.
- 문제 도메인에 가깝게 프로그래밍하라.
- 추정으로 놀람을 피하라.
- 코드와 함께 일정도 반복하며 조정하라.
- 지식을 일반 텍스트로 저장하라.
- 명령어 셸의 힘을 사용하라.
- 에디터를 유창하게(fluency) 쓸 수 있게 하라.
- 언제나 버전 관리 시스템을 사용하라.
- 비난 대신 문제를 해결하라.
- 당황하지 말라.
- 코드를 고치기 전 실패하는 테스트부터.
- 그놈의(damn…) 오류 메시지 좀 읽어라.
- “select”는 망가지지 않았다.
- 가정하지 말라. 증명하라.
- 텍스트 처리 언어를 익혀라.
- 여러분은 완벽한 소프트웨어를 만들 수 없다.
- 계약으로 설계하라.
- 일찍 작동을 멈춰라.
- 단정문으로 불가능한 상황을 예방하라.
- 자신이 시작한 것은 자신이 끝내라.
- 지역적으로 행동하라.
- 작은 단계들을 밟아라. 언제나.
- 예언하지 말라.
- 결합도가 낮은 코드가 바꾸기 쉽다.
- 묻지 말고 말하라 Tell, Don’t Ask, TDA.
- 메서드 호출을 엮지 말라.
- 전역 데이터를 피하라.
- 전역적이어야 할 만큼 중요하다면 API로 감싸라.
- 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.
- 상태를 쌓아 놓지 말고 전달하라.
- 상속세를 내지 말라.
- 다형성은 인터페이스로 표현하는 것이 좋다.
- 서비스에 위임하라. Has-A가 Is-A보다 낫다.
- 믹스인으로 기능을 공유하라.
- 외부 설정으로 애플리케이션을 조정할 수 있게 하라.
- 작업 흐름 분석으로 동시성을 개선하라.
- 공유 상태는 틀린 상태다.
- 불규칙한 실패는 동시성 문제인 경우가 많다.
- 공유 상태 없는 동시성을 위하여 액터를 사용하라.
- 칠판으로 작업 흐름을 조율하라.
- 여러분 내면의 파충류에게 귀 기울여라.
- 우연에 맡기는 프로그래밍을 하지 말라.
- 사용하는 알고리즘의 차수를 추정하라.
- 여러분의 추정을 테스트하라.
- 일찍 리팩터링하고, 자주 리팩터링하라.
- 테스트는 버그를 찾기 위한 것이 아니다.
- 테스트가 코드의 첫 번째 사용자다.
- 상향식이나 하향식이 아니라 끝에서 끝까지(end-to-end) 만들어라.
- 테스트할 수 있도록 설계하라.
- 여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.
- 속성 기반 테스트로 가정을 검증하라.
- 단순함을 유지하고 공격 표면을 최소화하라.
- 보안 패치를 신속히 적용하라.
- 이름을 잘 지어라. 필요하면 이름을 바꿔라.
- 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
- 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.
- 요구 사항은 피드백을 반복하며 알게 된다.
- 사용자처럼 생각하기 위해 사용자와 함께 일하라.
- 정책은 메타데이터다.
- 프로젝트 용어 사전을 사용하라.
- 생각의 틀을 벗어나지 말고, 틀을 찾아라.
- 코드에 혼자 들어가지 말라.
- 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.
- 작고 안정적인 팀을 유지하라.
- 실현하려면 계획하라.
- 모든 기능을 갖춘 팀을 조직하라.
- 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
- 사용자에게 필요할 때 제공하라.
- 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
- 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
- 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.
- 버그를 심어 놓고 테스트를 테스트하라.
- 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.
- 버그는 한 번만 잡아라.
- 수작업 절차를 사용하지 말라.
- 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.
- 자신의 작품에 서명하라.
- 먼저, 해를 끼치지 말라.
- 쓰레기 가은 인간을 돕지 마라
- 결국 당신의 삶이다.삶을 사람들과 나누고, 삶을 축하하고, 삶을 만들어가라. 그리고 그걸 즐겨라