🔖 오늘 읽은 범위 : 3장. 기본도구
❗ 소감 3줄 요약- 혼자 진행하는 프로젝트더라도 기록을 남기자
- 완벽한 코드는 없다. 버그는 항상 존재한다고 생각하자
- 올바른 디버깅 순서, 디버깅 방법
😃 책에서 기억하고 싶은 내용을 써보세요.[ 일반 텍스트의 힘 ]
실용주의 프로그래머로서 우리의 기본재료는 나무나 쇠가 아니라 지식이다.
지식을 저장하는 최고의 포맷이 일반 텍스트라고 믿는다.일반 텍스트란?
일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다. 쇼핑 목록처럼 간단할 수도 있다.
우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 한다.
텍스트의 힘
HTML, JSON, YAML 등은 모두 일반 텍스트다. HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다.
지원 중담에 대한 보험
일반 텍스트 파일은 포맷을 부분적으로밖에 알지 못하더라도 파싱할 수 있다.
더 쉬운 테스트
시스템 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.
[ 셸 가지고 놀기 ]
GUI의 장점은 WYSIWYG (What You See Is What You Get), 즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 WYSIAYG (What You See Is All You Get), 즉 여러분이 보는 것이 여러분이 얻는 전부라는 것
자신만의 셸
목수가 작업 공간을 자신에게 맞추어 바꾸듯이 개발자도 셸을 자신에게 맞추어야 한다.
- 색깔 조합 설정
- 프롬프트 설정
- 별칭과 셸 함수
- 명령어 자동 완성
[ 버전 관리 ]
우리가 사용자 인터페이스에서 중요하게 여기는 것 중에 실행 취소undo 키가 있다. 실수를 용서해 주는 버튼.
하지만 실수가 지난주에 발생했고 그 이후로 컴퓨터를 열 번은 껐다 켰다면 어떨까? 이것이 바로 버전 관리 시스템 (version control system), VCS을 사용하는 데서 생기는 여러 가지 이득 가운데 하나다.
버전 관리 시스템은 소스 코드나 문서의 모든 변경 사항을 기억한다. 바르게 설정된 버전 관리 시스템이 있으면 소프트웨어의 이전 버전으로 언제든지 되소프트웨어의 이전 버전으로 언제든지 되돌아갈 수 있다.
혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 버리기로 한 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도, 모든 것을 버전 관리 아래에 둬라.
브랜치 사용하기
브랜치의 장점 중에 다른 브랜치로부터 격리된다는 것이 있다.
프로젝트 허브로서의 버전 관리
- 확실한 보안과 권한 관리
- 직관적인 UI
- 명령 줄에서도 모든 작업 수행 가능(작업을 자동화할 때 필요하다.)
- 자동화된 빌드와 테스트
- 브랜치 병합(풀 리퀘스트pull request라고 부르기도 한다)을 잘 지원
- 이슈 관리. 커밋이나 브랜치 병합과 연계가 가능하고 지표도 구할 수 있으면 이상적이다.
- 적절한 보고서 기능. 칸반 보드Kanban board 형식으로 처리할 이슈나 작업을 표시할 수 있으면 매우 유용하다.
- 원활한 팀 의사소통을 돕는 기능. 변경 사항이 있을 때 이메일 혹은 다른 수단으로 알려준다든지, 위키를 제공한다든지 하는 등등
[ 디버깅 ]
버그라는 단어는 14세기 이래 공포의 대상을 지칭하는 단어로 사용되어 왔다. 코볼COBOL의 창안자인 해군 제독 그레이스 호퍼 박사는 최초로 컴퓨터에서 버그, 그러니까 벌레를 발견한 것으로도 알려져 있다.
지금도 컴퓨터 시스템은 여전히 여러분이 명령하는 것명령하는 것을 할 뿐, 여러분이 원하는 것원하는 것을 알아서 하지 않는다.
디버깅의 심리
- 디버깅은 단지 문제 풀이문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
- 남을 비난하기보다 문제문제를 고치는 데에 집중해야 한다.
디버깅 사고방식
- 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각생각해 보는 것이 정말 중요하다.
- 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.
실마리 찾기
- 버그를 살펴보기 전에살펴보기 전에 일단 작업 중인 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라.
- 우리는 우연한 사건들을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다.
- 자세한 정보를 충분히 얻으려면 해당 버그를 보고한 사용자가 시연하는 것을 눈으로 직접 확인해야 할 수도 있다.
디버깅 전략
여러분이 무슨 일이 벌어지고 있는지 파악했다는 생각이 들었다면, 이번에는 프로그램은 어떻게 생각하는지 알아낼 차례다.
버그 재현하기
- 버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다.
- 우리는 명령 하나로 재현할 수 있기를 바란다. 버그가 출현하는 시점까지 열다섯 단계를 거쳐야 한다면 버그 수정은 훨씬 어렵다.
- 디버거를 붙인 다음 여러분의 실패하는 테스트를 이용하여 문제를 재현하라.
- 디버거에서 호출 스택 위아래로 어떻게 이동하고, 스택의 지역 변수를 어떻게 확인하는지 숙지하라.
디버깅 전략
- 예상치 못한 놀라운 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다.
- 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 안다고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락이 맥락 안에서, 이 데이터이 데이터로, 이 경계 조건이 경계 조건하에서 증명하라.
- 버그를 수정하는 김에, 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자. 바로 지금 그것들을 찾아서 고쳐야 한다. 어떤 일이 일어났어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.
- 버그를 고치는 데 시간이 오래 걸린다면 왜 그런지 자문하라. 무엇을 하면 다음번에는 이 버그를 좀 더 쉽게 고칠 수 있을까? 더 나은 테스트 훅을 만들어 넣거나, 로그 파일 분석기를 작성할 수도 있겠다.
