실용주의 프로그래머 수록 팁 모음

Tip 1. 자신의 기예_Craft에 관심을 가져라.링크를 제목에 복사

여러분이 소프트웨어 개발을 잘하는 것에 관심이 없다면, 이 일을 하는 의미가 없다고 생각한다.

Tip 2. 자기 일에 대해 생각하라.링크를 제목에 복사

절대 기계적으로 일하지 말라. 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라. 오래된 IBM의 표어 '생각하라!_Think!가 실용주의 프로그래머의 계명이다.

Tip 3. 당신에게는 에이전시_agency가 있다.링크를 제목에 복사

당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.^{ChangeYourOrganization}

Tip 4. 어설픈 변경 말고 대안을 제시하라.링크를 제목에 복사

변명하는 대신 대안을 제시하라. 그 일은 할 수 없다고만 말하지 말고, 무엇을 할 수 있는지 설명하라.

Tip 5. 깨진 창문을 내버려 두지 말라.링크를 제목에 복사

발견하자마자 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것 만이라도 하라. 엔트로피가 우리를 지배하도록 내버려두지 말라.

Tip 6. 변화의 촉매가 되라.링크를 제목에 복사

계속되는 성공에 합류하기란 쉽다.

Tip 7. 큰 그림을 기억하라.링크를 제목에 복사

주변을 살피고 의식하는 습관을 들여라. 그리고 여러분의 프로젝트에 대해서도 똑같이 하라.^상황인식

Tip 8. 품질을 요구 사항으로 만들어라.링크를 제목에 복사

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

Tip 9. 지식 포트폴리오에 주기적으로 투자하라.링크를 제목에 복사

사고 간의 교접^{cross-pollination}

Tip 10. 읽고 듣는 것을 비판적으로 분석하라.링크를 제목에 복사

상업주의의 힘을 절대 과소 평가하지 말라. 웹 검색 엔진의 첫 머리에 나온 결과라고 해서 그것이 최선이라는 의미는 아니다.

비판적 사고를 위한 질문링크를 제목에 복사

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

Tip 11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.링크를 제목에 복사

한국어든 영어든 하나의 프로그래밍 언어인 것처럼 다뤄라. 문서 작성도 코드를 작성하듯이 하라. DRY 원칙, ETC_{Easier to Change}, 자동화 등을 지켜라.

Tip 12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.링크를 제목에 복사

소설가는 글쓰기 전에 책의 줄거리를 먼저 구성한다. 반면에 기술 문서를 작성하는 사람들은 종종 키보드 앞에 앉아서 "1. 서론"을 쳐 넣고는 무엇이건 머리에 떠오르는 대로 입력해 나가는 방식에 안주하고 만다.

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

코드와 별개로 만든 문서가 정확하거나 최신 정보를 잘 반영하기는 힘들다.

Tip 14. 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.링크를 제목에 복사

바꾸기 더 쉽게_{Easier to Change.} ETC. 이게 전부다. 파일을 저장할 때마다 "ETC?"

Tip 15. DRY: 반복하지 말라_{Don't Repeat Yourself}링크를 제목에 복사

• 코드의 중복
• 문서화 중복
• 데이터의 DRY 위반
• 표현상의 중복
• 개발자 간의 중복

Tip 16. 재사용하기 쉽게 만들어라.링크를 제목에 복사

여러분은 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다.

Tip 17. 관련 없는 것들 간에 서로 영향이 없도록 하라.링크를 제목에 복사

응집_cohension

직교성의 장점

• 생산성 향상
• 리스크 감소

Tip 18. 최종 결정이란 없다.링크를 제목에 복사

돌에 새겨진 것처럼 바뀌지 않는 결정이란 없다. 모든 결정이 바닷가의 모래 위에 쓰인 글씨라고 생각하고 변화에 대비하라.

Tip 19. 유행을 좇지 말라.링크를 제목에 복사

roll with punch.

Tip 20. 목표물을 찾기 위해 예광탄을 써라.링크를 제목에 복사

개발 우선순위를 정하라.

예광탄은 지금 맞히고 있는 것이 무엇인지 보여준다. 그러나 그것이 꼭 목표물이라는 보장은 없다. 그럴 경우 목표물에 맞을 때까지 조준을 옮겨야 한다.

Tip 21. 프로토타이핑으로 학습하라.링크를 제목에 복사

• 주요 영역의 책임이 잘 정의되었고 적절한가?
• 주요 컴포넌트 간의 협력 관계가 잘 정의되었는가?
• 결합도는 최소화했는가?
• 중복이 발생할 만한 곳은 있다면?
• 정의된 인터페이스와 제약 사항은 수용할 만한가?
• 각 모듈이 실행 중에 필요한 데이터에 접근할 수 있는 경로를 갖고 있는가? 모듈에 데이터가 필요한 시점에 데이터 접근이 가능한가?

Tip 22. 문제 도메인에 가깝게 프로그래밍하라.링크를 제목에 복사

도메인 특화 언어는 응용 프로그램 도메인 내의 특정 문제를 해결하도록 설계된, 제한된 범위의 컴퓨터 언어 유형

• DSL_{Domain-Specific Language}
  • 내부_internal 도메인 언어
  • 외부_external 도메인 언어
• GSL_{General Purpose Language}

Tip 23. 추정으로 놀람을 피하라.링크를 제목에 복사

기본적인 추정의 비법: 이미 그 일을 해본 사람에게 물어보라.

추정치는 어디서 나오는가?

• 무엇을 묻고 있는지 이해하라
• 시스템의 모델을 만들어라
• 모델을 컴포넌트로 나눠라
• 각 매개변수에 값을 할당하라
• 답을 계산하라
• 여러분의 추정 실력을 기록하라. 추정치가 틀렸다고 움츠리거나 도망가지 말라. 왜 틀렸는지 찾아라. 다음 추정치는 훨씬 나아질 것이다.

Tip 24. 코드와 함께 일정도 반복하여 조정하라.링크를 제목에 복사

구현하면서 얻는 경험을 바탕으로 프로젝트의 소요 시간을 재조정하라.

Tip 25. 지식을 일반 텍스트로 저장하라.링크를 제목에 복사

HTML, JSON, YAML 등은 모두 일반 텍스트다. HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다.

• 지원 중단에 대한 보험
• 기존 도구의 활용
• 더 쉬운 테스트

Tip 26. 명령어 셸의 힘을 사용하라.링크를 제목에 복사

모든 작업을 GUI로만 하면 여러분이 가진 환경의 능력을 전부 이용할 수 없다. 일반적인 작업을 자동화할 수 없고, 가용한 도구의 역량을 온전히 사용할 수 없다.

GUI의 장점은 WYSIWYG_{What You See Is What You Get,} GUI의 단점은 WYSIAYG_{What You See Is All You Get,}

Tip 27. 에디터를 유창하게_Fluency쓸 수 있게 하라.링크를 제목에 복사

무언가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라. '분명 더 나은 방법이 있을 텐데.' 그리고 더 나은 방법이 있는지 찾아보라.

Tip 28. 언제나 버전 관리 시스템을 사용하라.링크를 제목에 복사

버전 관리 시스템은 여러분의 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.

Tip 29. 비난 대신 문제를 해결하라.링크를 제목에 복사

디버깅의 심리

Tip 30. 당황하지 말라.링크를 제목에 복사

디버깅을 할 때 근시안의 함정에 주의하라. 표면에만 보이는 증상만 고치려는 욕구를 이겨내라. 실제 문제는 여러분 눈앞에 있는 것에서 몇 단계 떨어져있고, 또 다른 여러가지와 연관되어 있을 확률이 다분하다.

Tip 31. 코드를 고치기 전 실패하는 테스트부터.링크를 제목에 복사

재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있는가? 우리는 '명령 하나'로 재현할 수 있기를 바란다.

Tip 32. 그놈의_damn 오류 메세지 좀 읽어라.링크를 제목에 복사

대부분의 예외는 무엇이 어디서 실패했는지 알려준다. 운이 좋으면 어떤 매개 변수가 쓰였는지도 알 수 있다.

Tip 33. "select"는 망가지지 않았다.링크를 제목에 복사

OS나 컴파일러 혹은 외부 제품에 버그가 있을 수도 있다. 하지만 처음부터 그런 생각을 하지는 말라.

설사 외부 제품에 문제가 있더라도 버그 리포트를 제출하기 전에 여러분의 코드에 문제가 없다는 것을 확인해야 하는 것은 마찬가지이다.

Tip 34. 가정하지 말라. 증명하라.링크를 제목에 복사

어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.

Tip 35. 텍스트 처리 언어를 익혀라.링크를 제목에 복사

여러분은 매일 많은 시간을 텍스트와 씨름하며 보낸다. 왜 그중 일부를 컴퓨터에서 맡기지 않는가?

Tip 36. 여러분은 완벽한 소프트웨어를 만들 수 없다.링크를 제목에 복사

어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기에 자신의 실수에 대비한 방어책을 마련한다.

Tip 37. 계약으로 설계하라.링크를 제목에 복사

코드는 많지도 적지도 않게 자신의 일이라고 주장하는 만큼의 일만 해야 한다. 이를 계약으로 문서화하고 검증하라.

Tip 38. 일찍 작동을 멈춰라.링크를 제목에 복사

오류 발생 시 소비자의 입장을 우선하라.

잡은 후 그냥 놓아주는 것은 물고기뿐

• 예외 처리
  • 애플리케이션 코드가 오류 처리 코드 사이에 묻히지 않도록
  • 코드의 결합도를 높이지 않도록

Tip 39. 단정문으로 불가능한 상황을 예방하라.링크를 제목에 복사

테스트 되고 배포된 다음에는 더 이상 단정이 필요하지 않다는 오해 단정은 디버깅 도구일 뿐이라는 오해

성능에 문제가 있다 하더라도 정말 문제가 되는 단정문만 끄도록 하자.