실용주의 프로그래머 읽어보기 1주차

들어가며

이 포스트는 데이비드 토머스, 앤드류 헌트의 「실용주의 프로그래머」 Topic1 ~ 8까지 읽고 개인적으로 학습한 내용을 정리한 글입니다.

• 책: 실용주의 프로그래머
• 저자: 데이비드 토머스, 앤드류 헌트
• 출판사: 인사이트
• 챕터: Topic 1 ~ Topic 8

핵심 내용 정리

Topic 1. 당신의 인생이다

• 당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다
• 이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라

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

• 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다
• 실용주의 프로그래머는 자신의 경력에 대해 책임지고, 자신의 무지나 실수를 주저 없이 인정한다.

팀 내 신뢰

• 무엇보다 여러분의 팀의 여러분을 믿고 의지할 수 있어야 한다.

책임지기

• 책임은 여러분이 적극적으로 동의하는 것이다
• 여러분에게 불가능하거나 위험 요소가 너무 큰 상황, 또는 결과가 윤리적으로 심각하게 우려되는 상황에서는 책임을 맡지 않을 권리가 있다
• 어설픈 변명 말고 대안을 제시하라

도전해볼 것

• 여러분이 “잘 모르겠어요”라고 말했다면, 꼭 바로 이어서 “하지만 알아볼게요”라고 말하라. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다

Topic 3. 소프트웨어 엔트로피

• 소프트웨어가 부패하는 데 가장 중요한 것은 프로젝트에서 발생하는 심리학적 혹은 문화적 요소

  깨진 창문을 내버려 두지 말라

• 나쁜 설계, 잘못된 결정 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라.

우선, 망가트리지 말라

• 깨진 창문 하나는 내리막길로 가는 첫걸음이다
• 깨진 창문이 꽤 있는 프로젝트에서 일할 때는 ‘나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐.’라고 사고에 빠지기 너무 쉽다

도전해 볼 것

• 프로젝트를 함께 하는 동료의 생각을 조사하여 팀을 더 튼튼하게 만들라. 깨진 창문을 두세 개 고른 다음, 여러분의 동료들과 함께 무엇이 문제고 그걸 고치기 위해 무엇을 할 수 있는지 토론하라

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

• 시작 피로(start-up fatigue) : 새로운 프로젝트나 활동을 시작할 때 느끼는 정신적, 감정적 피로감

  Tip 6. 변화의 촉매가 되라

Tip 7. 큰 그림을 기억하라

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

• 적당히 괜찮은 소프트웨어를 만들도록 자신을 단련할 수 있다 사용자나 미래의 유지 보수 담당 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 된다

타협 과정에 사용자를 참여시켜라

Tip8. 품질을 요구사항으로 만들어라

• 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다

멈춰야 할 때를 알라

• 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라
• 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라. 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다

Topic 6. 지식 포트폴리오

• 여러분의 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다
• 하지만 이 자산은 기한이 있는 자산이다.새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다

지식 포트폴리오

• 지식 포트폴리오 관리는 투자 포트폴리오 관리와 유사하다
  1. 진지한 투자자는 주기적으로 투자하는 습관이 있다
  2. 장기적인 성공의 열쇠는 다각화다
  3. 똑똑한 투자자는 보수적인 투자와 위험이 크지만 보상이 높은 투자 사이에서 포트폴리오의 균형을 잘 맞춘다
  4. 투자자는 최대 수익을 위해 싸게 사서 비싸게 팔려고 한다
  5. 포트폴리오는 주기적으로 재검토하고 재조정해야 한다

포트폴리오 만들기

Tip 9. 지식 포트폴리오에 주기적으로 투자하라

주기적인 투자

• 자신의 자식 포트폴리오에 소량이라도 주기적으로 투자해야한다.

다각화

• 더 여러 가지를 알수록 자신의 가치는 더욱 높아진다
• 기술 외의 분야도 포함해 여러분에게 필요한 다른 역량도 잊지 말라

리스크 관리

• 여러분의 기술 달걀을 모두 한 바구니에 담지 말라

싸게 사서 비싸게 팔기

• 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 게 저평가된 주식을 찾아내는 것만큼이나 어려울 수 있지만, 이익 또한 그만큼 클 수 있다

검토 및 재조정

• 이 산업을 매우 동적이다. 지난달부터 탐구하기 시작한 인기 있던 기술이 한 달 만에 완전히 찬밥이 될지도 모른다

목표

매년 새로운 언어를 최소 하나는 배워라

• 다른 언어는 동일한 문제를 다르게 푼다. 몇 가지 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데 도움이 된다

기술 서적을 한 달에 한 권씩 읽어라

• 현재 프로젝트와 관련있는 흥미로운 주제의 기술 서적을 서점에서 찾아보라. 습관이 들면 한 달에 한 권씩 읽어라

기술 서적이 아닌 책도 읽어라

• 방정식에서 인간이라는 변을 잊지 말라

수업을 들어라

• 사는 지역의 대학, 온라인 대학, 근처에서 열리는 기술 세미나나 콘퍼런스에서 흥미로운 강좌를 찾아보라

지역 사용자 단체나 모임에 참여하라

• 회사 밖에서 사람들이 어떤 일을 하는지 알아보라. 가서 가만히 듣고만 오지 말고 적극적으로 참여하라

다른 환경에서 실험해 보라

• 윈도우만 사용했다면 리눅스로 사용해보기

요즘 흐름을 놓치지 말라

• 현재 프로젝트에서 사용 중인 것과는 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라
• 다른 사람이 그에 관해 어떤 경험을 했는지, 그들이 사용하는 특별한 전문 용어가 무슨 뜻인지 등을 배우기에 아주 좋은 방법이다

학습의 기회

• 모르는 것을 거리낌없이 인정하고, 답을 찾아라
• 스스로 답을 찾지 못하겠다면, 답을 찾아줄 수 있는 사람을 찾아라

비판적 사고

읽고 듣는 것을 비판적으로 분석하라

• 자신이 읽거나 듣는 것에 대해 비판적으로 생각하라
• “왜냐고 다섯 번 묻기”
  • 질문하고 답을 구하라
  • “왜”라고 물어서 더 깊이 파고들라
• 누구에게 이익이 되나
  • 돈의 흐름을 살피면 분석이 한결 쉬워지기도 한다
• 어떤 맥락인가?
  • 모든 일에는 각각의 맥락이 있기에, ‘만병통치약’인 해결책은 대개 통하지 않는다
• 언제 혹은 어디서 효과가 있을까?
  • “그 이후에는 또 어떤 일이 일어날까?”같이 그다음 단계까지 생각해 보라
• 왜 이것이 문제인가?
  • 광범위한 포트폴리오를 갖추고, 넘쳐나는 기술을 다룬 글을 읽을 때 비판적 분석을 적용함으로써 복잡한 해답을 이해할 수 있을 것이다

도전해 볼 것

• 이번 주부터 새로운 언어를 배우기 시작하라
• 새 책을 하나 읽기 시작하라
• 밖으로 나가서 지금 수행하고 있는 프로젝트에 관여하지 않는 사람 혹은 같은 회사에 근무하지 않는 사람과 기술에 관한 대화를 하라

Topic 7. 소통하라

Tip 11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다

• 최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다
• 여러분이 의사소통에 사용하는 언어도 또 다른 프로그래밍 언어일 뿐이라고 여겨라

청중을 알라

• 청중의 요구와 관심, 능력을 이해해야 한다

말하고 싶은 게 무언지 알라

• 무엇을 말할 지 미ㅣ리 계획하라. 개요를 작성하고 자문하라

때를 골라라

• 말하는 내용뿐 아니라 말하는 시점도 적절하게 하라

스타일을 골라라

• 전달하는 스타일을 청중에 어울리도록 조정하라

멋져 보이게 하라

• 아이디어를 청중에게 멋지게 전달하기 위한 수단을 준비해야 한다

청중을 참여시켜라

• 가능하다면 독자가 문서 초안에 참여하도록 하라
• 피드백을 받고 그들의 머릿속을 도용하라
• 독자와 더 좋은 관계를 형성하게 될 것이고, 아마 그 과정에서 더 나은 문서를 만들 수 있을 것이다

경청하라

• 질문을 해서 사람들이 이야기를 하도록 북돋우거나, 토론의 내용을 그들 자신의 표현으로 다시 말해 달라고 요청하라

응답하라

Tip 12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다

• 외부와 단절된 환경에서 작업하지 않는 이상 우리는 의사소통을 해야 한다

문서화

Tip 13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라

• 실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다
• 소스 코드의 주석으로 보기 좋은 문서 생성하기
• 모듈과 외부로 노출하는 함수에는 주석 달기

Topic 8. 좋은 설계의 핵심

Tip 14. 좋은 설계는 나쁜 설계보다 바꾸기 쉽다

• ETC(Easier to Change) 원칙

ETC는 규칙이 아니라 가치

• 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 ‘바꾸기 쉽게’라는 길을 선택한다
• 여러 상황들을 자신의 직관을 발전시키는 기회로 삼아라

느낀점

• 마음속으로는 무지나 실수에 대해 인정하는 것을 수월하게 하고 싶지만, 쉽지 않는 영역이다
• 신년에 새로운 언어를 하나씩 배워보려고 생각하지만 실천하지 않는 자신.. 올해는 하나라도 해야겠다
• 소통하는 건 너무 어려운 일이다. “Tip 12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다” 는 말이 가장 와닿았다
• 최근 사이드 프로젝트를 시작하려고 하는데, “Tip 13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라” 이 문장을 실천해야겠다는 생각이 들었다
• “앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 ‘바꾸기 쉽게’라는 길을 선택한다” 는 어떻게 설계해야 할 지 고민이 들 때, 사용해야겠다는 생각이 들었다