오늘 TIL 3줄 요약

• 원재료로는 이해하고 다루기 쉬운 일반텍스트를 사용하자
• 셸, 에디터, VCS, 디버깅, 범용텍스트처리도구 등을 익혀 생산성을 높이자!
• 도구들의 기본적인 사용법을 익히고, 필요에 따라 능동적으로 필요한 도구들을 추가시켜나가자.

TIL (Today I Learned) 날짜

2022.03.23

오늘 읽은 범위

3장 기본 도구

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

• 일반적으로 사용하는 기본 도구들로 시작하라. 점차 경험을 쌓고 특별한 요구 사항을 만나면서 이 기본 세트에 다른 도구를 추가하게 될 것이다. 앞에서 말한 목수처럼 자신의 도구 상자에 주기적으로 뭔가를 추가하게 될 것이라 예상하라. 언제나 일을 하는 데에 더 나은 방법이 없는지 살펴라. 사용하는 도구로 다룰 수 없는 문제를 마주쳤다는 생각이 들면, 도움이 될 만한 뭔가 다른 것이나 더 강력한 것을 찾아보아야 한다는 것을 명심하라. 필요에 따라 도구를 취하도록 하라.

Topic 16 일반 텍스트의 힘

• 일반 텍스트를 사용하면 수작업으로든 프로그램으로든 동원 가능한 거의 모든 도구로 지식을 다룰 수 있게 된다.
  대부분의 이진binary 포맷은 데이터를 이해하는데 필요한 문맥이 데이터 자체와 별도로 분리되어 있다는 문제가 있다.

일반 텍스트란?

• 일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다.
• 우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 한다.

텍스트의 힘

• 일반 텍스트가 형식이 없는 텍스트를 의미하는 것은 아니다. HTML, JSON, YAML 등은 모두 일반 텍스트다. HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다.

일반 텍스트가 널리 쓰이는 이유는 다음과 같다.

지원 중단에 대한 보험

• 사람이 읽을 수 있는 형태의 데이터와 그 자체만으로 의미가 드러나는 데이터는 다른 어떤 형태의 데이터보다, 심지어 그 데이터를 생성한 애플리케이션보다 더 오래 살아남을 것이다.
• 일반 텍스트 파일은 포맷을 부분적으로밖에 알지 못하더라도 파싱할 수 있다.이진 파일은 대부분 제대로 파싱하려면 전체 포맷을 세세한 사항까지 모두 알아야만 한다

기존 도구의 활용

• 버전 관리 시스템에서 에디터, 명령 줄 도구에 이르기까지 컴퓨터 세계의 거의 모든 도구는 일반 텍스트를 다룰 수 있다.
• 유닉스Unix는 작고 예리한 각각의 도구가 한 가지 일만 잘하도록 만들자는 철학에 따라 설계된 것으로 유명하다. 이 철학은 줄 단위로 처리하는 일반 텍스트 파일을 기반 포맷으로 공유하기 때문에 가능해졌다. 유닉스에서는 사용자, 비밀번호, 네트워크 설정 등 시스템 관리용 데이터베이스를 모두 일반 텍스트 파일로 저장한다. 일반 텍스트는 검색도 더 쉽다. 시스템 백업을 어떤 설정 파일에서 관리하는지 기억이 나지 않더라도 grep -r backup /etc로 순식간에 찾을 수 있다.

더 쉬운 테스트

• 시스템 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 특별한 도구특별한 도구를 만들 필요 없이를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수있다. 비슷하게 회귀 테스트가 결과를 일반 텍스트로 내보내면 셸 명령이나 간단한 스크립트로 손쉽게 분석할 수 있다.

최소 공통분모

• 모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야 한다. 일반 텍스트가 바로 그 표준이다.

Topic 17 셸 가지고 놀기

• 텍스트 파일을 다루는 프로그래머에겐 명령어 셸이 작업대다. 셸 프롬프트에서 모든 종류의 도구를 불러다 쓸 수 있다. 파이프를 이용해 원 개발자가 꿈도 꾸지 못했을 방식으로 도구를 결합할 수도 있다. 셸에서 응용 프로그램이나 디버거, 브라우저, 에디터, 유틸리티를 실행할 수 있다. 파일을 검색할 수 있고, 시스템의 상태를 조회할 수 있으며, 출력을 필터링할 수 있다. 또한 셸을 프로그래밍해서 자주 수행하는 작업을 수월하게 해 주는 복잡한 매크로 명령을 만들 수도 있다.
  -> 멋지다!!
• GUI의 장점은 WYSIWYGWhat You See Is What You Get, 즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 WYSIAYG What You See Is All You Get, 즉 여러분이 보는 것이 여러분이 얻는 전부전부라는 것이다.

Topic 18 파워 에디팅

• 텍스트는 프로그래밍의 기본 원재료이므로 여러분은 텍스트를 최대한 손쉽게 조작할 수 있어야 한다.
• 각각의 에디터에 유창해지도록 노력해야 한다.
• 유창해지는 것의 가장 큰 이점은 더는 에디터 사용법을 생각하지 않아도 된다는 것이다. 뭔가를 생각하는 것에서 에디터 화면에 그게 뜰 때까지의 거리가 확 줄어든다. 생각이 자유롭게 흐를 것이고 프로그래밍에 큰 도움이 될 것이다.

어떤 것이 유창한 것인가?

• 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라. - 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라.
• 변경한 코드의 들여쓰기indent를 자동으로 맞춰라.
• 여러 줄의 코드를 명령 하나로 주석 처리했다가 다시 주석을 해제하라.
  -실행 취소를 여러 번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라.
• 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.
• 특정 줄 번호로 이동하라.
• 여러 줄을 선택한 후 가나다순으로 정렬하라.
• 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라. - 선택 영역이나 패턴 검색을 이용하여 일시적으로 여러 개의 커서를 만든 다음, 동시에 여러 곳의 텍스트를 편집하라.
• 현재 프로젝트의 컴파일 오류를 표시하라.
• 현재 프로젝트의 테스트를 실행하라.
  -> 내가 현재 에디터를 유창하게 사용하고 있는지 점검할 수 있었다.

유창해지기

• 먼저 여러분이 에디터를 사용하는 모습을 관찰하라. 무언가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라. 분명 더 나은 방법이 있을 텐데. ^그리고 더 나은 방법이 있는지 찾아보라.*
• 유용한 기능을 새로 찾았다면 이 기능을 여러분의 몸이 기억하도록 만들어야 한다. 그래야 반사적으로 사용할 수 있다. 우리가 아는 유일한 방법은 반복이다.

에디터 성장시키기

• 에디터의 확장 기능 언어를 파헤쳐 보라.
• 온전한 확장 기능을 만들어 낼 수도 있을 것이다. 그렇다면 그 확장 기능을 공개하라

Topic 19 버전 관리

• 진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다.- 조지 산타야나(George Santayana), Life of Reason(이성의 삶)

소스 코드부터 시작

• 버전 관리 시스템은 실수를 되돌리는 것 외에도 아주 많은 일을 한다.
• 코드의 이 줄을 누가 바꿨을까? 현재 버전과 지난주 버전은 어디가 달라졌나? 이번 릴리스에 코드를 몇 줄이나 바꿨을까? 어느 파일이 가장 자주 바뀌나? 이런 종류의 정보는 버그 추적이나, 감사audit, 성능 관리, 품질 관리를 해야 할 때 매우 귀중하다.
• 언제나. 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 버리기로 한 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도, 모든 것모든 것을 버전 관리 아래에 둬라. 각종 문서, 전화번호 목록, 외부 업체에 보내는 메모, makefile, 빌드와 릴리스 절차, 로그 파일을 정리하는 작은 셸 스크립트까지 모두 다. 우리는 우리가 키보드로 입력하는 거의 모든 것에 대해 일상적으로 버전 관리 시스템을 사용한다.

프로젝트 허브로서의 버전 관리

• 개인 프로젝트에도 매우 유용하긴 하지만 버전 관리는 팀에서 사용할 때 그 진가가 드러난다.

다음과 같은 기능이 있어야 한다.

• 확실한 보안과 권한 관리
• 직관적인 UI
• 명령 줄에서도 모든 작업 수행 가능(작업을 자동화할 때 필요하다.)
• 자동화된 빌드와 테스트
• 브랜치 병합(풀 리퀘스트pull request라고 부르기도 한다)을 잘 지원
• 이슈 관리. 커밋이나 브랜치 병합과 연계가 가능하고 지표도 구할 수 있으면 이상적이다.
• 적절한 보고서 기능. 칸반 보드Kanban board 형식으로 처리할 이슈나 작업을 표시할 수 있으면 매우 유용하다.
• 원활한 팀 의사소통을 돕는 기능. 변경 사항이 있을 때 이메일 혹은 다른 수단으로 알려준다든지, 위키를 제공한다든지 하는 등등
• VCS를 다음과 같이 설정해 놓는 팀이 많다. 특정 브랜치에 푸시push를 하면 시스템을 빌드하고, 테스트를 수행한 다음, 테스트가 성공하면 새로운 코드를 서비스에 배포한다.무서운 방식 같은가? 버전 관리 시스템을 사용한다면 걱정하지 않아도 된다. 언제든지 롤백rollback, 즉 되돌릴 수 있다.
  -> 지금 내가 해보고 싶은 것

Topic 20 디버깅

디버깅의 심리

• 기술의 전당에서는 남을 비난하기보다 문제문제를 고치는 데에 집중해야 한다.

디버깅 사고방식

• 무엇보다도 다음 디버깅 제1 법칙을 기억하라.Tip 30 당황하지 말라.
• 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각생각해 보는 것이 정말 중요하다.
• 디버깅할 때 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라. 실제 문제는 여러분 눈앞에 있는 것에서 몇 단계 떨어져 있고, 또 다른 여러 가지와 연관되어 있을 확률이 다분하다.

실마리 찾기

• 버그를 살펴보기 전에살펴보기 전에 일단 작업 중인 코드가 경고 없이 깨끗하게 빌드되는지부터 확인하라.
• 컴퓨터가 대신 찾아 줄 수 있는 문제를 여러분이 찾느라 시간을 허비한다는 건 말도 안 된다! 우리는 당면한 더 어려운 문제에 집중해야 한다.
• 경계 조건boundary condition과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다.

디버깅 전략

• 여러분이 무슨 일이 벌어지고 있는지 파악했다는 생각이 들었다면, 이번에는 프로그램은 어떻게 생각하는지 알아낼 차례다.
• 버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다. 무엇보다, 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?
• 디버깅의 가장 중요한 규칙은 이것이다.
  Tip 31 코드를 고치기 전 실패하는 테스트부터.

미지의 세계에 온 프로그래머

• Tip 32 그놈의damn 오류 메시지 좀 읽어라.

이상한 결과

• 디버거를 붙인 다음 여러분의 실패하는 테스트를 이용하여 문제를 재현하라. 무엇보다 먼저 디버거에 잘못된 값이 나타나는지부터 확인하라
• 디버거에서 호출 스택 위아래로 어떻게 이동하고, 스택의 지역 변수를 어떻게 확인하는지 숙지하라.
• 옆에 종이와 펜을 가져다 두고 메모를 하면 도움이 될 때가 많다. 우리 경험상 가끔 실마리를 발견하고 쫓아 들어갔지만 결국 허탕을 쳤을 때 메모가 특히 도움이 되었다.

이진 분할

• 종종 이분 탐색, 이진 검색binary search 등으로도 부르는데, 발상은 단순하다. 정렬된 배열에서 특정한 값을 찾고 싶다. 맨 앞부터 하나씩 차례대로 값을 확인할 수도 있겠지만, 그러면 원하는 값 혹은 원하는 값보다 큰 값을 만날 때까지 평균적으로 대략 배열 길이의 절반만큼을 확인해야 한다.
• 배열에서 가운데에 위치한 값, 즉 중앙값을 골라라. 이 값이 원하는 값이면 멈춘다. 아니면 중앙값을 기준으로 배열을 둘로 쪼갠다. 원하는 값이 중앙값보다 작으면 앞쪽 배열에 원하는 값이 있을 것이고, 중앙값보다 크면 뒤쪽 배열에 원하는 값이 있을 것이다.
• 중간 즈음에서 스택 프레임을 하나 골라서 값이 정상인지 확인한다. 정상이라면 그 위의 프레임들을 확인해야 하고, 아니라면 그 밑의 프레임들을 확인해야 한다. 다시 이진 분할을 반복한다. 스택 트레이스에 프레임이 64개나 있더라도 이 방식을 사용하면 6번 안에 답을 찾아낼 수 있다.
• 특정 데이터 세트에 대해서만 버그가 나타나는 경우에도 마찬가지로 이진 분할을 사용할 수 있다.

로깅과 트레이싱

• 트레이싱tracing 구문은 여기까지 도달이나 'x값 = 2'같이 화면 혹은 파일에 출력하는 작은 진단용diagnostic 메시지를 일컫는다.
• 호출 트리call tree에서 내려갈 때마다 트레이싱 구문을 추가할 수 있다.
• 트레이싱 구문으로 남기는 메시지는 규칙적이고 일관된 형식이어야 한다. 메시지를 자동으로 분석해야 할 수도 있기 때문이다.
• 메시지를 로그 파일에 남겨 볼 수 있다. 로그 파일을 텍스트 처리 도구와 셸 명령어로 처리하면 문제를 일으키는 open을 쉽게 찾아낼 수 있다.

고무 오리

• 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다. 이런 가정 몇 가지를 입 밖에 내면, 문제에 대한 새로운 통찰을 불현듯이 얻을 수도 있다.

소거법

• 대개 애플리케이션 코드가 라이브러리를 잘못 호출하고 있다고 가정하는 편이 라이브러리 자체에 문제가 있다고 가정하는 것보다 낫다.

놀라운 구석

• 뭔가 잘못될 때 놀라는 정도는 실행되는 코드에 갖는 신뢰와 믿음의 정도에 비례한다. 그렇기 때문에 예상치 못한 놀라운 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다.
• 버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 안다고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.
• 놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서 왜 이 문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다. 버그를 미리 잡을 수 있도록 단위 테스트나 다른 테스트를 수정할 필요가 있는지 고민해 보라.
• 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자. 바로 지금 그것들을 찾아서 고쳐야 한다. 어떤 일이 일어났어떤 일이 일어났든지 간에든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.
• 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체 팀과 함께 토론하라. 한 사람이 오해했다면 다른 사람들도 그럴 수 있다.

Topic 21 텍스트 처리

• 가끔은 이런 기본 도구만으로는 해내기 힘든 종류의 변환 작업이 있다. 범용 텍스트 처리 도구가 필요한 것이다.
• 훌륭한 텍스트 처리 언어가 많이 있다. 유닉스나 맥을 사용하는 개발자들은 명령어 셸의 능력을 즐겨 활용하는 경우가 많은데, 여기에 awk나 sed와 같은 도구를 결합하여 사용하기도 한다. 좀 더 체계적인 도구를 선호하는 사람들은 파이썬이나 루비 같은 프로그래밍 언어를 더 좋아한다.
• 이들을 사용해서 유틸리티를 뚝딱 만들어 낼 수도 있고, 아이디어를 프로토타입해 볼 수도 있다. 전통적인 언어를 사용하면 다섯 배에서 열 배 가까이 더 오래 걸릴 것이다.

Topic 22 엔지니어링 일지

일지를 쓰면 좋은 점이 크게 세 가지 있다.

• 기억보다 더 믿을 만하다.
• 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다. 그러면 위대한 발상을 잊어버릴 걱정 없이 지금 하는 일에 계속해서 집중할 수 있다.
• 고무 오리와 같은 역할을 할 수 있다. 무언가를 쓰기 위해 하던 일을 멈추면 여러분의 뇌도 기어를 바꾼다. 누군가에게 이야기를 하는 것과 비슷하다. 하던 일을 돌아보기에 알맞은 기회가 생기는 것이다.
• 수년 전에 여러분이 무엇을 하고 있었는지 돌이켜 볼 수 있다.

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

• 내가 개발자로서 갖춰야 할 도구가 무엇인지에 대해서 한 번 정리해볼 수 있었다.
• 셸과 범용텍스트 처리도구를 이용한 생산성향상에 대해 기대가 많이 된다. 데이터의 조작과 그 조작방식이 매우 자유도가 높아보이는 것이 굉장히 멋져 보인다! 빠른 시일 내로 셸과 텍스트처리언어를 배울 것이다. 배워서 귀찮은 일을 자동화시키는 것도 해볼 것이다.

오늘 읽은 다른사람의 TIL

https://nomadcoders.co/community/thread/3908