Skip to main content

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. 소스코드 관리#

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

일반적으로 많이 쓰는 기능은 UndoRedo이며 이를 통해서 실수 전으로 돌아가는 부분입니다.

소스코드 관리 시스템 혹은 좀 더 넓은 의미의 형상 관리(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, 일반 텍스트 등등 원하는 어떤 결과물을 얻고자 할 때에도 코드 생성기를 쓸 수 있습니다.
Last updated on