@Heebeom Kim

실용주의 프로그래머 책 리뷰 + 요약

the pragmatic programmer 1 Photo by James Pond on Unsplash

실용주의 프로그래머는 다른 책들과 달리 철학적인 요소를 깊게 풀어내고, 프로그래밍 관련 지식을 두루 담고 있어서 재미있게 읽은 책 중 하나이다. 지금껏 읽어왔던 개발 관련 도서들의 종합본 같은 느낌을 조금 받기도 했고 그 와중에도 핵심은 모두 들어가 있구나? 하는 느낌을 받았다. 특히 아주 많은 팁(+명언)들이 나와서 좋았다.

그렇다고 ‘클린코드’나 ‘소프트웨어 장인’처럼 가볍게 읽어도 이해가 될만한 책은 아니다. 생소한 용어도 좀 있고, 번역체가 결정적인 순간에 아쉬울 때가 있다. 가끔은 너무 추상적으로만 표현을 해서, ‘이 상황은 실제로 겪어보지 않았으면 이해하기 힘들겠는데?‘라는 우려도 있었다.

아무튼, 언젠가 다시 꺼내어볼 날이 있을 것 같아서 요약본을 작성했다.

실용주의 프로그래머

프로그래머에게 영향을 미치는 요소를 꼽자면 수도 없이 많겠지만, 실용주의 프로그래머는 무엇이 다른가? 태도, 스타일, 문제와 해법에 접근하는 철학에 차이가 있다. 문제를 큰 맥락에서 보려 노력하고, 똑똑한 절충안을 만들며, 정확한 사실에 근거한 결정을 내린다.

너무나 당연하다고, 잘 알고 있다고 생각할 수 있다. 하지만 아는 것과 실천하는 것에는 크나큰 차이가 있다.

책임을 져라

적어도 당신이 전문가라면, 변명 대신 대안을 제시해야 한다.

우리는 항상 많은 문제에 맞닥뜨린다. 수월하게 해결할 수 있는 문제도 있지만 제어가 불가능할 정도로 난해한 것들이 많다. 그때마다 어떻게 해왔는가? 해결 불가능한 문제에 두 손 두 발 들고 순순히 항복을 하는가? 경력에 스크래치가 나는 것만 같아 비겁하게 숨어버리는가?

우리는 이러한 위기에 직면할 때 솔직해져야 한다. 불가능함을 인정해야 한다. 나의 무지 또한 인정해야 할 수 있다. 거짓말을 했다간 오히려 더 큰 문제를 야기한다. 그리고 실수를 하였다면 나의 잘못된 판단을 정직하게 인정해야 한다.

변화해라

깨진 창문을 내버려두지 마라.

깨진 창문 이론이 주는 교훈은, 고쳐야 한다는 것이다. 지금의 설계가 나쁜 설계이고 형편없는 코드라는 건 팀원들 모두 알고 있다. 하지만 안다고 해서 문제가 해결되던가? 중요한 차이는 이걸 고치느냐 그냥 내버려 두느냐이다.

완벽은 존재하지 않는다

어떤 면에서 프로그래밍은 그림 그리기와 유사하다.

그림을 그리다 보면 조금이라도 더 나은 작품을 만들기 위해 집착이 생길 때가 있다. 때로는 아예 새로운 캔버스에 그릴 때도 있다. 멈춰야 할 타이밍을 잡지 못한다면 오히려 작업을 망쳐버리게 될 것이다.

프로그래밍도 마찬가지다. 완벽하지 않더라도 멈출 줄 알아야 한다. 이미 훌륭한 프로그램을 과도하게 다듬으려고 노력하다가 오히려 더 망칠 수 있다. 애초에 ‘완벽’은 존재하지 않는다.

자신에게 투자하라

자신의 가치를 높일 수 있는 것에 끊임없이 투자해야 한다. 새로운 언어를 익혀도 좋고, 기술 서적 읽기, 수업, 모임 참여 많은 방법이 있다. 그리고 그 가치를 증명하는 포트폴리오를 만들자.

종종 주변에서도 매년 다른 회사에 면접을 보는 사람이 있다. 꼭 이직을 원해서가 아니라 시장에서의 자신의 가치를 판단하기 위해서 면접을 보러 다닌다고들 하신다. 평가를 받는다는 건 두려운 일이다. 평가가 좋지 않을 때는 우울감마저 들 수 있다. 하지만 자신의 가치를 판단할 수 있어야 부족한 부분을 더 메울 수 있다.

실용주의 접근

소프트웨어 개발에서 어떻게 실용주의 접근을 할 수 있을까. 우리 모두가 이미 알고 있는 것들도 많다. 모두가 알고 있다는 건 그만큼 중요하다는 뜻일 것이다. 특히 이 장은 하나도 빠뜨릴 것이 없다. 개발자라면 누구나 지녀야 할 바이블 같은 느낌.. 

중복의 해악

명세가 바뀌었을 때, 동일한 기능의 중복된 코드가 어디 있는지 기억할 수도 있다.
하지만 이것은 기억하느냐 마느냐의 문제가 아니다. 단지 언제 잊어버릴 것인가 하는 문제이다.

DRY -  Don’t Repeat Yourself

모든 것은 변한다. 오늘 개발한 프로그램이 내일 바뀌지 않을 거라고 확신할 수 있을까? 명세가 바뀌고, 설계가 바뀌고, 모든 것이 바뀔 수 있다.

그렇다는 건 우리는 변화에 대응하기 쉬운 형태를 항상 유지해야 한다는 것이다. 하나의 기능에는 하나의 단일화된 표현이 필요하고 하나의 동작하는 코드가 필요하다. 

직교성

기하학에서 시작된 용어이다. 두 직선이 직각으로 만나는 경우에 ‘직교’라고 한다. 컴퓨터의 세계로 들어오면 독립성이나 결합도 줄이기(decoupling)의 의미로 해석할 수 있다. 

어쩌면 책에서 가장 많이 언급되는 내용이기도 하고,, 책을 보길 추천합니다

관련 키워드: 모듈러, 컴포넌트, 결합도, 디미터 법칙 등등..

가역성

실제로도 너무 많이 듣고, 들을 때마다 답답한 말이 있다. “처음부터 OO방식을 생각하진 않았기 때문에 이제 와서 바꾸려면 많은 시간이 필요합니다.” 정말 예측하기 힘든 것이었을 수도 있다. 하지만 대부분 예측 가능 범위에 포함된다.

REST API로 실컷 설계했더니 다음날 아침에 GraphQL로 바꿔야 한다고 한다. 혹은 RDB를 써서 만들었는데 NoSQL로 바꿔야 한다. 과연 절대 예측이 불가능한 일인가?

많은 사람들이 코드를 유연하게 유지하려고 노력한다. 비단 클래스 하나하나만 그런 것이 아니라 아키텍처, 벤더를 포함한 모든 영역에 대해서 유연성을 가져야 한다.

도메인 언어

최대한 문제 도메인에 가깝게 프로그래밍해라.

실용주의 편집증

아무것도 믿지 말라. 세상에 완벽한 것은 없다. 자기 자신 역시 믿지 말아야 한다. 속이기 가장 쉬운 것이 자기 자신이다!

어느 누구도 심지어 자기 자신도 완벽한 코드를 짤 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비해서 방어적으로 코드를 짠다. 가끔 이런 제대로 된 편집증도 필요하다.

계약에 의한 설계

정확한 프로그램이란? 많지도 적지도 않게, 자신이 하는 일이라고 주장하는 것만큼 일을 하는 프로그램이다. 이 주장을 문서화하고 검증하는 것이 계약에 의한 설계(Design By Contract, DBC)의 핵심이다.

망치지 말고 멈춰라

나도 가끔 ‘그런 일은 절대 일어날 리 없어!’ 사고에 빠질 때 있다. 확실하게 오류를 던져야 할 곳에서 안일하게 생각한 나머지 지나쳐버린 것이다. 꼭 그런 곳에서 문제가 발생한다.

문제를 빨리 발견했다면, 시스템을 멈추는 게 이득일 수 있다. 죽은 프로그램이 입히는 피해가 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.

단정적 프로그래밍

‘이런 일은 절대 일어날 리 없어’라고 단정하는 것의 위험성. 아래 케이스를 보자

  • 한 달이 28일보다 적은 경우
  • 내각의 합이 180도가 아닌 삼각형
  • 60초가 아닌 1분, 자바에서 (a + 1) <= a

이런 일이 없을거라고 확신할 수 있는가? 하지만 실제로 저런 경우들이 있다.

실용주의 철학은 하루아침에 이룰 수도, 끝이 존재하지도 않는다.

한 관광객이 이렇게 완벽한 잔디밭을 어떻게 만들 수 있는지 정원사에게 물었다. 
정원사는 “그건 쉬워요.”라고 대답했다.
“매일 아침 이슬을 털어주고, 이틀에 한 번 잔디를 깎아주고, 일주일에 한 번 잔디밭을 골라주면 되지요.”


Written by@Heebeom Kim
iOS Engineer. Interested in Architecture, Automation. Work for CPNG

GitHubLinkedIn