실용주의 프로그래머 3

기본 도구

모든 제작자는 좋은 품질의 도구 세트로 자신의 재능을 발휘한다. 좋은 도구는 재능을 증폭시키고, 생산성을 향상시킨다. 그러나 항상 필요에 따라서 새로운 도구를 취하는 것에 익숙해져야 한다.

일반 텍스트의 힘

실용주의 프로그래머로서 가장 중요한 재료는 지식이다. 우리는 지식을 저장하는 최고의 포맷인 일반 텍스트에 대해서 알아야한다. 일반 텍스트는 데이터 그 자체만으로 의미가 드러나는 데이터를 만들 수 있다. 일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다.
그러나 일반 텍스트가 형식 없는 텍스트를 의미하는 것은 아니다. JSON, YAML, HTTP 와 같이 특정한 프로토콜을 따를 수 있다. 일반 텍스트는 그 자체로 사람이 읽을 수 있기에, 매우 강한 생존성을 갖고 있다. 텍스트를 생산하거나 관리하는 시스템보다 텍스트 자체의 수명이 더 길 수도 있다.

유닉스 철학은 작고 예리한 각각의 도구가 한 가지 일만 잘하도록 만들자는 철학에 따라 설계된 것으로 유명하다. 유닉스에서는 시스템 관리용 데이터베이스를 모두 일반 텍스트 파일로 저장한다. 시스템을 복구해야 하는 경우에, 일반 텍스트의 단순함은 매우 감사하다.

셸

프로그래머에겐 명령어 셸이 작업대다. 셸 프롬프트에서 모든 종류의 도구를 사용할 수 있다. 예를 들면, 파이프를 사용해서 도구들을 결합하거나, 디버거 브라우저 데이터 유틸리티를 실행할 수 있다.
GUI 와 비교해보자. GUI 는 간편하고 빠르지만, 제공되는 도구만을 사용할 수 있다.(What you see Is All You Get) 반면, 셸을 사용한다면 제공되는 모델 / 인터페이스 이상의 작업을 할 수 있다.
개발자도 셸을 자신에게 맞출 수 있다. 색 조합을 설정하거나, 프롬프트를 설정하거나, alias 를 설정할 수 있다. 셸을 집(소라게의 조개 껍데기)처럼 만들어라.

파워 에디팅

에디터를 유창하게 쓸 수 있게 하라.

에디터를 어떻게 써야 ‘유창한’ 정도일까?

• 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라.
• 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라.
• 변경한 코드의 들여쓰기를 자동으로 맞춰라.
• 여러 줄의 코드를 명령 하나로 주석 처리했다가 다시 주석을 해제하라
• 실행 취소를 여러 번 했다가 재실행 기능으로 다시 수행하라
• 에디터 창을 여러 구역으로 쪼개고, 각 구역 사이를 이동하라
• 특정 줄 번호로 이동하라
• 여러 줄을 선택한 후 가나다순으로 정렬하라
• 문자열로, 졍규 표헌식으로 검색하고 이전에 검색했던 것을 다시 검색하라
• 선택 영역이나 패턴 검색을 통해 여러 개의 커서를 만들고 편집해라
• 현재 프로젝트의 컴파일 오류를 표시하라
• 현재 프로젝트의 테스트를 실행하라

이 모든 작업을 마우스 없이 수행할 수 있어야 한다. 만약 필요한 기능을 추가하는 확장 기능을 찾아보거나, 만들어보라. 여러분이 필요한 것은 다른 사람도 필요할 것이다.

버전 관리

진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다.

버전관리 시스템은 일종의 거대한 ‘실행 취소’ 키와 같다. 프로젝트 전체에 걸쳐서 실제로 컴파일되고 실행되던 평화로운 시절로 덜려줄 수 있는 타임머신이다. 프로젝트의 어느 시점에나 브랜치를 만들고, 이를 통해 다른 사람과 독립적으로 작업을 진행할 수 있다.
저장소 시스템은 대부분 오픈 소스이므로 직접 설치하고 운영할 수 있다. 이런 기능이 있으면 좋다.

• 확실한 보안과 권한 관리
• 직관적인 UI
• 명령 줄에서도 모든 작업 수행 가능
• 자동화된 빌드와 테스트
• 브랜치 병합을 잘 지원
• 이슈 관리, 커밋이나 브랜치 병합과 연계가 가능하고 지표도 구할 수 있다면 이상적
• 적절한 보고서 기능, 칸반 보드 형식으로 처리할 이슈를 표시
• 원할한 팀 의사소통을 돕는 기능

디버깅

아무도 완벽한 소프트웨어를 작성할 수 없다. 디버깅을 통해서 문제를 풀어야 한다. 버그를 만들어낸 남을 비난하기보다 문제를 고치는 데에 집중해야 한다. 어쨋든 버그를 해결해야 하는 사람은 여러분이다.
디버깅에 있어서 제 1법칙을 항상 기억하라

당황하지 마라

버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각해보는 것이 중요하다. 근신안의 함정에 주의하고, 항상 문제의 근본 원인을 찾으려고 노력하라. 그러기 위해서는 버그를 재현할 수 있어야 하고, 관련 자료를 확인해야 한다.

• 버그 발생 조건을 확인하고, 최초로 보고한 사용자를 인터뷰할 필요도 있다.
• 경계 조건과 실제 사용자의 사용 패턴 모두를 철저히 테스트해야 한다.

버그를 재현하는 것이 항상 쉬운 것만은 아니다. 따라서 코드를 고치지 전에 실패하는 테스트부터 작성해라. 그리고 제발 ‘오류 메시지 좀 읽어라’
프로그램이 죽은 지점부터 거꾸로 추적해 가도 되지만, 데이터에서 시작하는 것이 더 쉬운 경우도 있다. 릴리스 사이에 문제가 발생했을 수도 있다. 이진 분할 탐색으로 문제가 처음 발생하는 릴리스를 찾아보라.
코드가 무엇을 해야 하는지 누군가에게 차근차근 설명해 나가는 단순한 행위 그 자체로 충분할 때가 많다. 그것만으로도 여러분이 찾고 있던 문제가 화면 밖으로 뛰쳐나와 문제를 드러낸다. 들어줄 사람이 없다면 고무 오리도 괜찮다.
예상치 못한 ‘놀라운’ 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못됐다는 것을 받아들여야 한다. 버그와 관련된 루틴이나 코드가 제대로 작동하는 것을 증명해라. 이 맥락과, 데이터와 경계 조건을 바탕으로.

가정하지 말라. 증명하라

버그를 마주쳤을 때, 고치는 것을 넘어서 문제가 왜 더 일찍 발견되지 않았을지 생각해봐야 한다. 그런 버그를 예방할 수 있는 테스트를 수정해야 할지 고민해보라. 그리고 버그에 대해서 팀 전체와 토론해서 다음번에 발생할 수 있는 문제를 대비해라.

텍스트 처리

커니핸과 파이크의 프로그래밍 수련법에서는 동일한 프로그래밍을 다섯 개의 서로 다른 언어로 구현한다. 펄 버전이 가장 짧다. 텍스트를 처리하기 위해서 어떤 언어를 선택할지 고려해봐라. 우리는 루비로 출판 작업을 빌드한다. 모든 것을 일반 텍스트로 저장하고, 텍스트 처리 언어로 이를 처리한다면 많은 것을 배울 수 있을 것이다.

yaml 파일을 json 파일로 바꾸는 스크립트를 작성해라. 디렉토리를 인자로 받아서 그 안의 .yaml 파일을 .json 으로 바꿔야 한다.

모든 소스 파일을 검사하여 카멜케이스의 변수를 스네이크 케이스로 변경하는 스크립트를 만들어라

엔지니어링 일지

일지를 쓰면 좋은 점이 3가지가 있다.

• 기억보다 믿을만하다.
• 진행 중인 작업과 직접적인 관계가 없는 발사을 일단 쌓아 놓을 수 있는 곳이 생긴다. 위대한 발상을 잊어버릴 걱정 없이 지금 하는 일에 집중할 수 있다.
• 하던 일을 돌아보기에 알맞은 기회가 생긴다.

파일아니 위키말고 종이를 사용해라. 글씨를 쓰는 것은 키보드를 두드리는 것과는 다른 무언가 특별한 것이 있다.