[실용주의 프로그래머] 3장. 기본 도구

오늘 TIL 3줄 요약

• 1번
• 2번
• 3번

---

책에서 기억하고 싶은 내용을 써보세요.

3장 기본 도구(p.103 - p.144)

▶ Topic 16. 일반 텍스트의 힘

• 우리가 수집하는 요구사항은 지식이고, 우리는 그 지식을 설계와 구현, 테스트, 문서로 표현한다.

일반 텍스트란?

• 데이터 그 자체만으로 의미가 드러나는 데이터 → 데이터를 생성하는 애플리케이션에 독립적인 데이터
• 사람이 읽을 수 있고 별도의 추가 과정 없이 이해할 수 있는 데이터
• 형식이 없는 텍스트가 아님 → HTML, JSON, YAML || HTTP, SMTP, IMAP 등의 핵심 프로토콜 역시 일반 텍스트
• 최소 공통분모
  • 모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야한다면, 일반 텍스트가 바로 그 표준이다.

지식을 일반 텍스트로 저장하라.

▷ 장점

• 지원 중단에 대한 보험
  
  • 본래의 애플리케이션에 대한 지원이 중단되더라도 일반 텍스트 파일은 살아남는다.
  • 포맷을 부분적으로 밖에 알지 못하더라도 파싱할 수 있다.
• 기존 도구의 활용
  • 버전 관리 시스템에서 에디터, 명령 줄 도구에 이르기까지 컴퓨터 세계ㅒ의 거의 모든 도구는 일반 텍스트를 다룰 수 있다.

cf) 유닉스 철학
- 작고 예리한 각각의 도구가 한 가지 일만 잘하도록 만들자는 철학에 따라 설계됨
- 줄 단위로 처리하는 일반 텍스트 파일을 기반 포맷으로 공유하기 때문에 가능
- 유닉시는 모든 시스템 관리용 데이터 베이스를 일반 텍스트 파일로 저장

• 더 쉬운 테스트
  • 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.
  • 회귀테스트가 결과를 일반 텍스트로 내보내면 셸 명령이나 간단한 스크립트로 손쉽게 분석할 수 있다.

 

▶ Topic 17. 셸 가지고 놀기

• 텍스트 파일을 다루는 프로그래머에겐 명령어 셸이 곧 작업대.
• 모든 작업을 GUI로만 하면 여러분이 가진 환경의 능력을 전부 이용할 수 없다.
  • GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.
• 실용주의 프로그래머는 오직 코드만 쏟아내거나, 객체 모델만 개발하거나, 문서만 작성하거나, 빌드 과정 자동화만 하지 않는다. 이 모든 일을 다 한다. GUI 환경에서 이런 작업을 하는 도구의 사용 범위는 보통 그 도구가 사용되리라고 예상되는 작업에 한정된다.

명령어 셸의 힘을 사용하라.

GUI의 장점은 WYSIWYG - 여러분이 보는 것이 여러분이 얻는 것
GUI의 단점은 WYSIAYG - 여러분이 보는 것이 여러분이 얻는 전부라는 것

자신만의 셸

• 색깔 조합 설정
• 프롬프트 설정
• 별칭alias과 셸 함수
• 명령어 자동 완성

 

▶ Topic 18. 파워 에디팅

• 텍스트는 프로그래밍의 기본 원재료이므로 여러분은 텍스트를 최대한 손쉽게 조작할 수 있어야 한다.

에디터를 유창하게 fluency 쓸 수 있게 하라.

• 여러분이 에디터를 사용하는 모습을 관찰하라. 무언가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라. '분명 더 나은 방법이 있을 텐데.' 그리고 더 나은 방법이 있는지 찾아보라.
• 유용한 기능을 찾았다면 반복을 통해 반사적으로 사용할 수 있게 하라.
• 확장 기능을 통해 에디터를 성장시켜라.

 

▶ Topic 19. 버전 관리

• 버전 관리 시스템 version control system, VCS 은 일종의 거대한 '실행 취소' 키와 같다.
  • 프로젝트 전체에 걸쳐서 코드가 실제로 컴파일 되고 실행되던 지난주의 평화로운 시절로 돌려줄 수 있는 타임머신이다.
  • + 공동 작업, 배포 파이프라인, 이슈 추적, 일반적인 팀 상호작용
• 공유 디렉터리는 버전 관리 시스템이 아니다. 지속 불가능한 공유. 
  • 주 저장소를 네트워크 드라이브나 클라우드에 두는 버전 관리도 위험하다. 버전 관리 소프트웨어는 일련의 파일 및 디렉터리들과 상호작용 하기 때문이다. 두 군데에서 동시에 변경이 일어나면 전체 상태가 꼬일 수 있다.
• 모든 것을 버전 관리 아래에 둬라 
• 중앙 저장소를 두는 방식이 좋다. 중앙 저장소가 있으면 프로젝트 업무 흐름을 원활하게 해 주는 수많은 확장 기능을 이용할 수 있기 때문이다.

 

▶ Topic 20. 디버깅

참으로 고통스러운 일입니다.
자신이 겪는 어려움을 보고는 알게 되죠.
다른 누구도 아닌 바로 자신이 문제를 만들었다는 걸.
- 소포클레스, 《아이아스》

• 안타깝지만 지금도 컴퓨터 시스템은 여전히 여러분이 명령하는 것을 할 뿐, 여러분이 원하는 것을 알아서 하지 않는다.

▷ 디버깅의 심리

비난 대신 문제를 해결하라.

• 디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
• 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.

▷ 디버깅의 사고 방식

가장 속이기 쉬운 사람은 자기 자신이다.
- 에드워드 불워-리턴 《의절》

당황하지 말라.

• 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각해 보는 것이 정말 중요하다.
• 겉으로 드러난 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.

▷ 실마리 찾기

• 버그를 살펴보기 전에 일단 작업 중인 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라.
• 처음에 버그를 보고한 사용자를 인터뷰할 필요도 있다.
• 경계 조건과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 체계적으로.

 

□ 디버깅 전략

버그 재현하기

코드를 고치기 전 실패하는 테스트부터.

• 버그가 발생하는 상황을 다른 것들로부터 분리하다 보면 어떻게 고쳐야 할지에 대한 통찰을 얻기도 한다.

그놈의 오류 메시지 좀 읽어라.

이진 분할
- 분할 정복 divide and conquer 방식을 사용해라. 즉, 중앙값을 골라라.

로깅과 트레이싱

• 디버거는 일반적으로 프로그램의 현재 상태에 주목한다. 그러나 때로는 시간에 따라 프로그램이나 데이터 구조의 상태가 변하는 것을 관찰해야 할 때도 있다.
• 트레이싱 구문은 화면 혹은 파일에 출력하는 작은 진단용 메시지를 일컫는다.
• 디버거가 진단할 수 없는 몇 가지 종류의 오류를 진단하는 데에 매우 효과적이다. 특히, 시간 자체가 중요한 요소가 되는 시스템에서 이루 말할 수 없이 소중하다.
• 호출 트리 call tree에서 내려갈 때마다 트레이싱 구문을 추가할 수 있다.
• 트레이싱 구문으로 남기는 메시지는 규칙적이고 일관된 형식이어야 한다.

고무 오리

• 코드가 무엇을 해야하는지 차근차근 설명해 나가는 단순한 행위 그 자체
• 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다. 이 과정에서 문제에 대한 새로운 통찰을 불현듯이 얻을 수도 있다.

소거법

• 외부 제품에 문제가 있더라도 버그 리포트를 제출하기 전에 여러분의 코드에 문제가 없다는 것을 확인해야 한다.
• 자신의 실수일 수 있는 일을 시스템의 문제라고 탓하기 시작하면 우리는 "select가 망가졌어"라고 한다.

"select"는 망가지지 않았다.

놀라운 구석

가정하지 말라. 증명하라

• 어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.

디버깅 체크 리스트
- 보고된 문제가 내재하는 버그의 직접적 결과인가 아니면 단순히 증상일 뿐인가?
- 버그에 정말로 여러분이 사용하는 프레임워크에 있나? OS에? 아니면 여러분의 코드에 있나?
- 이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가?
- 의심 가는 코드가 단위 테스트를 통과한다면 테스트는 충분히 갖춰진 것인가? 이 데이터로 테스트를 돌리면 무슨 일이 생기는가?
- 이 버그를 야기한 조건이 시스템의 다른 곳에도 존재하는가? 다른 버그가 유충 단계에서 성충이 될 날만 기다리고 있는 것은 아닌가?

 

▶ Topic 21. 텍스트 처리

• 제대로 사용하기만 한다면 루터와 텍스트 처리 언어 둘 다 믿기 힘들 정도로 강력하고 쓰임새가 다양하다.
• 적절히 사용하면 이 도구들은 놀라울 정도로 예리하고 섬세하다. 하지만 숙달하는 데에는 시간이 걸린다.

텍스트 처리 언어를 익혀라.

 

▶ Topic 22. 엔지니어링 일지

일지의 장점 (종이 일지)

• 기억보다 더 믿을 만하다.
• 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있다.
• 하던 일을 돌아보기에 알맞은 기회가 생긴다.

 

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

미뤄뒀다가 한 번에 읽으면서 정리를 하려니 시간이 너무 오래걸렸다. 앞으로는 평일에 한 장을 읽어야 할 때는 점심 시간 등을 활용해서 틈틈이 읽어 두어야할 것 같다. 아직 사회 초년생인 내가 보기에도 점점 실무에 직접 관련되는 내용들이 많이 등장하고 있는 것 같다.

이번 TIL 에서부터는 각 주제 별로 느낀 점을 정리해보고 싶었는데 시간이 여의치 않아서 스킵... 그래도 아직 업무를 시작한 지 얼마 안 된 나에게 제일 와닿았던 부분은 일반 텍스트의 힘과 버전 관리, 디버깅 부분이었다.

모든 텍스트는 사람이 이해할 수 있도록 만들어져야 한다는 부분은 변수명이나 함수명을 작성할 때 명심해야 할 것 같다.

디버깅 파트는 아직 제대로 개발을 해보지 않았음에도 본능적으로 계속 머리에 새기려고 하고 있었다. 아마 나는 무수히 많은 버그들을 생산해 낼 것이 분명한데, 항상 버그의 원인은 나에게 있다는 걸, 또 사람에게 있다는 것을 명심해두고 이 밖의 내용들을 체화시킬 수 있도록 반복해서 읽어야 할 것 같다.

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• grep: 여러 파일에서 문자열을 찾는 도구. 과거 ed 라는 편집에서 비슷한 일을 하는 명령이었던 "g/re/p"에서 유래. re는 찾고자하는 정규표현식 의미
• 회귀 테스트 regression test: 동일한 테스트를 반복적으로 수행함으로써 새로운 기능이 애플리케이션에 추가되었을 때 기존 기능이 여전히 제대로 작동하는지 검사하는 테스트. 회귀 테스트에서 찾아낸 문제를 리그레션 regression이라고 함.
• 체크섬: 하기 링크 참고

[네트워크] 체크섬 (checksum)

 

---

오늘 읽은 다른 사람의 TIL (URL)

https://flynndev.notion.site/2022-03-23-DAY-05-5e2efb73d6f444edaf365e02c30980d6