실용주의 프로그래머(The Pragmatic Programmer) - Topic 20~22

 

『실용주의 프로그래머』 3장 기본 도구

🧠 Topic 20 디버깅

• 디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
  → 감정을 배제하고 문제 해결에 집중하자.
• 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.
  → 탓하지 말고 해결에 집중하라.
• '하지만 정말 그럴 리가 없는데.'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라.
  → 불필요한 의심은 시간 낭비다.
• 표면에 보이는 증상만 고치려는 욕구를 이겨 내라.
  → 근본 원인을 찾아라.
• 겉으로 드러난 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.
  → 증상이 아닌 원인을 진단하라.
• 처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰할 필요도 있다.
  → 사용자와 소통해 더 많은 정보를 얻자.
• 인공적인 테스트는 애플리케이션을 충분히 테스트하지 못한다. 경계 조건(boundary condition)과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다.
  → 실제 상황을 반영한 테스트가 필요하다.
• 코드를 고치기 전 실패하는 테스트부터 진행하라.
  → 테스트 실패를 먼저 확인하라.
• 옆에 종이와 펜을 가져다 두고 메모를 하면 도움이 될 때가 많다.
  → 아날로그 도구도 강력한 지원군이다.
• 추적을 시작할 때 우리가 어디에 있었는지 메모를 남겨두지 않았다면 원래 자리로 돌아오느라 시간을 많이 소모했을 것이다.
  → 진행 경로를 기록하자.
• 트레이싱 구문으로 남기는 메시지는 규칙적이고 일관된 형식이어야 한다.
  → 로그 메시지도 일관성이 중요하다.
• 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다. 이런 가정 몇 가지를 입 밖에 내면, 문제에 대한 새로운 통찰을 불현듯이 얻을 수도 있다. 만약 들어 줄 사람이 없다면 고무 오리나 곰 인형, 화분도 괜찮다.
  → 설명하는 과정이 문제 해결의 실마리다.
• 대개 애플리케이션 코드가 라이브러리를 잘못 호출하고 있다고 가정하는 편이 라이브러리 자체에 문제가 있다고 가정하는 것보다 낫다. 설사 외부 제품에 문제가 있더라도 버그 리포트를 제출하기 전에 여러분의 코드에 문제가 없다는 것을 확인해야 하는 것은 마찬가지다.
  → 먼저 내 코드부터 점검하자.
• 우리 둘 중 하나가 자신의 실수일 수 있는 일을 시스템의 문제라고 탓하기 시작하면 우리는 그 사건을 떠올리도록 'select가 망가졌어'라는 표현을 사용한다. "select"는 망가지지 않았다.
  → 시스템보다 인간의 실수를 의심하라.
• 발굽 모양을 보면 말을 생각해야지 얼룩말부터 떠올리지 말라.
  → 흔한 문제부터 점검하자.
• 업그레이드를 고려할 때는 일정을 면밀히 살펴라. 한마디로 말해 딴 세상이 되는 것이고 새 조건하에서 시스템을 다시 테스트해야 한다.
  → 업그레이드는 철저한 준비가 필요하다.
• 뭔가 잘못될 때 놀라는 정도는 실행되는 코드에 갖는 신뢰와 믿음의 정도에 비례한다. 그렇기 때문에 예상치 못한 '놀라운' 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다. 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 '안다'고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.
  → 믿지 말고, 증명하라.
• 놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서 왜 이 문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다.
  → 문제 발생의 배경까지 분석하자.
• 어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.
  → 재현 가능성 확보가 중요하다.
• 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체팀과 함께 토론하라. 한 사람이 오해했다면 다른 사람들도 그럴 수 있다.
  → 오류는 공유해서 예방하자.

---

✂️ Topic 21 텍스트 처리

• 실용주의 프로그래머는 목수가 나무를 다루는 것과 똑같은 방식으로 텍스트를 다룬다.
  → 텍스트는 코드의 원재료다.
• 프로그래밍에서 텍스트 처리 언어는 목공에서 '루터(router)'와 같다. 제대로 사용하기만 한다면 루터와 텍스트 처리 언어 둘 다 믿기 힘들 정도로 강력하고 쓰임새가 다양하다.
  → 텍스트 도구는 숙련된 장인의 무기다.

---

📝 Topic 22 엔지니어링 일지

• 무엇을 했고 무엇을 배웠는지, 떠오르는 생각을 그려본 것, 방금 읽은 계기판의 눈금 등 기본적으로 업무에 관한 건 무엇이든지 적었다.
  → 기록은 생각의 저장소다.
• 일지를 쓰면 기억보다 더 믿을 만하다.
  → 기록이 기억을 이긴다.
• 일지를 쓰면 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다.
  → 창의적인 여지를 만들어 준다.
• 무언가를 쓰기 위해 하던 일을 멈추면 여러분의 뇌도 기어를 바꾼다. 누군가에게 이야기를 하는 것과 비슷하다. 하던 일을 돌아보기에 알맞은 기회가 생기는 것이다.
  → 기록은 반성의 시간을 만든다.
• 메모를 시작하자마자 메모의 주제인 여러분이 방금 전까지 하던 일이 실은 말도 안 된다는 것을 깨닫게 될 수도 있다.
  → 기록하면서 오류를 깨달을 수 있다.
• 때때로 수년 전에 여러분이 무엇을 하고 있었는지 돌이켜 볼 수 있다.
  → 과거의 자신과 대화하라.
• 파일이나 위키말고 종이를 사용하라.
  → 종이는 사고를 자극한다.