[책] 실용주의 프로그래머 3장 기본 도구

실용주의 프로그래머

The Pragmatic Programmer

 

3장. 기본 도구

(p103)The Basic Tools

 

 

자신의 기본 도구 상자에 어떻게 투자해야 할 것인가?

도구들의 사용법을 배우는 데에 시간을 투자하라.

도구가 손의 연장이 된 자신을 발견하게 될 것이다.

 

Topic 16. 일반 텍스트의 힘

 

일반텍스트란?

 

Tip 25. 지식을 일반 텍스트로 저장하라.

 

텍스트의 힘

일반 텍스트가 널리 쓰이는 이유는?

 - 지원 중단에 대한 보험

 - 기존 도구의 활용

 - 더 쉬운 테스트

 

지원 중단에 대한 보험

일반 텍스트 파일은 포맷을 부분적으로밖에 알지 못하더라도 파싱할 수 있다.

사람이 읽을 수 있는 것과 사람이 이해할 수 있는 것에는 차이가 있다.

 

기존 도구의 활용

버전 관리 시스템에서 에디터, 명령 줄 도구에 이르기까지 컴퓨터 세계의 거의 모든 도구는 일반 텍스트를 다룰 수 있다.

 

더 쉬운 테스트

시스템 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.

 

최소 공통분모

모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야 한다.

일반 텍스트가 바로 그 표준이다.

 

Topic 17. 셀 가지고 놀기

GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.

실용주의 프로그래머는 오직 코드만 쏟아 내거나, 객체 모델만 개발하거나, 문서만 작성하거나, 빌드 과정 자동화만 하지는 않는다.

이 모든 일을 다 한다.

 

Tip 24. 명령어 셸의 힘을 사용하라.

 

자신만의 셸

 

목수가 작업 공간을 자신에게 맞추어 바꾸듯이 개발자도 셸을 자신에게 맞추어야 한다.

 - 색깔 조합 설정

 - 프롬프트 설정

 - 별칭과 셸 함수

 - 명령어 자동 완성

 

Topic 18. 파워 에디팅

텍스트는 프로그래밍의 기본 원재료이므로 여러분은 텍스트를 최대한 손쉽게 조작할 수 있어야 한다.

원한다면 에디터를 몇 개 사용하든 상관없다.

다만 각각의 에디터에 유창해지도록 노력해야 한다.

 

Tip 27. 에디터를 유창하게(fluency) 쓸 수 있게 하라.

 

유창해지는 것의 가장 큰 이점은 더는 에디터 사용법을 생각하지 않아도 된다는 것이다.

생각이 자유롭게 흐를 것이고 프로그래밍에 큰 도움임 될 것이다.

 

어떤 것이 '유창'한 것인가?

 

 - 텍스트 편집 시 여러 단위로 커서 이동 or 내용 선택 해보아라

 - 코드 편집 시 반대편 괄호로 이동, 함수/모듈 등 다양한 문법 단위로 커서 이동 해보아라

 - 변경한 코드의 들여쓰기를 자동으로 맞춰라

 - 여러 줄의 코드를 명령 하나로 주석 처리했다가 다시 주석을 해제하라

 - 실행 취소를 여러번 헀다가 취소한 명ㅎ령을 재실행 기능으로 다시 수행하라

 - 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.

 - 특 정 줄 번호로 이동하라.

 - 여러 줄을 선택한 후 가나다순으로 정렬하라.

 - 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라.

 - 선택 영역이나 패턴 검색을 이용하여 일시적으로 여러 개의 커서를 만든 다음, 동시에 여러 곳의 텍스트를 편집하라.

 - 현재 프로젝트의 컴파일 오류를 표시하라.

 - 현재 프로젝트의 테스트를 실행하라.

 

과연 몇개나 마우스/트랙패드 없이 수행 가능할까?

현재 사용하는 에디터로는 수행 불가능한 것이 몇가지 있을 수도 있다.

그럼 바꿀 때인 것은 아닐까??

 

유창해지기

삶을 편하게 해 주는 명령어를 배워라.

더 나은 방법을 찾아보고 몸이 기억하도록 만들어야 한다.

 

에디터 성장시키기

 

사용 중인 에디터에서 명백한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라.

나뿐만 아니라 필요한 사람이 있고 운이 좋다면 누군가가 해결책을 만들어 놓았을 것이다.

늘 하는 반복적인 일을 자동화할 방법을 연구하여 한두 줄 만으로 가능하게 해보아라.

확장 기능을 만들고 공개 해보아라.

 

Topic 19. 버전 관리

진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다.
과거를 기억하지 못하는 사람은 과거를 반복할 운명이다.
 - 조지 산타야나(George Santayana), <Life of Reason(이성의 삶)>

실제로 컴파일되고 실행되던 지난주의 평화로운 시절로 돌려줄 수 있다!

또한 공동 작업과 배포 파이프라인, 이슈 추적에다 일반적인 팀 상호작용까지 아우르는 훨씬 더 큰 세상을 놓치지 마라.

 

공유 디렉토리는 버전 관리 시스템이 아니다.

 

소스 코드부터 시작

버전 관리 시스템은 소스 코드나 문서의 모든 변경 사항을 이거하고,

바르게 설정된 버전 관리 시스템이 있으면 소프트웨어의 이전 버전으로 언제든지 되돌아갈 수 있다.

 

코드 수정한 사람, 버전간 변경점, 변경된 코드 줄 수, 수정된 파일 빈도 등 정보는

버그 추적이나, 감사(audit), 성능 관리, 품질 관리를 해야 할 때 매우 귀중하다.

 

여러 사용자가 동일한 파일을 작업하며 합칠 수도 있다.

 

Tip 28. 언제나 버전 관리 시스템을 사용하라.

우리가 키보드로 입력하는 거의 모든 것에 대해 일상적으로 버전 관리 시스템을 사용한다.

 

브랜치 사용하기

 

프로젝트 허브로서의 버전 관리

 

Topic 20. 디버깅

참으로 고통스러운 일입니다.
자신이 겪는 어려움을 보고는 알게 되죠.
다른 누구도 아닌 바로 자신이 문제를 만들었다는 걸.
 - 소포클레스(Sophocles) <아이아스>

소프트웨어 결함은 요구 사항을 오해하는 것부터 코딩 오류에 이르기까지 여러 모습으로 나타난다.

 

디버깅의 심리

디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

 

Tip 29. 비난 대신 문제를 해결하라.

 

디버깅 사고방식

 

가장 속이기 쉬운 사람은 자기 자신이다.
 - 에드워드 불워-리턴(Edward Bulwer-Lytton), <The Disowned(의절)>

Tip 30. 당황하지 말라.

실제 문제는 눈앞에 있는 것에서 몇 단계 떨어져 있고,

또 다른 여러 가지와 연관되어 있을 확률이 다분하다.

 

겉으로 드러난 특정한 증상만 고치려고 하지 말고,

항상 문제의 근본 원인을 찾으려고 노력하라.

 

실마리 찾기

버그를 살표보기 전에 일단 작업 중인 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라.

 

 - 처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰할 필요도 있다.

 - 경계 조건(boundary condition)과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다.

 

디버깅 전략

버그 재현하기

버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다.

Tip 31. 코드를 고치기 전 실패하는 테스트부터.

 

미지의 세계에 온 프로그래머

 

Tip 32. 그놈의(damn) 오류 메시지 좀 읽어라.

 

이상한 결과

디버거에서 호출 스택 위아래로 어떻게 이동하고,

스택의 지연 변수를 어떻게 확인하는지 숙지하라.

 

흔한 버그 시나리오

 - 입력값에 따라 바뀜

 - 릴리스 사이에서 발생한 문제(regression)

 

이진 분할

이진 분할ㅡ이분 탐색, 이진 검색(binary search)ㅡ는 짜 보았을 것이다.

분할 정복(divide and conquer) 방식을 사용해보아라.

 

로깅과 트레이싱

트레이싱(tracing) 구문은 '여기까지 도달'이나 'x값 = 2' 같이 화면 혹은 파일에 출력하는 작은 진단용(diagnostic) 메시지를 일컫는다.

 

고무오리

문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다.

누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다.

이런 가정 몇 가지를 입 밖에 내면, 문제에 대한 새로운 통찰을 불현듯이 얻을 수도 있다.

 

소거법

 

Tip 33. "select"는 망가지지 않았다.

 

만약 여러분이 '단 하나만 변경'했는데 시스템이 작동을 멈춘다면 설사 아무 관련이 없어 보여도 십중팔구 직접적이든 간접적이든 변경한 그 하나에 책임이 있다.

 

놀라운 구석

어떤 버그로 놀라게 될 때 애지중지 믿고 있던 진실들을 재평가해야만 한다.

예상치 못한 '놀라운' 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다.

 

버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 '안다'고 해서 대충 얼버무리고 지나치지 말라.

그것을 증명하라.

이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.

 

Tip 34. 가정하지 말라. 증명하라.

 

놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서

왜 이 문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다.

 

버그를 미리 잡을 수 있도록 단위 테스트나 다른 테스트를 수정할 필요가 있는지 고민해 보라.

 

디버깅 체크 리스트

 - 보고된 문제가 내재하는 버그의 직접적 결과인가 아니면 단순히 증상일 뿐인가?

 - 버그가 정말로! 여러분이 사용하는 프레임워크에 있나? OS에? 아니면 여러분 코드에 있나?

 - 이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가?

 - 의심 가는 코드가 단위 테스트를 통과한다면 테스트는 충분히 갖춰진 것인가?

  이 데이터로 테스트를 돌리면 무슨 일이 생기는가?

 - 이 버그를 야기한 조건이 시스템의 다른 곳에도 존재하는가?

  다른 버그가 유충 단계에서 성충이 될 날만 기다리고 있는 것은 아닌가?

 

Topic 21. 텍스트 처리

가끔은 기본 도구만으로는 해내기 힘든 종류의 변환 작업이 있다.

범용 텍스트 처리 도구가 필요한 것이다.

 

Tip 35. 텍스트 처리 언어를 익혀라.

이 책을 쓰기 위해 만든 루비와 파이썬 프로그램들,,

 - 책 빌드하기

 - 코드 넣기 및 강조

 - 웹사이트 갱신

 - 수식 넣기

 - 찾아보기(index) 생

 

(연습 문제 11~13 는 추후 기재)

 

Topic 22. 엔지니어링 일지

일지를 쓰면 좋은 점

 - 기억보다 더 믿을 만하다.

 - 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다.

  (지금 하는 일에 계속해서 집중할 수 있다!)

 - 메모를 시작하자마자 메모의 주제인 여러분이 방금 전까지 하던 일이

  실은 말도 안 된다는 것을 깨닫게 될 수도 있다.

 

파일이나 위키말고 종이를 사용하라.

글씨를 쓰는 것은 키보드를 두드리는 것과는 다른 무언가 특별한 것이 있다.

 

적어도 훗날 여러분이 성공해서 유명해졌을 때 회고록을 쓰는 데는 도움이 될 것이다.