Topic 16 - 일반 텍스트의 힘
일반 텍스트란?
인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야한다. 또한 사람이 이해할 수 있어야한다.
- 일반 텍스트
1 2
우유 커피
- 일반 텍스트가 아님
1 2
hlj;uijn bfjxrrctvh jkni’pio6p7gu;vh bjxrdi5rgvhj Field19=467abe
형식은 HTML, JSON, YAML 등 다양하다.
일반 텍스트는 데이터를 그 자체로만 이해할 수 있다. 이진포맷은 데이터를 읽는데 필요한 문맥과 데이터가 분리되어있어, 데이터를 읽는 문맥(애플리케이션 등)이 없으면 데이터는 무의미하다.
텍스트의 힘
- 지원 중단에 대한 보험
- 일반 텍스트는 이진형식과 달리 그 데이터를 읽는 문맥(시스템)이 없어져도 파싱이 가능하다.
- 기존 도구의 활용
- 새로운 도구가 나오더라도 텍스트형식은 항상 지원한다
- 더 쉬운 테스트
- 시스템 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 특별한 도구 없이도 테스트 데이터를 편집할 수 있다.
최소 공통분모
데이터를 서로 교환하는 시스템 간에 일반 텍스트는 하나의 표준이 된다.
Topic 17 - 셸 가지고 놀기
셸 프롬프트를 통해 모든 도구를 불러다 쓸 수 있다. 도구를 조합하여 자동화 시스템을 만들 수도 있으며, 복잡한 명령어 수행도 가능하다. GUI 환경에서는 제공된 기능만 사용가능하지만, 셸에서는 원하는 기능을 만들 수 있다.
명령어 셸의 힘을 사용하라.
셸에 익숙해지면 생산성은 급상승한다.
평소 GUI 에서 수동으로 하는 작업이 있다면 셸로 자동화 해보자
Topic 18 - 파워 에디팅
에디터에 유창해지면 작업속도를 빠르게 할 수 있을 뿐 아니라, 에디터 사용법을 생각하지 않고도 작업할 수 있게 된다. 그러면 생각이 자유롭게 흘러갈 것이고 이는 프로그래밍에 큰 도움이 될 것이다.
유창해지기
에디터를 사용하면서 무언가 같은 일을 반복하는 경우가 있을 것이다. 이 작업을 발견하면 더 나은 방법(단축키)가 있는지 찾아봐라. 찾았다면 그것을 의식적으로 사용해봐라. 시간이 지나면 무의식적으로 사용할 수 있게 된다.
Topic 19 - 버전 관리
VCS은 시스템의 거대한 실행 취소 키와 같은 것으로, 정상적으로 컴파일 되는 지난 버전으로 돌려놓을 수 있도록 해준다. 이외에도 공동 작업, 배포 파이프라인, 이슈 추적, 팀 상호작용까지 아우를 수 있다.
Topic 20 - 디버깅
디버깅에 관련된 몇몇 문제들을 살펴보고 버그를 찾아내는 일반적인 전략 몇가지를 알아보자
디버깅의 심리
비난 대신 문제를 해결하라
버그가 누구의 잘못인지는 중요하지 않다. 다만 해결해야할 사람은 나라는 걸 명심하자
디버깅 사고방식
당황하지 마라
- ‘그건 불가능해’ 란 생각을 하지마라. 실제로 일어났기 때문이다.
- 근시안에 빠지지마라. 표면에 드러난 증상만 고치지 말고, 실제 원인을 찾으려고 노력하라
실마리 찾기
- 작업중인 코드가 경고 없이 깨끗하게 빌드되는지 확인하라.
- 관련 자료를 모두 모아라.
- 실제 버그인지, 버그라면 자세한 현상이 무엇인지 자료를 요구하라
- ex) 실제 시연되는 영상 등
디버깅 전략
버그 재현하기
버그를 고치는 가장 좋은 방법은 버그를 재현할 수 있게 하는 것이다. 버그를 명령하나로 재현할 수 있으면 더 좋다.
코드를 고치기 전 실패하는 테스트부터
버그가 발생하는 상황을 다른 것들로부터 분리하면 버그를 고칠 힌트를 얻을 수도 있다.
미지의 세계에 온 프로그래머
그놈의 오류 메세지 좀 읽어라
프로그램이 죽었다면 빨간색 예외 메시지를 무시하지마라
프로그램이 죽는 것이 아니라 결과가 이상한 상황이면 어떨까? 디버거를 붙인 다음 실패하는 테스트를 이용하여 문제를 재현하라. 그리고 먼저 디버거에 잘못된 값이 나타나는 지부터 확인하라.
이진 분할
거대한 스택 트레이스가 눈앞에 있을때, 이중에 정확히 어떤 부분에서 문제가 되는지 찾기 위해서는 중간부터 이진 분할 기법으로 찾을 수 있다.
입력값이 따라 버그가 발생하는 경우에도 정확히 어떤 입력값이 범인인지 이진분할을 통해 찾을 수 있다.
어떤 릴리스에서 버그가 발생하는지 찾고 싶은 경우에도 문제가 없던 릴리스와 현재 버전 사이에서 이진분할을 시도할 수 있다.
로깅과 트레이싱
트레이싱 구문은 ‘여기까지 도달’이나 ‘x값 = 2’ 같은 정보를 화면이나 파일에 출력하는 작은 진단용 메시지이다. 트레이싱은 여러 프로세스가 동시에 작동하는 경우, 특히 시간이 중요한 시스템에서는 중요한 정보가 된다.
트레이싱 구문으로 남기는 메세지는 규칙적이어야하며 일관된 형식이어야한다.
고무 오리
누군가(고무 오리도 괜찮다)에게 문제를 설명함으로써 원인을 찾을 수도 있다. 차근차근 코드를 설명함으로써 당연히 여기고 넘어갔을 부분을 명시적으로 이야기하게 되고, 그러면 문제가 보일 수 있다.
소거법
OS, 외부 라이브러리, 외부 제품에서 오류를 찾지 마라. 대개 외부 제품을 잘못 사용하고 있다고 생각하는 것이 더 낫다. 설사 외부 제품에 문제가 있다하더라도 우리 애플리케이션 코드에 문제가 없다는 걸 확인은 해야한다.
만약 하나만 변경했는데 시스템의 작동이 멈춘다면, 관련이 없어보여도 변경된 그 하나에 책임이 있다.
때로는 외부 제품이 새로운 버전으로 바뀌면서 버그가 생길 수도 있다. 따라서 이럴때는 새 조건하에서 시스템을 다시 테스트해봐야한다.
놀라운 구석
당연하다고 생각되는, 버그가 없을거라 생각되는 부분에서도 버그가 생길 수 있다. 버그가 발생한 데이터로, 맥락으로 다시 그 코드를 테스트하라. 이 경계 조건하에서 증명하라.
가정하지 말라. 증명하라.
이러한 놀라운 버그를 발견했을때는 단순히 고치는 것을 넘어 어떻게하면 미리 잡을 수 있었을지를 생각해보라. 그리고 버그를 고치는 김에 동일한 버그가 있을 법한 다른 코드도 확인하고, 지금 고쳐라.
버그가 누군가의 잘못된 가정으로 발생했다면 이 문제에대해 전체 팀과 함께 토론하라. 한 사람이 오해했다면 다른 사람도 그럴 수 있다.
디버깅 체크리스트
- 보고된 문제가 내재하는 버그의 직접적 결과인가 아니면 단순히 증상일 뿐인가?
- 버그가 정말로 여러분이 사용하는 프레임워크에 있나? OS에? 아니면 여러분 코드에 있나?
- 이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가?
- 의심가는 코드가 단위 테스트를 통과한다면 테스트는 충분히 갖춰진 것인가? 이 데이터로 테스트를 돌리면 무신일이 생가는가?
- 이 버그를 야기한 조건이 시스템의 다른 곳에도 존재하는가?
Topic 21 텍스트 처리
텍스트에 특화되어 처리해주는 도구가 있다 ex) sed, awk, 파이썬, 루비 등
이러한 텍스트 처리 도구는 중요한 기반 기술이며, 이러한 도구를 사용하면 유틸리티를 쉽게 만들거나, 아이디어를 프로토타입화 해볼 수 있다.
텍스트 처리 언어를 익혀라
Topic 22 엔지니어링 일지
회의에서 메모하거나, 작업 내용을 쓸때, 디버깅하다가 변수의 값을 적을때, 무엇을 어디 두었는지, 엉뚱한 생각을 기록할때 등 사용한다.
일지를 쓰면 좋은 점이 있다
- 기억보다 믿을만하다
- 진행 중인 작업과 직접적 관계가 없는 발상을 일단 쌓아놓을 수 있다.
- 무엇가를 쓰면서 환기를 시킬 수 있다.