1 주차
수 | Assignment #05
3장. 기본 도구
📘 책에서 기억하고 싶은 내용
- 일반 텍스트의 힘 (p.105)
XML, HTML, JSON, YAML 및 HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다.
- 셸 가지고 놀기 (p.110)
- 모든 작업을 GUI로만 하면 내가 가진 환경의 능력을 전부 이용할 수 없다.
- GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.
- 색깔 조합 설정, 프롬프트 설정, 별칭과 셸 함수, 명령어 자동 완성을 통하여 개발자 편의성 증대가 가능하다.
- 파워 에디팅 (p.114)
- 에디터를 사용하며 특정 행위를 반복한다면 개선하고, 개선한 방법을 의식적으로 사용하도록 하라.
- 마우스 없이 키보드를 사용하는 방법을 연습하다 보면 처음엔 불편하지만 생산성을 크게 높일 수 있다.
- 버전 관리 (p.119)
- 공유 디렉토리, 네트워크 드라이브, 클라우드는 지속 가능한 버전 관리 시스템이 아니다.
- 혼자서 진행하는 경우나 나중에 버리기로 한 프로토타입일지라도 버전 관리가 필요하다.
- 중앙 저장소를 두면 프로젝트 업무 흐름을 원활하게 해주는 수많은 확장 기능을 이용할 수 있다.
- 디버깅 (p.125)
- 다른 사람의 버그를 발견하면 버그를 만들어 낸 범죄자를 비난하기보다 문제를 고치는 데에 집중해야 한다.
- '하지만 정말 그럴 리가 없는데.'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라.
- 디버깅할 때 근시안의 함정에 주의하라, 실제 문제는 몇 단계 떨어져 있고 또 다른 여러 가지와 연관되어 있을 확률이 다분하다. 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본적인 원인을 찾으려고 노력하라.
- 컴파일러의 경고 수준을 최고로 높게 맞춰 컴퓨터가 대신 찾아 줄 수 있는 문제를 찾느라 시간을 허비하지 않도록 한다.
- 인공적인 테스트는 애플리케이션을 충분히 테스트하지 못하기 때문에 경계 조건과 실제 최종 사용자의 사용 패턴 모두 철저히 테스트해야 한다.
- 코드를 고치기 전 실패하는 테스트부터 생성한다.
- 매우 긴
Stack Trace를 봐야 할 때는 이진 분할을 이용한다.
- 중간 즈음에서 스택 프레임을 하나 골라 해당 시점에 값이 정상인지 확인하고, 아니라면 이를 다시 반복한다.
- 문제가 발생한 릴리즈 버전을 찾을 때도 이러한 방식을 사용할 수 있지만 VCS가 테스트 결과에 따라 문제가 발생한 릴리스를 찾게 할 수도 있다.
트레이싱 구문 : 도달 여부 등을 알기 위해 화면 혹은 파일에 출력하는 진단용 메시지
- 메시지를 자동으로 분석해야 할 수도 있으므로 규칙적이고 일관된 형식이어야 한다.
- 누군가에게 코드를 설명하다 문제점을 찾게 될 수도 있다.
- 단 하나만을 변경했음에도 시스템이 작동을 멈춘다면 아무 관련 없어도 변경한 그 하나에 책임이 있다.
- 놀라운 버그를 발견했을 때 고치는 것을 넘어 왜 더 일찍 발견되지 않았을지 고민해야 한다.
- 이것과 유사한 버그가 있을 법한 다른 코드가 있는지도 확인해야 한다.
- 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체 팀과 함께 토론하라.
- 텍스트 처리 (p.139)
- 텍스트 처리 언어를 익혀 유틸리티, 프로토타입 등에 활용해보자. (전통적인 언어를 사용했을 때보다 시간 단축이 가능하다.)
- 엔지니어링 일지 (p.142)
- 파일이나 위키 말고 종이를 사용하여 엔지니어링 일지를 작성하라.
- 진행중인 작업과 직접적인 관계가 없는 발상을 쌓아 놓을 수 있다.
🤔 소감 및 생각
- 당연하지만 지키기 어려웠던 내용도 있고, 새로운 내용도 있어 읽는 데에 지루하지 않은 것 같다. 디버깅 관련 내용이 가장 인상 깊었다.
🔍 새롭게 또는 다시 알게 된 내용
