<div id="readability-page-1" class="page"><div>
    

<blockquote>
<p>The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition<br>
by Thomas David, Hunt Andrew, 2020</p>
</blockquote>



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

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

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

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

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



<p><img src="http://integerous.github.io/images/review/the_progmatic_programmer.jpeg" width="300"></p>



<h2 id="밑줄-친-문장들">밑줄 친 문장들</h2>

<ol>
<li>모든 개발 과정에서, 매일, 여러분이 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다. 절대 기계적으로 일하지 말라.
언제나 일하면서 동시에 생각하고, 자기 일을 비평하라. (p.21)</li>
<li>실용주의 프로그래머는 직면한 문제 너머를 고민한다. 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다. (p.1)</li>
<li>‘깨진 창문’을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. (p.9)</li>
<li>지식 포트폴리오 만들기 (p.21)

<ul>
<li>주기적인 투자

<ul>
<li>금융 투자에서와 마찬가지로 여러분의 지식 포트폴리오에 소량으로라도 주기적으로 투자해야 한다.</li>
</ul></li>
<li>다각화

<ul>
<li>더 여러 가지를 알수록 자신의 가치는 더욱 높아진다. 기본적으로 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야 한다.</li>
<li>하지만 거기서 멈추지 말라. 컴퓨터 분야의 지형은 빠르게 변한다. (중략) 더 많은 기술에 익숙하다면 변화에 더 잘 적응할 수 있을 것이다.</li>
</ul></li>
<li>리스크 관리

<ul>
<li>기술은 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 다양한 스펙트럼 위에 존재한다.</li>
<li>여러분의 기술 달걀을 모두 한 바구니에 담지 말라.</li>
</ul></li>
<li>검토 및 재조정

<ul>
<li>이 산업은 매우 동적이다. 지난달부터 탐구하기 시작한 인기 있던 기술이 한 달 만에 완전히 찬밥이 될지도 모른다.</li>
</ul></li>
</ul></li>
<li>API가 아닌 코드에 주석을 쓸 때는 왜 이렇게 되어 있는지, 즉 코드의 용도와 목적을 논해야 한다. 어떻게 동작하는지는 코드가 이미 보여 주기 때문에
이에 대해 주석을 다는 것은 사족이다. (p.34)</li>
<li>‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라. (p.40)</li>
<li>DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다. (p.44)</li>
<li>코드는 동일하지만 두 함수가 표현하는 지식은 다르다. 두 함수는 각각 서로 다른 것을 검증하고 있지만, 우연히 규칙이 같은 것뿐이다. 이것은 우연이지 중복이 아니다. (p.47)</li>
<li>이렇게 아키텍처가 변덕스러운 환경에서 어떻게 계획을 세울 수 있겠는가? 못한다. 여러분이 할 수 있는 것은 바꾸기 쉽게 만드는 것이다.
외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라. 여러분의 코드를 여러 컴포넌트로 쪼개라. 결국에는 하나의 거대한 서버에 배포하게 되더라도, 이 방식이 거대한
단일 모듈 애플리케이션을 가져다 쪼개는 것보다 훨씬 더 쉽다. (우리도 뼈저린 경험을 통해 배웠다.) (p.70)</li>
<li>일반적으로 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적은 법이다. (p.161)</li>
<li>묻지 말고 말하라(Tell, Don’t Ask, TDA.) 이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다는 것이다. (p.186)</li>
<li>전역적이어야 할 만큼 중요하다면 API로 감싸라. (p.191)</li>
<li>‘동시성concurrency’은 둘 이상의 코드 조각이 실행될 때 동시에 실행 중인 것처럼 행동하는 것이다. 그리고 ‘병렬성parallelism’이란 실제로 동시에 실행되는 것이다. (p.241)</li>
<li>&lt;리팩터링&gt;에서 마틴 파울러는 ‘리팩터링’을 다음과 같이 정의한다. 밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법. (p.301)</li>
<li>리팩터링이 필요한 코드를 일종의 ‘종양’이라고 생각하자. (p.304)</li>
<li>무언가를 테스트하기 좋게 만들면 결합도도 낮아진다. (p.310)</li>
<li>우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다. 사실 이게 우리의 가치가 가장 빛나는 부분일 것이다. (p.351)</li>
<li>생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다. - Alfred North Whitehead (p.392)</li>
</ol>

  </div></div>

Integerous DevLog on Integerous DevLog

한정수

The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition by Thomas David, Hunt Andrew, 2020 이 책은 현재 총원 4명의 개발팀 팀원들과 함께 스터디를 하기 위해 읽은 책이다. 각자 책을 읽어 오고 총 3회로 걸쳐서, 회당 2시간

<실용주의 프로그래머>

댓글