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, 일반 텍스트 등등 원하는 어떤 결과물을 얻고자 할 때에도 코드 생성기를 쓸 수 있습니다.