제 3장 기본 도구

" 아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다 "

 

TIL (Today I Learn)

• Assignment 05
• 2022-03-23

---

오늘 읽은 범위

• 3장 기본 도구

---

3줄 요약

• 도구들의 사용법을 배우는 데에 시간을 투자하라. 여러분은 IDE가 갖는 한계를 넘어설 수 있어야 한다.
• 근시안의 함정에 주의하라.
• 텍스트 처리 언어를 익혀라.

---

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

Topic 16 일반 텍스트의 힘

• 일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다.
• 우리가 만드는 일반 텍스트는 사람이 이해할 수 있어야 이해할 수 있어야 한다.
• 여러분은 모든 참가자가 하나의 공통 표준을 사용해서 소통하도록 해야 한다.

Topic 17 셸 가지고 놀기

• 작업대는 목공소의 중심이 된다. 프로그래머에겐 명령어 셸이 작업대다.
• GUI의 장점은 WYSIWYG What You See Is What You Get,즉 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만,
• 단점은 WYSIAYG What You See Is All You Get, 즉 여러분이 보는 것이 여러분이 얻는 전부라는 것이다
• 셸을 여러분의 집으로 만들어라.

나만의 셸 만들기

• 색깔 조합 설정
• 프롬프트 설정
  • 간단한 것을 좋아해서 현재 디렉터리 경로를 짧게 줄인 것, 버전 관리 시스템 상태, 시간 정도만 표시하도록 설정한다.
• 별칭alias과 셸 함수
  • alias rm ='rm -iv'
• 명령어 자동 완성

Topic 18 파워 에디팅

• 에디터를 유창하게 쓸 수 있게 하라. (체화의 과정...)
  • 유창해지는 것의 가장 큰 이점은 더는 에디터 사용법을 생각하지 않아도 된다는 것이다.
• 여러분의 삶을 편하게 해 주는 명령어를 배워라.
• 사용 중인 에디터에서 명백한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라.
  • 한 걸음 더 나아가라. 사용하는 에디터의 확장 기능 언어를 파헤쳐 보라. 
  • 더 멀리까지 나아가서 온전한 확장 기능을 만들어 낼 수도 있을 것이다. 
    • 그렇다면 그 확장 기능을 공개하라. 여러분이 필요한 것은 다른 사람도 필요할 것이다. (소통!)

유창함의 기준

• 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라.
• 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법
• 단위로 커서를 이동하라.
• 변경한 코드의 들여쓰기indent를 자동으로 맞춰라.
• 여러 줄의 코드를 명령 하나로 주석 처리했다가 다시 주석을 해제하라.
• 실행 취소를 여러 번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라.
• 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.

이 과제들을 마우스나 트랙패드 없이 모두 수행할 수 있는가? (기능 자체가 안되면 에디터를 바꿔라)

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

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

Topic 20 디버깅

• 소프트웨어 결함은 요구 사항을 오해하는 것부터 코딩 오류에 이르기까지 여러 모습으로 나타난다
• 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다. 비난 대신 문제를 해결하라.
• 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라. 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본 원인을 찾으려고 노력하라.
• 빌어먹을 오류 메시지 좀 읽어라. 이 정도면 됐겠지? (ㅋㅋㅋ)
• 경계 조건 boundary condition과 실제 최종 사용자의 사용 패턴 모두를 철저히 테스트해야 한다. 그것도 체계적으로 할 필요가 있다.
• 버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다.
• 스택 프레임을 일일이 조사하는 것보다 더 빠른 방법이 있다. 바로 ‘이진 분할binary chop’을 하는 것이다.
• 문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다.
  • 만약 들어 줄 사람이 없다면 고무 오리나 곰 인형, 화분도 괜찮다.
  • 이 책의 예전 버전에는 화분(potted plant)이 아니라 대마초(pot plant)에게 이야기하라고 되어 있었는데, 오타다. 정말로. (ㅋㅋㅋㅋㅋ)
• OS나 컴파일러 혹은 외부 제품에 버그가 있을 수도 있다. 하지만 처음부터 그런 생각을 하지는 말라. 개발하고 있는 애플리케이션 코드에 버그가 존재할 가능성이 훨씬 더 크다.
• 버그를 수정하는 김에, 혹시 이것과 동일한 버그가 있을 법한 다른 코드가 있는지 살펴보자. 

 

" 어떤 버그로 놀라게 될 때
애지중지 믿고 있던 진실들을 재평가해야만 한다.
가정하지 말라. 증명하라. "

Topic 21 텍스트 처리

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

Topid 22 엔지니어링 일지

• 회의에서 메모할 때나 작업하는 내용을 써 놓을때, 디버깅하다가 변수의 값을 적어 놓을 때, 무엇을 어디 두었는지 기록을 남길 때, 엉뚱한 생각을 기록할 때, 아니면 때로는 그냥 낙서할 때 일지를 쓴다.
  • 낙서가 집중력을 높이고 인지 능력을 증진한다는 근거도 있다. 

 

• 엔지니어링 일지를 남겨 보라. 파일이나 위키말고 종이를 사용하라.
  • 글씨를 쓰는 것은 키보드를 두드리는 것과는 다른 무언가 특별한 것이 있다.

---

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

• 생각해보니 IDE 테마는 늘 깐깐히 따져보면서 하나하나 세팅해줬으면서 터미널은 그 쌔까만 화면에 대한 갬성 때문인지 너무 방치했던 것 같다.
  • 미안하다 조개야. 컬러 셋이라도 맞춰주고 자동 완성까진 세팅해보도록 해야지. 일명 보노보노 프로젝트.
  • 아 근데 노트북/컴퓨터 기기가 너무 많아서 탈이다... 환경도 제각각이라 설정 파일 복사도 어려운데 언제 다 설정하냐
• 학부 전공에 리눅스 수업 자체가 있기도 했고 프로젝트 하면서 서버 만질일이 많아 쉘에 아예 무지한 건 아니었고, 인턴 시절 2달 내내 쉘 스크립트를 짜다가 많이 늘었는데 현재 업무에도 상당히 도움 되는 편이다.
  • awk나 sed는 알았다가도 금방 까먹는다. 아직까진 업무상 plane text를 처리할 일이 많지 않아서 손이 안가는 듯.
  • 쉘도 쉘인데 개인적으로 vi를 유창하게 쓰고 싶다. 아직도 visual 모드에서 버벅거리는 나...
• 진행중인 프로젝트에선 룰 포맷 등에 대해서도 별도 디렉토리로 기재하여 git에 올리고 있다. 처음에는 굳이 이럴 필요가 있었나 싶었는데 이또한 히스토리의 일환이 되는 것 같다.
  • 물론 변경이 있을 때마다 함께 싱크해야한다. 아직까진 잘 맞추고 있는듯...
• 버그라고 하는게 그 옛날 실제 벌레였다는 것은 알고 있었는데 는 착실하게도 그걸 날개를 비롯해 통째로 업무 일지에 테이프로 붙였다는 문구에서 뻘하게 터져버렸다. 덧붙여 우리의 버그는 날아다니는 종류는 아니라고 한다. 작가가 은근 개그 욕심이 있어 좋다.
• 간혹 버그 생겼을 때 누가 개발한 로직인지부터 찾으려는 사람을 볼 때마다 한심하더라. 장난이 아니라 진심으로 건수 잡았다는 식으로 이력 뒤져보는 그 모습이란... 개발은 당시 환경과 인프라 구성에 따라서도 얼마든지 바뀔 수 있는데 그 시절엔 그게 최선이었을지도 모를 일이다. 당장 문제가 생겼다고 당시 개발자의 고충을 함부로 재단하지 말 것.
• 이진 분할을 적용하라는 문구를 처음 보고 처음엔 뭔소리지 했는데 의외로 나도 상당히 자주쓰는 접근법이었다. 다만 처음 기점을 잡을때 중구난방 이었던것 같기도 하니 이진 분할을 표준처럼 정해두는 것도 괜찮을지도.
• 트레이싱 구문도 문제 생겼을 때 많이 쓰는 방법이지. 역시 개발자들 고충은 전세계가 비슷하구만... 신입 분들이랑 일 할 때 이상하다고 뭐 가져오면 "구문별로 print 찍어보세요" 라는 가이드를 꽤 많이 했었다.
• 설명할 줄 알아야 이해를 한 것이고, 이해를 했다면 문제점이 자연스레 보이는 게 맞다.그러니 인형이라도 앉혀두고 설명하다보면 문제점이 보일 수 있다고 하는 거겠지. 신박하다고 생각한다. 그치만 고무 오리라니...
• 디버깅 할 일이 많다보니 이번 장에서 공감하고 웃픈 이야기들이 꽤 있었다. 문제 생기면 서버 문젠가? 싶기도 하고 트러블 슈팅 잘 안될 때 배포 미루고 싶을 때가 한두번이 아니지 ^^
• 작가가 나랑 취향이 좀 비슷한 것 같아 소름이다. 나도 마크다운이나 위키를 쓰는 선호하는 편이긴 하지만 그날그날 일정은 캘린더가 아닌 일반 다이어리를 쓰고, 아키텍처링 고민할 때 그림을 끄적이거나 생각 흐름 정리할 땐 이면지를 활용한다. 별거 아닌 내용이 흑연으로 표기되어 바로 버리는 경우도 많긴 한데 그 손 맛이 좋아서 계속 하는 편이다. 작가양반 뭘 좀 아는구만

 

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

• 이번 장은 공감의 장이었다. 끄덕끄덕.