실용주의 프로그래머 #03. 기본 도구
TL;DR
- 늘 하는 반복적인 일을 자동화할 방법을 찾아보자.
- 디버깅을 시작하기에 앞서, 당황하지 말라. 그리고 그놈의 오류 메시지 좀 읽자
- 아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다. 일지를 쓰자
🗓️ TIL (Today I Learned)
2022.03.22
🔖 오늘 읽은 범위
3장. 기본 도구
🌟 책에서 기억하고 싶은 내용을 써보세요.
Topic16 일반 텍스트의 힘
[일반 텍스트란?]
- 우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 한다. (p.106)
- 사람이 읽을 수 있는 것과 사람이 이해할 수 있는 것에는 차이가 있다. (p.108)
🛠️ Tip 25 지식을 일반 텍스트로 저장하라.
[일반 텍스트가 널리 쓰이는 이유 (장점)]
- 지원 중단에 대한 보험 : 데이터가 남아 있는 한 그걸 사용할 기회가 찾아오기 마련이기에 그 자체만으로 의미가 드러나는 데이터는 다른 어떤 형태의 데이터보다, 심지어 그 데이터를 생성한 애플리케이션보다 더 오래 살아남을 것이다. (p.107)
- 기존 도구의 활용 : 컴퓨터 세계의 거의 모든 도구는 일반 텍스트를 다룰 수 있다. (p.108)
- 더 쉬운 테스트 : 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.
Topic17 셸 가지고 놀기
GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다. (p.111)
🛠️ Tip 26 명령어 셸의 힘을 사용하라.
[자신만의 셸]
변경할만한 터미널 설정
- 색깔 조합 설정
- 프롬프트 설정
- 별칭과 셸 함수
- 명령어 자동 완성
[도전해 볼 것]
- 평소 GUI에서 수동으로 하는 작업이 있는가? 이걸 자동화할 수 있겠는가?
- 여러분의 셸로 처리할 수 없는 문제를 만난다면 다른 셸은 좀 더 잘 처리할 수 있는지 알아보라.
Topic18 파워 에디팅
🛠️ Tip 27 에디터를 유창하게 쓸 수 있게 하라.
- 에디터에 유창해지는 것이 중요한 이유?!
- 시간을 절약
더는 에디터 사용법을 생각하지 않아도 된다는 것이다.- 모든 동작을 일일이 생각하면서 운전하는 초보 운전자와 의식하지 않고 차를 모는 경험 많은 운전자는 완전히 다르다. (p.115)
[어떤 것이 ‘유창’한 것인가?]
- 유창함의 기준! (다음의 과제들을 마우스나 트랙패드 없이 수행할 수 있는가)
- 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라.
- 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라.
- 변경한 코드의 들여쓰기(indent)를 자동으로 맞춰라.
- 여러 줄의 코드를 명령 하나로 주석 처리 했다가 다시 주석을 해제하라.
- 실행 취소를 여려 번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라.
- 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.
- 특정 줄 번호로 이동하라.
- 여러 줄을 선택 후 가나다순으로 정렬하라.
- 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라.
- 선택 영역이나 패턴 검색을 이용하여 일시적으로 여러 개의 커서를 만든 다음, 동시에 여러 곳의 텍스트를 편집하라.
- 현재 프로젝트의 컴파일 오류를 표시하라.
- 현재 프로젝트의 테스트를 실행하라.
[유창해지기]
- 무언가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라 .’분명 더 나은 방법이 있을 텐데.’ 그리고 더 나은 방법이 있는지 찾아보라.(p.116)
[에디터 성장시키기] **
- 여러분이 늘 하는 반복적인 일을 자동화할 방법을 연구해보라. (p.117)
야심찬 도전 과제!! 원하는 플러그인이나 확장 기능이 없다면 만들어라! (p.118)
Topic19 버전 관리
🛠️ Tip 28 언제나 버전 관리 시스템을 사용하라.
- 언제나, 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 ‘버리기로 한’ 프로토타입일지라도, 심지어 여러분이 작업하는 것이 소스 코드가 아닐지라도,
모든 것을 버전 관리 아래에 둬라.
[브랜치 사용하기]
- 브랜치의 장점 1. 브랜치들끼리 서로 방해하지 않는다. (p.122)
- 브랜치의 장점 2. 브랜치가 팀의 프로젝틀 업무 흐름에서 핵심이 되는 경우가 많다.
[도전해 볼 것]
- 안전하게 롤백하는 명령어를 아는가? 사고가 발생했을 때 압박감 속에서 배우려 하지 말로 지금 미리 익혀 둬라. (p.124)
- 프로젝트 이외의 것에도 버전 관리를 사용하라.
Topic20 디버깅
[디버깅의 심리]
- 디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
- 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다. (p.126)
🛠️ Tip 29 비난 대신 문제를 해결하라.
[디버깅 사고방식]
- 디버깅을 시작하기에 앞서 올바른 마음가짐이 중요하다. (p.127)
- 자신의 자아를 보호하기 위해 늘 켜 놓는 많은 방어막을 꺼 버리고,
- 여러분을 짓누르고 있는 프로젝트의 압력을 무시해서 자신을 편안하게 만들어야 한다.
- 무엇보다도 다음 디버깅 제 1 법칙을 기억하라.
- 한발짝 뒤로 물러나서 여러분이 버그라고 생각하는 증상의 원인이 무엇일지 진짜로 생각해 보는 것이 정말 중요하다.
- 디버깅할 때 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라. (중략) 겉으로 드러난 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라. (p.128)
[실마리 찾기]
- 작업 중인 코드가 컴파일 경고 없이 깨끗하게 빌드되는지 확인하라.
- 어떤 문제건 해결을 하려면 관련 자료를 모두 모아야 한다.
- 버그 보고는 오도되기 쉽다. 우연한 사건을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다. (p.128)
- 처음에 받은 자료 이상을 얻기 위해서 버그를 보고한 사용자를 인터뷰할 필요도 있다.
- 경계 조건과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다. (p.129)
[디버깅 전략] - 프로그램은 어떻게 생각하는가
버그 재현하기
- 버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다. (p.129)
🛠️ Tip 31 코드를 고치기 전 실패하는 테스트부터.
[미지의 세계에 온 프로그래머]
🛠️ Tip 32 그놈의 damn 오류 메시지 좀 읽어라.
이상한 결과
- 무엇보다 먼저 디버거에 잘못된 값이 나타나는지부터 확인하라.
- 옆에 종이와 펜을 가져다 두고 메로를 하면 도움이 될 때가 많다. (p.131)
흔한 버그 시나리오 → 이진 분할을 활용하라
- 입력값에 따라 바뀜
- 릴리스 사이에서 발생한 문제
로깅과 트레이싱
- 디버거는 일반적으로 프로그램의 현재 상태에 주목한다.
- 로그 파일을 텍스트 처리 도구와 셸 명령어로 처리하면 문제를 일으키는 부분을 쉽게 찾아낼 수 있다.
고무오리
- 문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다.
- 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다. → 문제에 대한 새로운 통찰! (p.134)
소거법
- OS나 컴파일러 혹은 외부 제품에 버그가 있을 수도 있다. 하지만 처음부터 그런 생각을 하지는 말라.
- 개발하고 있는 애플리케이션 코드에 버그가 존재할 가능성이 훨씬 더 크다. (p.135)
-
(예시) select에 관한 문서를 읽을 수밖에 없게 되자 그는 원인을 발견해 냈고, 몇 분 만에 문제를 해결했다.
- 업그레이드를 고려할 때는 일정을 면밀히 살펴라.
놀라운 구석
- 어떤 버그로 놀라게 될 때, 애지중지 믿고 있던 진실들을 재평가해야만 한다. (p.136)
- 예상치 못한 ‘놀라운’ 실패를 대면했을 때 자신이 세운 가정이 적어도 하나는 잘못되었다는 것을 받아들여야 한다.
-
버그와 관련된 코드가 제대로 작동한다는 걸 ‘안다’고 해서 대충 얼버무리고 지나치지 말라. 그것을 증명하라. 이 맥락 안에서, 이 데이터로, 이 경계 조건하에서 증명하라.
- 놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서 왜 이 문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다. 버그를 미리 잡을 수 있도록 단뒤 테스트나 다른 테스트를 수정할 필요가 있는지 고민해 보라. (p.137)
- 버그를 수정하는 김에, 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자.
- 어떤 일이 일어났든지 간에 똑같은 일이 다시 발생하면 그 사실을 알 수 있도록 하라.
- 버그를 고치는 데 시간이 오래 걸린다면 왜 그런지 자문하라. **
- 더 나은 테스트 훅을 만들거나
- 로그 파일 분석기를 작성
- 마지막으로, 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체팀과 함께 토론하라.
Topic21 텍스트 처리
- 텍스트 처리 언어
- 유닉스, 맥 → 셸 + awk나 sed와 같은 도구 결합
- 좀 더 체계적인 도구 : 파이썬, 루비
- 유틸리티를 만들거나, 아이디어를 더 빠르게 프로토타입해 볼 수도 있다. (p.139)
🛠️ Tip 35 텍스트 처기 언어를 익혀라.
- 모든 것을 일반 텍스트로 저장하고, 텍스트 처리 언어로 이를 처리한다면 엄청나게 많은 이점을 누릴 수 있을 것이다. (p.141)
Topic22 엔지니어링 일지
아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다 (p.105)
- 데이브가 만난 기계 엔지니어들의 엔지니어링 일지
- 무엇을 했고 무엇을 배웠는지, 떠오르는 생각, 방금 읽은 계기판의 눈금 등 → 기본적으로 업무에 관한 건 무엇이든지! (p.142)
- 일지
- 회의에서의 메모
- 작업하는 내용
- 디버깅하다가 변수 값 기록
- 무엇을 어디 두었는지 기록남길 때
- 엉뚱한 생각을 기록할 때
- 낙서
- 일지의
장점세 가지- 기억보다 더 믿을 만하다.
- 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다. → 현재에 집중
- 하던 일을 돌아보기에 알맞은 기회가 생기는 것이다.
일단 한 달만 써 보고 어떤 이득을 얻었는지 살펴보라.
💭 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 이번 챕터에서는 특히 관심이 집중되는 토픽들이 몇몇 있었다.
셸,파워 에디팅,디버깅, 그리고엔지니어링 일지이다. 안그래도 늘 생각하고 도전하고 싶은 주제들이었는데 마침 책도 읽었겠다 싶어 처음으로 쉘을 만들어보았다. 개발 서버 반영을 자동화하는 쉘을 만들었는데 오늘 날짜로 백업 폴더를 만들때 같은 날 두 번 이상 배포하는 경우를 고려하지 못해서 그때마다 폴더 명을 바꿔주어야 하는 점을 제외하면 시간도 엄청나게 단축되고 직접 치지 않으니 실수할 확률도 줄어들어 너무 좋았다. 역시 도전하면 두려움을 이긴 만큼의 보상이 따르는 듯?! 히히.. 내일은 위의 부분만 더 수정해봐야겠다. - 기존에 계속 이클립스를 쓰다가 이번에 새로운 프로젝트를 들어가면서 인텔리제이로 툴을 바꾸게 되었다. 그러다보니 단축키도, 위치도, 모든게 달라져서 너무 너무 어색하고 자꾸만 익숙했던 이클립스로 돌아가고 싶기도 했다. 하지만 책에서 파워 에디팅 부분을 보며 인텔리제이의 필수 단축키, 그 중에서도 디버깅 단축키를 정리해서 포스트잇에 써 놓고 모니터 가장 잘 보이는 곳에 붙여놓고 수시로 보고 있으니 생각보다 금방 적응이 되는 것도 싶다. :) 아직 능숙하진 않지만 좀 적응이 되면 유창함의 기준을 보면서 얼마나 쓸 수 있는지 체크해봐야겠다.
- vim 뿐 아니라 브라우저에서도 vimium을 쓰고 있다. 웹 브라우저에서도 vim같은 단축키로 마우스 없이 자유롭게 쓸 수 있는 크롬 확장툴인데 이게 아주 손목 건강에 큰 도움이 되었다. 너무너무 좋음
- 업무 일지는 개발자로 일을 시작한 이래로 거의 쭉 써온것 같다. 기본적으로는 노션에 데이터베이스를 만들고 매일 작성했는데 사실 회의할때나 평소 생각하면서 끄적일때는 아이패드만한 것이 없어서 양쪽으로 데이터가 분산되는 느낌이 있었다. 이게 지금 고민하는 것 중 하나이다. 어디 한 곳으로 모으고 싶은데.. 쓰기 편한 아이패드로 갈 것인가, 검색하고 모아놓기 좋은 노션으로 갈 것인가… 아직도 못 정했다ㅠㅠ
🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
-
awk와 sed :
-
트레이싱
댓글남기기