3. 기본적인 도구
- 신입 개발자는 IDE와 같은 제약없이 능숙하게 개발할 수 있어야합니다.
Item 14. 일반 텍스트의 힘#
- 실용주의 개발자로서 기본 재료는 지식입니다.
- 요구사항을 지식으로 수집하고, 그 지식을 설계, 구현, 테스트 그리고 문서에 표현합니다.
- 지식을 저장하는 최고의 포맷은 일반 텍스트(plain text)입니다.
일반 텍스트란#
- 일반 텍스트란 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자입니다.
- 일반 텍스트를 사용하면 애플리케이션과 상관없이 의미있는 데이터 흐름을 얻을 수 있습니다.
Tip 20. 지식을 일반 텍스트로 저장하라
단점#
일반 텍스트의 단점은 크게 두 가지가 있습니다.
- 압축된 이진 포맷을 사용하는 것보다 더 많은 공간을 차지할 수 있습니다.
- 일반 텍스트 파일을 해석하고 처리하는 데에 더 많은 계산이 필요할 수 있습니다.
텍스트 힘#
일반 텍스트로 얻을 수 있는 부분은 다음과 같습니다.
- 구식이 되는 것에 대한 보험
- 호환성
- 더 쉬운 테스트
구식이 되는 것에 대한 보험#
- 사람이 읽을 수 있는 형태의 데이터와 자명한 데이터는 다른 형태의 데이터와 애플리케이션보다 생명이 깁니다.
유닉스 철학
- 유닉스는 작고 예리한 각각의 도구가 한 가지 일만 잘 하도록 만들자는 철학에 따라 설계된 것으로 유명합니다.
- 이 철학은 라인 중심의 일반 텍스트 파일을 기반 포맷으로 공유하므로 가능합니다.
- ex) <주민번호>990909-xxxxxxx</주민번호>
호환성#
- 소스코드 관리 시스템, 컴파일러 환경, 에디터, 단독으로 사용되는 필터에 이르기까지 컴퓨팅 세계의 거의 모든 도구들은 일반 텍스트를 다룰 수 있습니다.
더 쉬운 테스트#
- 특별한 도구를 만들어야 할 필요 없이 간단히 테스트 데이터를 추가, 업데이트, 수정할 수 있습니다.
최소 공통분모(LCM)#
이질적인 환경에서는 일반 텍스트의 장점은 모든 단점을 보상하고도 남습니다.
Item 15. 조개 놀이(Shell Games)#
- 모든 목공은 훌륭하고 튼튼한 작업대를 필요로 합니다.
- 텍스트 파일들을 다루는 프로그래머에게는 명령어 셸이 작업대가 됩니다.
- 셸 프롬프트는 모든 종류의 도구를 불러쓸 수 있습니다.
- GUI는 환경의 전체 능력을 이용못한다는 단점이 있습니다.
- GUI 환경은 일반적으로 설계자의 의도에 따른 제약을 받습니다.
- 명령어 쉘은 간결하고 강력합니다.
- ex) Makefile보다 더 최근에 수정된 모든 .c 파일을 찾아라
find . -name '*.c' -newer Makefile -print
Tip 21. 명령어 쉘의 힘을 사용해라
셸 유틸리티와 윈도우 시스템#
- 윈도우 명령어 셸이 점점 더 나아지고 있습니다.
- Cygwin이나 책에는 없는 Powershell 이 그 예시입니다.
Item 16. 파워 에이팅#
에디터는 일종의 연장입니다.
하나의 에디터#
- 에디터에 대해 능숙해질 필요가 있습니다. (단축키 등)
Tip 22. 하나의 에디터를 잘 사용합니다.
- 에디터 하나를 골라서 완전히 마스터하고 모든 편집 작업에 그 에디터를 사용합니다.
- 선택한 에디터가 사용하는 모든 플랫폼에서 가능한지 확인합니다.
에디터의 기능#
설정변경 가능#
- 에디터의 모든 요소(폰트, 색깔, 윈도우 크기, 키입력 바인딩) 등을 기호에 맞게 설정할 수 있어야합니다.
확장 가능#
- 새 프로그래밍 언어가 나왔다고 쓸모없는 구식이 되어서는 안됩니다.
프로그램 가능#
- 복잡하고 다단계의 작업을 수행할 수 있도록 에디터를 프로그램할 수 있어야합니다.
더 나은 기능#
- 구문 강조(syntax highlighting)
- 자동 완성
- 자동 들여쓰기
- 코드나 문서 상용어구 지원
- 관련 도움말 시스템
- IDE 기능 (컴파일, 디버그 등)
생산성#
- 위의 측면에서 메모장은 그러한 좋은 에디터는 아닙니다.
- 특정 에디터는 자동으로 템플릿을 제공하기 때문에 매우 편리합니다.
- 클래스와 모듈 이름이 채워져 있습니다.
- 이름과 저작권이 선언됩니다.
- 해당 언어의 프로그램 뼈대(생성자, 소멸자 선언 등)
- 자동 들여쓰기를 통해 에디터가 적절한 시기에 자동으로 들여쓰기를 해줍니다.
Item 17. 소스코드 관리#
진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운영이다.
일반적으로 많이 쓰는 기능은 Undo와 Redo이며 이를 통해서 실수 전으로 돌아가는 부분입니다.
소스코드 관리 시스템 혹은 좀 더 넓은 의미의 형상 관리(configuration management) 시스템은 소스코드나 문서 관련의 모든 변화를 기억합니다. 이를 통해 언제든 소프트웨어의 이전 버전으로 되돌아 갈 수 있습니다.
SCCS는 다음의 기능을 추가적으로 제공합니다.
- 변화를 기록하여 수정 사항, 자주 바뀌는 파일, 릴리스에 코드가 얼마나 바뀐지 등을 확인할 수 있습니다.
- 정보들은 버그 추적, 감사, 퍼포먼스, 품질 관리 목적으로 매우 귀중하게 쓰입니다.
- 릴리스들을 구분할 수 있게 제공합니다.
- 브랜치를 통해 선택된 몇 개의 수정사항을 주된 줄기와 자동으로 합쳐주는 기능을 제공합니다.
- 소스코드 관리 시스템은 관리하는 파일들을 중앙 저장소에 유지할 수 있는 데 이는 아카이브를 위한 좋은 선택입니다.
- 동일한 파일에 대해 동시에 수정이 가능하도록 합니다.
Tip 23. 언제나 소스코드 관리 시스템을 사용합니다.
소스 코드 관리와 빌드#
- 제품 빌드를 자동화하고 그것을 반복할 수 있습니다.
- 빌드를 자동화하는 것은 일관성을 보장해줍니다.
소스코드 관리 시스템을 사용하지 않으면...#
- 매우 부끄러운 상황입니다.
- 모듈이나 빌드가 안되는 이유 등에 대해서 확인해야할 때 이는 답이 될 것입니다.
대표적인 소스코드 관리 시스템#
RCS, CVS, Aegis 트랜잭션 기반 형상 관리, ClearCase, MKS Source Integrity, PVCS 형상 관리, Visual Sourcesafe, Perforce...
Item 18. 디버깅#
참으로 고통스러운 일입니다. 자신이 겪는 어려움을 보고는 알게 되죠. 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 걸.
- 버그는 공포의 대상에 어원이 있습니다.
- 아무도 완벽한 소프트웨어를 작성하지 못하기 때문에 디버깅에 많은 시간을 보내야합니다.
디버깅 심리#
- 디버깅은 문제 해결이라는 사실을 받아들이고 방식으로 공략해야합니다.
- 기술에서는 남의 버그를 비난하기보다는 문제를 고치는 것에 더 집중해야합니다.
Tip 24. 비난 대신 문제를 해결하라
디버깅 사고방식#
가장 속이기 쉬운 사람은 자기 자신이다.
- 디버깅을 할 때는 스스로를 편안하게 해야합니다. (자기합리화도 하면 안됩니다.)
Tip 25. 디버깅을 할 때 당황하지 마라
- 실제로 원인이 무엇일지 생각해보는 것이 중요합니다.
- 그건 불가능하다라는 생각은 하지 않습니다. 이미 그럴 수도 있고 일어난 일입니다.
- 디버깅을 할 때 표면에 보이는 증상만 고치려는 욕구에 저항하고 실제 문제와 연관이 있는지 알아야합니다.
어디서 시작할지#
- 해당 버그를 살펴보기 전 깨끗이 컴파일된, 경고문 없는, 코드로 작업하는 지 확인합니다.
- 처음에 받은 자료 이상을 얻기 위해서는 버그를 보고한 사용자를 인터뷰할 필요도 있습니다.
- 인공 테스트는 애플리케이션을 충분히 테스트하지 못합니다. 경계 조건(boundary condition)과 실제 최종 사용자 사용 패턴을 모두 철저히 테스트해야합니다.
디버깅 전략#
버그 재현(reproduction) : 버그가 정말 발생하지 않는다는 것을 확인하는 방법은 버그를 재현할 수 있게 만드는 것입니다.
데이터를 가시화하라#
- 데이터와 데이터들 사이에 존재하는 모든 상호관계를 시각화할 수 있는 디버거를 사용하면 자신의 데이터에 대해 훨씬 더 깊은 통찰을 얻을 수 있습니다.
- 때로 그림으로 나타낸 것이 천마디의 말보다 훨씬 더 가치가 있습니다.
트레이싱(tracing)#
- 디버거는 일반적으로 프로그램의 현재 상태에 주목합니다.
- 스택 트레이스는 단지 여기에 어떻게 도달했는지를 말해줄 수 있습니다.
- 트레이싱 구문은 여기까지 도달이나 파일에 출력하는 작은 진단용 메시지(diagnostic)를 의미합니다.
- 디버깅보다 원시적인 방법이나, 디버깅이 진단할 수 없는 몇가지 종류의 예시에서 특별히 효과적입니다.
- 동시 프로세스, 실시간 시스템, 이벤트 기반 애플리케이션 등
- 트레이싱 메시지는 규칙적이고 일관적인 형식이어야합니다.
고무 오리#
- 문제의 원인을 찾는데 매우 단순하나 유용한 기법으로, 누군가에게 그걸 설명하는 단순한 방법입니다.
- 이를 통해서 과정이나 명시적으로 생각했던 부분에 대해서 확인이 되며, 통찰력을 얻을 수 있게됩니다.
제거 과정#
- 함께 작업을 하다보니 플랫폼 환경이 섞이고 코드가 섞이는 경우가 있습니다.
- 시스템도 버그가 있을 수 있으나 대부분은 애플리케이션의 오류입니다.
Tip 26. 'select'는 망가지지 않았다.
- 탐색의 위치가 오래되어 찾기힘들다면, 이진검색을 통해서 멀리 떨어진 두 코드에서 어디에 증상이 발생하고 가운데 지점에서 확인을 하면서 넘어갑니다.
놀람의 요소#
- 놀라운 일이 일어났으면 자기가 세운 가정들이 잘못되었음을 깨달아야합니다.
Tip 27. 가정하지 마라. 증명하라.
- 놀라운 버그를 마주하면 그것을 고치는 것에 넘어서 왜 실패를 일찍 발견되지 못했는지에 대한 단위 테스트, 다른 테스트를 수정할 필요에 대해 고민해봐야합니다.
- 버그가 일어나기전부터 일종의 단계를 거쳐서 불량 데이터가 넘어왔다면 매개 변수 검사 등이 필요했을지에 대한 고민을 합니다. (일찍 자동 멈추기나 단정문 등을 사용)
- 다른 곳에서 동일한 버그가 있을 수 있는지에 대해서 고민해봐야합니다.
- 버그가 다른 사람이 만든 결과라면 이를 팀과 공유해서 다른 사람들이 그러한 버그를 만들지 않도록 공유합니다.
디버깅 체크 리스트#
- 보고된 문제는 버그의 직접적 결과인지 단순히 증상인지
- 버그가 정말로 컴파일러? OS? 아님 코드인가
- 이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가
- 의심가는 코드가 단위 테스트를 통과한다면 테스트는 충분히 완전한 것인가? 이 데이터로 단위 테스트를 돌리면 어떻게 되는가?
- 이 버그 조건이 시스템의 다른 곳에도 존재하는가
Item 19. 텍스트 처리#
- 때로는 기본 도구 세트가 아닌 범용 텍스트 처리 도구가 필요합니다.
- 대표적인 예시로 간단한 스크립트를 만들 때는 Perl을 사용합니다.
- c는 150줄 perl은 17줄.
Tip 28. 텍스트 처리 언어를 하나 익혀라.
애플리케이션 샘플#
- 데이터베이스
스키마 관리- 데이터베이스를 만드는 SQL 명령문
- 데이터 사전을 채워 넣은 데이터 파일들
- 데이터베이스를 액세스하는 C 코드 라이브러리
- 데이터베이스 무결성을 확인하는 스크립트
- 자바 속성 액세스
- ex. lombok
- getter/sett를 통해 액세스를 제한 하는 것이 좋은 객체지향, 이 또한 없애는 것이 좋음
- 테스트 데이터 생성
- 서적 집필
- C에서 오브젝트 파스칼 인터페이스로
- 웹 문서 생성
- swagger?
Item 20. 코드 생성기#
프로그래머는 상황에 따라 코드 생성기를 만들어 프로젝트의 비용을 줄일 수 있습니다.
Tip 29. 코드를 작성하는 코드를 작성하라
일반적으로 다음의 유형을 가집니다.
- 수동적 코드 생성기 : 결과를 내기 위해 한 번만 실행되며, 결과물은 독립적이 됩니다.
- 능동적 코드 생성기 : 코드 생성이 필요할 때마다 작동되며, 코드는 일회용입니다.
수동적 코드 생성기#
수동적 코드 생성기는 타이핑을 줄여줍니다. 일반적으로 기본적인 몇 개의 입력에서 주어진 출력을 생성하는 매개 변후화된 템플릿입니다.
- 새 소스 파일 생성
- 수동적 코드 생성기는 프로젝트에서 새로운 파일을 만들 때마다 반복되는 것을 수정합니다.
- 프로그래밍 언어간 일회용 변환을 수행하기
- 반드시 정확할 필요는 없습니다.
- 런타임에 계산하기엔 비용이 많이 드는 참조 테이블과 여타 자원을 생성
능동적 코드 생성기#
- DRY 원칙을 위해서 필수적으로 사용해야합니다.
- 어떤 지식을 단 하나의 형태로만 만들어놓고 애플리케이션이 필요로 하는 온갖 형식으로 변환 가능합니다.
- 필요할 때마다 코드 생성기가 만들며 중복이 아닙니다.

- 다른 경우 예시로는 코드를 다른 프로그래밍 언어로 수정하는 경우도 있습니다.
코드 생성기가 꼭 복잡할 필요는 없다.#
- 입력 형식을 단순하게 만들면 코드 생성기도 단순하게 합니다.
코드 생성기가 꼭 코드를 생성해야할 필요는 없습니다.#
- HTML, XML, 일반 텍스트 등등 원하는 어떤 결과물을 얻고자 할 때에도 코드 생성기를 쓸 수 있습니다.