실용주의 프로그래머 - 1장 실용주의 철학

서문

무엇이 실용주의 프로그래머를 만드는가?

• 얼리 어댑터 또는 새로운 것에 빨리 적응하는 사람
• 호기심 많은 사람
• 비판적인 사고의 소유자
• 현실주의자
• 다방면에 능숙한 사람

Tip 1. 자신의 기예(craft)에 관심을 가져라

Tip 2. 자기 일에 대해 생각하라

• 모든 개발 과정에서, 매일, 우리가 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다.
• 절대 기계적으로 일하지 말라
• 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라.
• '생각하라!'가 실용주의 프로그래머의 계명(mantra)이다.

실용주의 프로그래머와 규모가 큰 팀

• "우리가 단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다."

끊임없는 과정

• 완벽한 잔디밭을 만드는 법
  • 매일 아침 이슬을 털어 주고, 이틀에 한 번 잔디를 깎아 주고, 일주일에 한 번 잔디밭을 골라주면 된다.
  • 그렇게 500년만 하면 완벽한 잔디밭을 만들 수 있다.
• 카이젠; 꾸준히 조금씩 자주 개량한다.
  • 매일같이 지금 있는 기술들을 다음고, 기술 목록에 새로운 도구들을 추가하라.

1장 실용주의 철학 

• 실용주의 프로그래머는 무엇이 다른가?
  • 문제와 해법에 접근하는 태도와 방식, 철학에 차이가 있다고 생각한다.
  • 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다.
  • 자신이 하는 모든 일에 책임을 진다.

Topic 1. 당신의 인생이다.

나는 당신의 기대대로 살기 위해 이 세상에 있는 게 아니고, 당신도 내 기대대로 살기 위해 이 세상에 있는 게 아니다.
- 브루스 리(Bruce Lee)

• "왜 직접 바꾸지 않습니까?"

Tip3 당신에게는 Agency가 있다.

• "당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다." - 마틴 파울러

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

약점을 보이는 것에 대한 두려움이 가장 큰 약점이다.
- J. B 보쉬에

• 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다.
• 우리는 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야만 한다.
• 정직하고 솔직해져야 한다.

팀 내 신뢰

 

책임지기

• 다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 말라.
• 해결책을 찾아내야 하는 사람은 나이다.

Tip 4. 어설픈 변명 말고 대안을 제시하라.

• 부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.
• 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해 보라.

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

• 소프트웨어의 무질서도가 증가할 때 우리는 이를 '소프트웨어의 부패'라고 일컫는다. 이를 보다 긍정적으로 '기술 부채'라고 부르기도 한다.

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

• 나쁜 설계, 잘못된 결정, 형편없는 코드 등이 모두 깨진 창문이다.
• 발견하자마자 바로 고쳐라.
• 어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라.

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

• 큰 무리 없이 요구할 수 있을 만한 것을 찾아라. 그리고 그걸 잘 개발하라. 일단 무언가 생기면 사람들에게 보여 주고 그들이 경탄하게 하라.
• 물러나 앉아 우리가 애초에 원했던 그 기능을 추가해 달라고 사람들이 부탁하기 시작할 때까지 기다려라.
• 계속되는 성공에 합류하기란 쉽다.
• 미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 모여들 것이다.

Tip 6. 변화의 촉매가 되라.

Tip 7. 큰 그림을 기억하라.

• 큰 그림에 늘 주의를 기울여라.
• 당장하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라.

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

우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망친다.
- 셰익스피어

• 실세계에서는 진정 완벽한 것을 만들어 내기란 불가능하다.
• 사용자나 미래의 유지 보수 담당 아니면 자기 자신의 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 된다.
  우리는 더 생산적이 되고 사용자는 한층 더 행복해할 것이다.
• '적당히 괜찮은'이라는 표현은 너절하거나 형편없는 코드를 의미하지 않는다.
  사용자의 요구 사항을 충족해야 한다.

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

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

• 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다.
• 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다.

멈춰야 할 때를 알라

• 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라.

Topic 6. 지식 포트폴리오

지식에 대한 투자가 언제나 최고의 이윤을 낸다.
- 벤저민 프랭클린

• 지식은 '기한이 있는 자산'이다.
• 새로운 것을 배우는 능력은 우리의 가장 중요한 전략 자산이다.

지식 포트폴리오

• 주기적인 투자
• 다각화
• 리스크 관리
• 싸게 사서 비싸게 팔기
• 검토 및 재조정

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

목표

• 매년 새로운 언어를 최소 하나는 배워라.
• 기술 서적을 한 달에 한 권씩 읽어라.
• 기술 서적이 아닌 책도 읽어라.
• 수업을 들어라.
• 지역 사용자 단체나 모임에 참여하라.
• 다른 환경에서 실험해 보라.
• 요즘 흐름을 놓치지 말라.

 

• 학습 과정에서 사고가 확장된다.
• 사고 간의 교접이 중요하다.
• 새로 배운 교훈을 현재 프로젝트에 적용하도록 노력하라.

학습의 기회

• 누군가의 질문에 답이 무엇인지 전혀 알지 못한다면 거리낌 없이 그걸 인정하고 답을 찾기 위한 도전을 하라.

비판적 사고

• 우리가 읽거나 듣는 것에 대해 비판적으로 생각하라.
• 자신의 도그마(dogma)가 유일한 답이라고 주장하는 광신도를 조심하라.

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

• 왜냐고 다섯 번 묻기
• 누구에게 이득이 되나?
• 어떤 맥락인가?
• 언제 혹은 어디서 효과가 있을까?
• 왜 이것이 문제인가?

Topic 7. 소통하라!

나는 무시당하느니 차라리 샅샅이 훑어보는 시선이 낫다고 봐요.
- 메이 웨스트

• 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다.

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

청중을 알라

• 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다.
• 청중의 요구와 관심, 능력을 이해할 필요가 있다.

말하고 싶은 게 무언지 알라

• 무엇을 말할지 미리 계획하라.
• 의사소통하고 싶은 아이디어들을 적은 다음 제대로 전달하는 데 필요한 전략을 몇 개 세워라.
• 상대가 무엇을 원하는지 알았다면 원하는 것을 이루어 주자.

때를 골라라

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

스타일을 골라라

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

멋져 보이게 하라

• 아이디어는 중요하다. 그러니 마땅히 청중에게 멋지게 전달하기 위한 수단을 준비해야 한다.

청중을 참여시켜라

• 피드백을 받고 적용하라.

경청하라

• 다른 사람들이 우리가 하는 말을 경청해 주길 바란다면 그들의 말을 경청하라.

응답하라

• 언제나 이메일과 음성 메시지에 답을 하라.

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

문서화

• 문서화는 전체 개발 프로세스의 필요 불가결한 부분이다.
• 코드 안에 문서를 두어라.
  소스 코드의 주석으로 보기 좋은 문서를 쉽게 생성할 수 있다.

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