1. 일반 텍스트의 힘
개발자는 지식을 수집하고 그 지식을 표현한다. 그리고 지식을 저장하는 최고의 포맷은 일반 텍스트이다.
일반 텍스트란 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자로 이루어진 텍스트이다.
일반 텍스트로 작성된 데이터는 다른 형태의 데이터보다 오래 살아남을 수 있고 사용될 가능성도 더 높다. 또한 대부분의 도구들이 일반 텍스트를 다룰 수 있으므로 호환성이 뛰어나다.
게다가 시스템 테스트를 구동하게 할 합성 데이터를 만들기 위해 일반 텍스트를 사용하면 간단하게 테스트 데이터를 추가, 수정할 수 있다.
물론 일반 텍스트는 이진 포맷보다 용량이 크고, 해석하는데 더 많은 계산이 필요하기 때문에 일반 텍스트를 사용하지 못하는 경우가 있다.
이런 경우에도 원 데이터의 메타데이터를 일반 텍스트로 저장해 사용할 수 있다.
2. 조개 놀이
GUI 인터페이스와 IDE에 익숙한 사람에게 셸은 불편하기만 한 도구처럼 보일 것이다.
물론 간단한 작업이라면 GUI도 문제 없지만, 눈에 보이는 것 외에는 사용할 수 없다는 것이 한계이다.
셸을 사용하면 가진 환경의 전체 능력을 사용할 수 있고, GUI가 지원하지 않는 작업도 직접 만들어서 사용할 수 있다.
3. 파워 에디팅
코드를 작성한다면 에디터에서 작성하게 될 것이다.
어떤 에디터를 사용하든 그 에디터의 기능을 마스터하고, 텍스트를 편집할 때 반사적으로 필요한 키를 입력할 수 있을 정도가 되어야 한다.
4. 소스코드 관리
코드를 작성하면서 개인적으로 많이 사용하는 기능은 되돌리기 기능(cmd+z)이라고 생각한다.
코드 전체에서 본다면 문제가 발생한 코드를 문제가 발생하기 이전의 상태로 돌리는 것은 반드시 필요한 기능인데 이를 소스코드 관리 시스템(SCCS)이 대신해준다.
물론 실수를 취소해주는 것 외에도 버전간의 차이나 코드의 어떤 라인을 누가 변경했는지와 같은 정보도 제공해준다.
프로젝트를 SCCS의 관리하에 둠으로써 생기는 가장 큰 이득은 빌드의 자동화와 반복일 것이다.
빌드를 자동화함으로써 일관성을 보장하고 특정 소스를 언제나 다시 빌드할 수 있어 빌드를 반복할 수 있다.
5. 디버깅
완벽한 소프트웨어는 없다.
결국 개발자는 버그와 싸워야 하는 운명이지만, 버그를 대하는 자세는 잘못된 경우가 많다.
버그는 비난의 대상이 아니라 단지 해결해야 할 문제이다.
디버깅을 할 때는 올바른 사고방식을 가지고 해야 하는데, 당황하지 말고 버그의 원인이 무엇인지 생각해 보는 것이 중요하다. 또한 표면에 보이는 증상만 고치는 것이 아니라 근본적인 원인을 발견하려는 노력이 필요하다.
디버깅 전략은 다음과 같다.
-
데이터 가시화
데이터 사이의 상호관계를 시각화할 수 있는 디버거를 통해 데이터에 대한 더 깊은 통찰을 얻을 수 있다. -
트레이싱
디버거는 프로그램의 현재 상태에 주목하지만, 가끔은 시간에 따른 상태 변화를 봐야 할 필요도 있다.
트레이싱 구문을 통해 디버거가 진단할 수 없는 종류의 에러를 진단할 수 있다. 트레이싱 구문이란 화면 혹은 파일에 출력하는 작은 진단용 메시지이다. -
고무 오리
코드가 무엇을 수행하는지 한줄 한줄 고무 오리에게 설명함으로써, 혼자 코드를 볼 때는 당연하게 여겼던 부분을 명시적으로 이야기해야 하고, 이를 통해 문제가 스스로 드러나게 할 수 있다. -
제거 과정
버그가 발생하면 다른 사람의 코드, OS, 컴파일러, 서드파티 제품에 버그가 있다고 생각하는 것보다 자신의 코드에 버그가 있을 가능성이 더 높다.
버그가 발생했을 때, 기존에 자신이 세운 가정들이 잘못되었다는 것을 깨달아야 한다. 버그에 관련된 루틴이나 코드가 제대로 작동한다고 '안다'고 대충 넘기지 말고 맞다는 것을 '증명'해야 한다.
6. 코드 생성기
개발을 하면서 같은 기능을 서로 다른 맥락에서 필요로 할 때가 있다. 이처럼 같은 정보를 다른 여러 곳에서 반복해야 할 때 코드 생성기를 만들면 수고를 줄일 수 있다.
코드 생성기는 두 가지 종류가 있다.
-
수동적 코드 생성기
타이핑을 줄여주는 것이 목적이다. 몇 개의 입력에서 주어진 출력을 생성하는 매개변수화 된 템플릿이다.
새 소스 파일을 생성할 때 필요한 요소들을 미리 넣어주거나, 언어간 변환을 수행하는데 사용하기도 하고 런타임에 계산하기에 비용이 많이 드는 참조 테이블 등의 자원을 생성할 때도 사용할 수 있다. -
능동적 코드 생성기
수동적 코드 생성기가 단지 편하려고 쓰는 것이라면 능동적 코드 생성기는 DRY 원칙을 따르려면 반드시 사용해야 하는 것이다.
능동적 코드 생성기를 사용하면 어떤 지식을 단 하나의 형태로만 만들어 놓고 애플리케이션이 필요로 할 때 다양한 형식으로 변환할 수 있다.
예를 들어 한 애플리케이션에서 여러 프로그래밍 언어를 사용하는 경우, 언어 중립적인 형태로 공통 정보를 표현한 후 코드 생성기에서 이를 읽어 각 언어의 코드를 생성함으로써 중복을 방지할 수 있다.
코드 생성기는 반드시 코드만 생성해야 할 필요는 없고, HTML이나 일반 텍스트를 생성할 때도 사용할 수 있다.
