TIL 3장. 기본 도구 – 노마드 코더 Nomad Coders

자신의 기본 도구 상자에 어떻게 투자할지?
도구가 손의 연장(extension)이 될 수 있도록!
'분명 더 나은 방법이 있을텐데'
IDE가 갖는 한계를 넘어설 수 있어야 한다! - 유일한 방법은 기본 도구들을 언제나 곧바로 사용할 수 있도록 예리하게 유지하는 것. 도구들의 사용법을 배우는 데에 시간을 투자하라

TIL (Today I Learned) 날짜

2022.03.23

오늘 읽은 범위

3장. 기본 도구

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

개발자를 목수에 빗대어 어떻게 일을 하면 '더 나은 방법'으로 작업을 할 것인가?

작업 step1. 원재료, 모양을 만들어 나갈 재료 논의
- Topic 16. 일반 텍스트의 힘

우리가 수집하는 요구사항은 지식이고, 우리는 그 지식을 설계와 구현, 테스트, 문서로 표현한다.
일반 텍스트를 사용하면 수작업으로든 프로그램으로든 동원 가능한 거의 모든 도구로 지식을 다룰 수 있게 된다.

인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖춘 사람이 이해할수 있는것이 일반 텍스트 이다.
형식이 없는 텍스트를 의미하진 않는다. HTML, JSON, YAML 등등 과 HTTL, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로코콜도 대부분 일반 텍스트이다.

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

일반 텍스트가 널리 쓰이는 이유 3가지

지원 중단에 대한 보험
: 일반 텍스트 파일은 포맷을 부분적으로밖에 알지 못하더라도 파싱할 수 있다.
이진 파일은 대부분 제대로 파싱하려면 전체 포맷을 세세한 사항까지 모두 알아야만 한다.
기존 도구의 활용
: 버전 관리 시스템에서 에디터, 명령 줄 도구에 이르기까지 컴퓨터 세계의 거의 모든 도구는 일반 텍스트를 다룰 수 있다.
더 쉬운 테스트

작업 step2. 작업대, 컴퓨터. 사용하는 도구에서 어떻게 효용을 최대한 끌어낼지 논의
- Topic 17. 셸 가지고 놀기

모든 목수는 훌륭하고 튼튼하며 믿을 만한 작업대가 필요하다.
=> 텍스트 파일을 다루는 프로그래머에겐 명령어 셸이 작업대다.

모든 작업을 GUI로만 하면 여러분이 가진 환경의 능력을 전부 이용할 수 없다.

일반적인 작업을 자동화할 수 없고,
가용한 도구의 역량을 온전히 사용할 수 없다.
도구를 결합해서 자신에게 꼭 맞는 '매크로 도구' 를 만들 수 없다.

GUI의 장점, WYSIWYG(what you see is what you get) : 여러분이 보는 것이 여러분이 얻는 것

GUI의 단점, WYSIAYG(what you see is all you get) : 여러분이 보는 것이 여러분이 얻는 전부
=> GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.

=> 명령어 셸의 힘을 사용하라

목수가 작업 공간을 자신에게 맞추어 바꾸듯이 개발자도 셸을 자신에게 맞추어야 한다.
떄로는 여러분이 사용하는 터미널 프로그램의 설정을 바꾸어야 할 수도 있다.

색깔 조합 설정
프롬프트 설정
: 현재 디렉터리 경로를 짧게 줄인 것, 버전 관리 시스템 상태, 시간 정도만 표시하도록 설정
별칭(alias)과 셸 함수
명령어 자동 완성

작업 step3. 원재료와 작업대가 갖추어 졌으니 작업을 할 도구에 대해서 논의
- Topic 18. 파워 에디팅

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

=> 에디터를 유창하게(fluency) 쓸 수 있게 하라.

왜 에디터에 유창해지는 것이 중요?

: 더는 에디터 사용법을 생각하지 않아도 된다는 것. 모든 동작을 일일이 생각하면서 운전하는 초보 운전자와 의식하지 않고 차를 모는 경험 많은 운전자는 완전히 다르다.

에디터 사용이 유창하다고 볼 수 있는 과제 체크리스트! 아래의 과제들을 마우스나 트랙패드 없이 모두 수행할 수 있는지 체크해보자.

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

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

작업 step4. 소중한 작업물, 심지어 개인 자료까지 잃어버리지 않기 위한 관리에 대해서 논의
- Topic 19. 버전 관리

버전 관리 시스템(version control system, VCS)은 일종의 거대한 '실행 취소' 키와 같다.
=> 프로젝트 전체에 걸쳐서 코드가 실제로 컴파일되고 실행되던 지난주의 평화로운 시절로 돌려줄 수 있는 타임머신이다.
=> 공동작업과 배포 파이프라이, 이슈 추적, 일반적인 팀 상호작용까지 아우를 수 있다.

VCS 를 사용하면?

소프트웨어의 이전 버전으로 언제든지 되돌아갈 수 있다.
변경 사항을 추적할 수 있다.
: 버그 추적, 감사(audit), 성능 관리, 품질 관리를 해야 할 때 유용
소프트웨어의 특정 릴리스를 찾을 수 있다.
VCS가 관리하는 파일들을 중앙 저장소에도 복제해 두면 자료를 장기간 보관하기에 탁월한 도구가 된다.
둘 이상의 사용자가 동일한 파일을 동시에 작업할 수 있다.
개발 중인 내용을 섬처럼 따로 떼어 격리하는 '브랜치branch' 기능을 사용하여 프로젝트의 어느 시점에나 브랜치를 만들 수 있다. 작업한 브랜치를 나중에 다른 브랜치로 '병합merge' 할 수도 있다
프로젝트 허브로서의 버전 관리 - 중앙 저장소가 있으면 프로젝트 업무 흐름을 원할하게 해 주는 수많은 확장 기능을 이용할 수 있다.

=> 언제나 버전 관리 시스템을 사용하라

언제나. 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 '버리기로 한' 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도, 모든 것을 버전 관리 아래에 둬라.

작업 step5. 위대한 작업자, 디버깅의 고수가 되기 전에는 위대한 프로그래머가 될 수 없다
- Topic 20. 디버깅

소프트웨어 결함은 요구 사항을 오해하는 것부터 코딩 오류에 이르기까지 여러 모습으로 나타난다.
안타깝지만 지금도 컴퓨터 시스템은 여전히 여러분이 명령하는 것을 할 뿐, 여러분이 원하는 것을 알아서 하지 않는다.

디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

=> 비난 대신 문제를 해결하라

마감일이 코앞이거나 버그의 원인을 찾는 동안 신경질적인 상사나 의뢰인이 여러분에게 바짝 붙어서 감시하고 있다면 더더욱 당황하기 쉽다.
하지만 한발짝 뒤로 물러나서 여러분이 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각해 보는 것이 정말 중요하다.

=> 당황하지 말라

실제 문제는 여러분 눈앞에 있는 것에서 몇 단계 떨어져 있고, 또 다른 여러 가지와 연관되어 있을 확률이 다분하다.
겉으로 드러난 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.

=> 디버깅할 때 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨내라.

버그 실마리 찾기 - 버그를 정확하게 파악하기

처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰할 필요도 있다.
경계 조건(boundary condition)과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다.

버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다.

디버깅의 가장 중요한 규칙!
버그가 발생하는 상황을 다른 것들로부터 분리하다 보면 어떻게 고쳐야 할지에 대한 통찰을 얻기도 한다. 테스트를 작성하는 행위가 해결책을 알려주는 것이다.

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

우리가 프로그래밍 실습이 포함된 수업을 할 때면, 빨간색 예외 메시지가 튀어나오면 냅다 탭키를 눌러서 코드로 직진하는 개발자가 얼마나 많은지 늘 놀라울 따름이다.

=> 그놈의damn 오류 메시지 좀 읽어라

이진 분할binary chop을 이용한 디버깅

거대한 스택 트레이스
: 검색을 시작하기 위해 여러분은 중간 즈음에서 스택 프레임을 하나 골라서 값이 정상인지 확인.
정상이라면 그 위의 프레임들을 확인해야 하고,
아니라면 그 밑의 프레임들을 확인해야 한다. 다시 이진 분할을 반복한다.
특정 데이터 세트에 대해서만 나타나는 버그
: 데이터 세트를 둘로 나누고, 각각을 프로그램에 넣었을 때 문제가 발생하는지 살펴보라.
문제가 발생하는 가장 작은 데이터 세트를 만들 때까지 나누기를 반복한다.
현재 릴리스에서 예전 릴리스에는 없었던 버그가 발생

: 현재 릴리스에서 실패하는 테스트를 만들어라.
문제가 없었던 버전 중 가장 최근 버전과 현재 버전 사이에서 중간 정도에 위치한 릴리스를 골라라.
테스트를 수행한 후, 결과에 따라 어느쪽을 탐색할지 골라라.

트레이싱 구문이 디버거가 진단할 수 없는 몇가지 종류의 오류를 진단하는 데에 효과적

여러 프로세스가 동시에 작동하는 경우
실시간real-time 시스템
이벤트 기반 애플리케이션
시간 자체가 중요한 요소가 되는 시스템

코드가 무엇을 해야 하는지 차근차근 설명해 나가는 단순한 행위 그 자체로 여러분이 찾고 있던 문제가 화면 밖으로 뛰쳐나와 모습을 드러낸다.

=> 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다.

개발하고 있는 애플리케이션 코드에 버그가 존재할 가능성이 OS나 컴파일러 혹은 외부 제품에 버그가 있을 가능성 보다 훨씬 더 크다.

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

버그와 관련된 루틴이나 코드가 제대로 작동하는 걸 '안다'고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.
놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서 왜 이문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다.

=> 가정하지 말라. 증명하라

디버깅 체크 리스트

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

작업 step6. 여러 마술같은 작업들을 한군데 모아 붙이려면 접착제가 필요하다
- Topic 21. 텍스트 처리

프로그래밍에서 텍스트 처리 언어는 목공에서 '루터router'와 같다.
둘 다 시끄럽고, 지저분하며, 어느 정도는 무식하게 완력brute force을 쓰는 것이다.
사용하다가 실수라도 하면 재료 전체를 망가트릴 수 있다.
제대로 사용하기만 한다면 루터와 텍스트 처리 언어 둘 다 믿기 힘들 정도로 강력하고 쓰임새가 다양하다.

=> 텍스트 처리 언어를 익혀라

유닉스나 맥을 사용하는 개발자들은 명령어 셸의 능력을 즐겨 활용하는 경우가 많은데, 여기에 awk나 sed와 같은 도구를 결합하여 사용하기도 한다.
좀 더 체계적인 도구를 선호하는 사람들은 파이썬이나 루비 같은 프로그래밍 언어를 더 좋아한다.

마지막 작업. 아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다. 생각과 역사를 기록으로 남겨라
- Topic 22. 엔지니어링 일지

회의에서 메모할 때, 작업하는 내용을 써 놓을 때, 디버깅하다가 변수의 값을 적어 놓을 때, 무엇을 어디 두었는지 기록을 남길 때, 엉뚱한 생각을 기록할 때, 아니면 때로는 그냥 낙서할 때 일지를 쓴다.

일지를 쓰면 좋은 점 세가지

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

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

장인은 도구를 탓하지 않는다는 말이 있다. 장인 자체가 너무나도 재능이 넘치기에 그가 처한 환경이 잘낫기에 아니면 그 외 미쳐 파악하지 못한 외부의 어떠한 요인 때문에 장인이 된것이 아니다.
장인이 되기까지 장인 타이틀을 가지게 된 작업물을 만들게 되기까지 재료를 고르는 것부터 시작해 작업대를 최적의 작업물을 만들수 있도록 마련해 나가는 과정과 만드는 작업물을 지속적으로 추적 관리하여 다듬어가며 잘못된 작업물의 정확한 원인을 파악하여 개선해나가고 그러한 모든 역사들을 잊지 않기 위해 기록해나가는 그 모든 과정들을 장인 '스스로가' 했기에 장인은 도구를 탓하지 않을 수 있는것이라는 생각을 해보았다.

프로그래밍을 업으로 삼는 프로그래머로써 '장인' 혹은 '고수' 프로그래머가 되길 원한다면 그 실천의 첫걸음이자 지속적으로 걸어야 할 걸음과 같은 지식이 이번 3장을 통해 얻은 지식이 아닐까?

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

트레이싱tracing 구문 : '여기까지 도달' 이나 'x값 = 2' 같이 화면 혹은 파일에 출력하는 작은 진단용diagnostic 메시지를 일컫는다.
=> 버그를 찾기 위한 로그를 넣는 작업 대부분이 트레이싱 구문에 해당하고 있었다.
sed : https://jhnyang.tistory.com/287
awk : https://garyj.tistory.com/19
https://intrepidgeeks.com/tutorial/awk-sed-command-set-19-for-mac

오늘 읽은 다른사람의 TIL