<실용주의 프로그래머>

블로그 옮겼습니다! 🡒 integer.blog

The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition
by Thomas David, Hunt Andrew, 2020

이 책은 현재 총원 4명의 개발팀 팀원들과 함께 스터디를 하기 위해 읽은 책이다.

각자 책을 읽어 오고 총 3회로 걸쳐서, 회당 2시간~2시간 30분씩 스터디를 진행했다.
같은 주제에 대해 (의견이 있는 경우) 각자의 생각을 공유하고 서로 질답하는 방식으로 진행했다.
결과적으로 개발팀의 첫 스터디 혹은 book review를 함께 하기에 가장 적합한 책이 아닌가 싶다.

최근에 안정적인 투자를 받았지만, 개발 팀원은 4명 뿐인 초기 스타트업이고 팀원간에 맞춰가야할 것들이 많은 상황이라
책에서 이야기하는 개발에 대한 기본적인 주제들을 함께 이야기하고, 서로의 생각을 공유하고 싱크를 맞추어 나가기에 적합했다.

개인적으로는 그동안 오해하고 있던 개념들을 바로 잡을 기회가 되었고,
각 주제에 대하여 다양한 경험을 가진 팀원들의 생각을 엿들을 수 있어서 유익했다.

줌인터넷에서 동기들(남준이, 희정이)과 2019년에 JPA 스터디를 한 이후 처음 하는 스터디였는데,
역시 생각을 공유하는 과정에서 내 생각이 정리되기도 하고,
미처 생각하지 못한 부분을 엿듣고 생각의 지평을 넓힐 수 있어서 좋았다.

밑줄 친 문장들

1. 모든 개발 과정에서, 매일, 여러분이 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다. 절대 기계적으로 일하지 말라. 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라. (p.21)
2. 실용주의 프로그래머는 직면한 문제 너머를 고민한다. 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다. (p.1)
3. ‘깨진 창문’을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. (p.9)
4. 지식 포트폴리오 만들기 (p.21)
   • 주기적인 투자
     • 금융 투자에서와 마찬가지로 여러분의 지식 포트폴리오에 소량으로라도 주기적으로 투자해야 한다.
   • 다각화
     • 더 여러 가지를 알수록 자신의 가치는 더욱 높아진다. 기본적으로 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야 한다.
     • 하지만 거기서 멈추지 말라. 컴퓨터 분야의 지형은 빠르게 변한다. (중략) 더 많은 기술에 익숙하다면 변화에 더 잘 적응할 수 있을 것이다.
   • 리스크 관리
     • 기술은 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 다양한 스펙트럼 위에 존재한다.
     • 여러분의 기술 달걀을 모두 한 바구니에 담지 말라.
   • 검토 및 재조정
     • 이 산업은 매우 동적이다. 지난달부터 탐구하기 시작한 인기 있던 기술이 한 달 만에 완전히 찬밥이 될지도 모른다.
5. API가 아닌 코드에 주석을 쓸 때는 왜 이렇게 되어 있는지, 즉 코드의 용도와 목적을 논해야 한다. 어떻게 동작하는지는 코드가 이미 보여 주기 때문에 이에 대해 주석을 다는 것은 사족이다. (p.34)
6. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라. (p.40)
7. DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다. (p.44)
8. 코드는 동일하지만 두 함수가 표현하는 지식은 다르다. 두 함수는 각각 서로 다른 것을 검증하고 있지만, 우연히 규칙이 같은 것뿐이다. 이것은 우연이지 중복이 아니다. (p.47)
9. 이렇게 아키텍처가 변덕스러운 환경에서 어떻게 계획을 세울 수 있겠는가? 못한다. 여러분이 할 수 있는 것은 바꾸기 쉽게 만드는 것이다. 외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라. 여러분의 코드를 여러 컴포넌트로 쪼개라. 결국에는 하나의 거대한 서버에 배포하게 되더라도, 이 방식이 거대한 단일 모듈 애플리케이션을 가져다 쪼개는 것보다 훨씬 더 쉽다. (우리도 뼈저린 경험을 통해 배웠다.) (p.70)
10. 일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다. (p.161)
11. 묻지 말고 말하라(Tell, Don’t Ask, TDA.) 이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다는 것이다. (p.186)
12. 전역적이어야 할 만큼 중요하다면 API로 감싸라. (p.191)
13. ‘동시성concurrency’은 둘 이상의 코드 조각이 실행될 때 동시에 실행 중인 것처럼 행동하는 것이다. 그리고 ‘병렬성parallelism’이란 실제로 동시에 실행되는 것이다. (p.241)
14. <리팩터링>에서 마틴 파울러는 ‘리팩터링’을 다음과 같이 정의한다. 밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법. (p.301)
15. 리팩터링이 필요한 코드를 일종의 ‘종양’이라고 생각하자. (p.304)
16. 무언가를 테스트하기 좋게 만들면 결합도도 낮아진다. (p.310)
17. 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다. 사실 이게 우리의 가치가 가장 빛나는 부분일 것이다. (p.351)
18. 생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다. - Alfred North Whitehead (p.392)