TOC
- 참고
- Topic 17 : 셸 가지고 놀기
- Topic 18 : 파워 에디팅
- Topic 19 : 버전 관리
- Topic 20 : 디버깅
- Topic 22 : 엔지니어링 일지
- 총평
- 실천 계획
참고
본 내용은 실용주의 프로그래머 를 읽고 정리한 내용입니다. 책의 내용과 함께 개인적인 의견과 생각을 담아 작성하였습니다.
Topic 17 : 셸 가지고 놀기
언제나 일을 하는 데에 더 나은 방법이 없는지 살펴라. 사용하는 도구로 다룰 수 없는 문제를 마주쳤다는 생각이 들면, 도움이 될 만한 뭔가 다른 것이나 더 강력한 것을 찾아보아야 한다는 것을 명심하라.
GUI의 한계
모든 작업을 GUI로만 하면 여러분이 가진 환경의 능력을 전부 이용할 수 없다. 일반적인 작업을 자동화할 수 없고, 가용한 도구의 역량을 온전히 사용할 수 없다.
GUI의 장점은 WYSIWYG이지만, 단점 역시 WYSIWYG이다. 보는 것대로 얻을 수 있는 편리함은 있지만, 보는 것까지가 얻을 수 있는 전부라는 것이다. GUI 환경에서 이런 작업을 하는 도구의 사용 범위는 보통 그 도구가 사용되리라고 예상하는 작업에 한정된다.
자신만의 셸
개발자는 셸을 자신에게 맞춰야 한다. 사용하는 터미널 프로그램의 설정은 보통 다음의 내용들을 바꾼다.
- 색깔 조합 설정
- 프롬프트 설정
- 명령어 별칭 설정
- 명령어 히스토리 설정
- 명령어 자동완성 설정
도전해볼 것
- 평소 GUI에서 수동으로 하는 작업을 자동화하는 방법 찾아보기
- 새 환경으로 이동할 때 어떤 셸을 사용할 수 있는지 알아보기
- 현재 사용하는 셸의 대안은 없는지 알아보기
Topic 18 : 파워 에디팅
"도구는 손의 연장이다. 그리고 소프트웨어에서는 특히나 에디터가 그렇다."
에디터 사용에 유창해져라
유창해지는 것의 가장 큰 이점은 더는 사용법을 생각하지 않아도 된다는 것이다. 어느 정도 에디터를 써야 유창하다고 볼 수 있을까?
- 텍스트 편집 시, 문자, 단어, 줄, 문단 단위로 커서를 이용하거나 내용을 선택하라.
- 코드 편집 시, 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라.
- 변경한 코드의 들여쓰기를 자동으로 맞춰라.
- 실행 취소를 여러 번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라.
- 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.
- 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라.
- 선택 영역이나 패턴 검색을 이용하여 일시적으로 여러 개의 커서를 만든 다음, 동시에 여러 곳의 텍스트를 편집하라.
삶을 편하게 해주는 명령어를 배워라
- 에디터를 사용하는 모습을 관찰하라.
- 무언가 같은 일을 반복하는 것을 발견할 때마다 더 나은 방법이 있는지 찾아보라.
- 유용한 기능을 새로 찾았다면 이 기능을 몸이 기억하도록 만들라. 그래야 반사적으로 사용할 수 있다.
- 유일한 방법은 '반복'이다. 새로운 초능력을 활용할 기회를 의식적으로 찾아다녀라.
도전해 볼 것
- 마우스나 트랙패드를 치워라. 1주일동안 키보드로만 에디터를 사용하라.
- 새로 배운 단축키를 메모로 남겨라. 구식이지만 종이와 연필 사용을 추천한다.
- 여러분이 하는 일을 에디터에 통합하는 방법을 찾아라.
- 여러분이 원하는 일을 하는 플러그인이나 확장 기능을 찾을 수 없다면 하나 만들어 보라.
Topic 19 : 버전 관리
"버전 관리 시스템은 일종의 거대한 '실행 취소' 키와 같다."
도전해 볼 것
- VCS를 사용하면 이전의 어떤 상태로든 롤백할 수 있다. 그런데 정말 롤백할 수 있는가? 안전하게 롤백하는 명령어를 아는가? 사고가 발생했을 때 압박감 속에서 배우려 하지 말고 지금 미리 익혀 둬라.
- 예상치 못한 일이 발생했을 때 노트북 환경을 복구하는 것에 대해 시간을 두고 고민해 보라. 무엇을 복구해야 할까? 설치한 프로그램, 시스템 설정 등 다른 것도 생각해보라.
- VCS를 활용한 새로운 방식으로 컴퓨터를 설정할 수 있는지 확인해보라.
- 프로젝트 이외의 것에도 버전 관리를 사용하라.
Topic 20 : 디버깅
"디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라."
디버깅의 심리
다른 사람의 버그를 발견한 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 쏟을 수도 있다. 하지만 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.
디버깅의 사고방식
자신의 자아를 보호하기 위해 늘 켜 놓는 많은 방어막을 꺼 버리고, 여러분을 짓누르고 있는 프로젝트의 압력을 무시해서 자신을 편안하게 만들어야 한다.
디버깅의 마음가짐
- 버그라고 생각하는 증상의 원인이 무엇일지 진심으로 생각해 보는 것이 정말 중요하다.
- "정말 그럴 리가 없는데"로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라. 그런 일은 일어날 수 있다.
- 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라. 실제 문제는 더 깊은 곳에 있거나 또 다른 여러 가지와 연관되어 있을 확률이 다분하다.
- 특정 증상만 고치려고 하지 말고, 문제의 근본 원인을 찾으려고 노력하라.
오류 메시지에 집중하라
"그놈의 오류 메시지 좀 읽어라." 오류 메시지는 프로그램이 여러분에게 말하려고 하는 것이다. 오류 메시지를 읽고 이해하라.
고무 오리
문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다. 듣는 사람은 입도 뻥긋할 필요가 없다. 코드가 무엇을 해야 하는지 차근차근 설명해 나가는 단순한 행위 그 자체로 충분할 때가 많다. 누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다.
Topic 22 : 엔지니어링 일지
"아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다" - 중국 속담 -
"여러분의 생각과 역사를 기록으로 남겨라. 무엇을 했고 무엇을 배웠는지, 떠오르는 생각을 그려본 것. 업무에 관한 것 무엇이든지"
일지를 쓰면 좋은 점
- 기억보다 더 믿을 만하다.
- 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놓을 수 있는 곳이 생긴다. 집중의 흐름을 이어나갈 수 있다.
- 누군가와 이야기를 하는 것과 비슷하다. 하던 일을 돌아보기에 알맞은 기회가 생기는 것이다.
도전해 볼 것
엔지니어링 일지를 남겨 보라. 파일이나 위키 말고 종이를 사용하라. 글씨를 쓰는 것은 키보드를 두드리는 것과는 다른 무언가 특별한 것이 있다.
총평
이번 장은 개발자로서 생산성을 높일 수 있는 여러 팁들과 조언들이 주가 되었다고 느꼈다. 그런만큼 실용적인 팁을 담은 도전 과제들이 정리가 잘 돼있었고, 진심으로 도전해보고자 하는 마음이 드는 대목도 생겼다. 마지막에 간단히 정리했다. 길면 나중에 안 읽으니까.
개별 내용 중에서는 먼저 GUI 대신 셸을 사용하라는 "Topic17 셸 가지고 놀기" 부분은 공감이 많이 됐다. 나는 git을 사용할 때 GUI를 많이 오가지 않고 터미널에서 git 명령어를 CLI로 사용하고 있다. "자신만의 셸" 파트에서 별칭(alias)을 설정하라고 했는데, 한때 git 명령어를 풀로 작성하다가 영 불편해서 alias를 설정했던 기억이 떠올랐다.
물론 모든 것을 그렇게 하지는 않는다. IDE로 사용중인 VSCode의 git 관련 기능이 훌륭하고, GUI로써 고급 기능을 많이 제공하고 있기 때문이다. 아쉽게도 CLI로 git을 다루는 내 능력은 아직 그에 미치지 못하는 것 같다. 아직은 어중간하게 사용하고 있는 것 같아서 CLI를 쓸거면 제대로 공부해서 유창하게 사용하고, 아니라면 GUI를 더 사용하는 것도 괜찮겠다고 느꼈다. GUI도 아주 훌륭한 개발 도구니까.
그리고 "Topic 18 파워 에디팅" 부분은 에디터 사용에 유창해지는 것이 중요하다는 것을 강조했다. 나는 VSCode를 사용하고 있고, 나름 단축키를 중요하게 생각하는 사람이라 초장부터 익혀서 많이 사용하고 있다. 그런데 도전 과제를 살펴보면 평소에 이것까지 shortcut으로 할 수 있나? 하는 것들(예를 들면 괄호의 반대편으로 이동하기 등)이 있어서 이번 기회에 더 많은 단축키를 사용해보고, 플러그인을 찾아보는 것도 좋을 것 같다고 생각했다.
조금 극단적이긴 하지만 마우스를 치워버리고 키보드로만 작업하라는 도전 과제도 있었다. 사실 이 글을 쓰는 중에 벌써 실천중인데 의외로 불편하지 않으면서도 이럴 땐 내가 마우스를 썼구나 하는 생각이 은연중에 들었다. 역시 의식하면 보이는구나. shortcut에 익숙해지고 생산성을 높이는 좋은 방법이라고 생각한다. 더 알아보고 정리를 해봐야겠다.
"Topic 19 버전 관리" 부분은 버전 관리 시스템을 사용하면 어떤 상태로든 롤백할 수 있다는 것을 강조했다. 나는 git을 사용하고 있고, git을 사용하면서 이런 장점을 느끼고 있다. 지금으로부터 약 2년 남짓 전, 처음으로 팀을 이뤄서 같은 소스 코드를 편집할 때 branch에 대한 이해가 너무 안 돼서 master branch에서 작업을 했던 적이 있었는데, 그때를 생각하면 지금은 branch를 오가며 작업하는 것이 너무 편해졌다. 팀에서도 git branch 전략에 대한 가이드 글을 쓰기도 했으니 격세지감이 느껴진다.
한편으로는 이제는 git과 이를 둘러싸고 있는 주변을 더 공부하고 싶다는 생각이 들었다. 예를 들면 github에서 pull request template을 우아하게 다룬다던지, git과 관련된 CI/CD라던지 말이다. 아직 갈 길이 멀다.
"Topic 20 디버깅" 부분은 오류 메시지 좀 보라는 저자의 소리침이 크게 다가왔다. 오류 메시지는 코드가 개발자에게 말하려고 하는 내용이다. 그런데 빨간 색만 보면 지레 겁먹고 "오류다!" 하고 멘붕에 빠지는 경우가 많았던 것 같다. 특히나 잘 모르는 용어나 수십 중에 달하는 자세한 오류 메시지인 경우엔 더더욱 말이다. 실제로 오류 메시지에 해결을 위한 길이 있는데 자세히 읽지 않아 인터넷을 돌고 돌았던 경험도 종종 있었다. 앞으로는 오류 메시지 잘 읽자.
마지막으로 "Topic 22 엔지니어링 일지"는 디버깅의 '고무오리' 부분과 조금 이어진다. 확실히 내가 이해가 안 돼서 누군가에게 내 구현 목적과 코드의 작성을 정리해 얘기하다보면 그러다가 정리가 되는 부분이 있기도 했다. 그래서 누군가에게 말하기 이전에 내 스스로 글로써 내 코드의 시작과 끝까지 정리해보는 것도 좋은 방법이 될 수 있겠다고 생각했다.
실천 계획
- 사용하고 있는 도구 중 더 나은 게 없는지 항상 예민하게 살펴보기
- 파워 에디팅 부분의 "에디터 사용에 유창해져라" 항목을 참고하여 shortcut 정리 및 사용해보기
- 에디터 사용시 최대한 마우스를 안 쓰고 키보드로만 작업하기
- 버전 관리 시스템을 사용해 미래의 불안정성에 대비하는 방법 정리하기
- 오류 메시지 잘 읽기
- 남에게 물어보기 전에 나한테 먼저 설명하기
- 엔지니어링 일지 작성하기
