[TIL 3] 실용주의 프로그래머 #3. 기본 도구

오늘 TIL 3줄 요약

• 우리는 지식을 설계와 구현, 테스트, 문서로 표현한다.
• 비난 대신 문제를 해결하라.
• 그 놈의 오류 메시지 좀 읽어라

TIL (Today I Learned)

2022.03.23

오늘 읽은 범위

3.장 기본 도구 p103-p144

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

실용주의 프로그래머로서 우리의 기본 재로는 나무나 쇠가 아니라 지식이다.

• 우리가 수집하는 요구 사항은 지식이고, 우리는 그 지식을 설계와 구현, 테스트, 문서로 표현한다.
• 일반 텍스트를 사용하면 수작업으로든 프로그램으로든 동원 가능한 거의 모든 도구로 지식을 다룰 수 있게 된다.
• 일반 텍스트는 인쇄 가능한 문자로 이루어지고, 정보를 전달하기에 적합한 형식을 갖추어야 한다.
• 일반 텍스트라면 데이터 그 자체만으로 의미가 드러나는 데이터를 만들 수 있다.
• 시스템 테스트에 사용할 합성 데이터를 일반 텍스트로 표현하면 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.

=> 우리는 데이터로 말하는 개발자다. 정보를 조회하거나, 통계를 내기 위해서 데이터는 필요 불가결한 것임이 틀림없다. 비밀번호 같이 민감한 정보는 암호화해서 저장하게 되지만, 그게 아니라면 대게 쉽게 알아볼 수 있도록 DB에 저장한다. 비지니스 영역에서 데이터는 곧 돈이고 정보이자 지식이로써, 사람이 알아볼 수 있도록 표현되어야 한다. 만약 어떤 개발자가 DB에 자신만 알아볼 수 있도록 변환하여 저장(다른 사람은 이게 무슨 뜻인지 알 수 없다)한 뒤 시간이 흘러 퇴사하고, 다른 개발자가 해당 모듈을 수정해야 할 상황이 왔다고 가정해보자. 다른 개발자는 당연히 해당 데이터가 어떤 데이터인지 알 방법이 없어 아무것도 고칠 수 없는 상황에 놓이게 된다. 이런 일을 방지하기 위해서 항상 표준화된 텍스트로 지식을 저장하도록 하자!

텍스트 파일을 다루는 프로그래머에겐 명령어 셀이 작업대다.

• 셸을 프로그래밍에서 자주 수행하는 작업을 수월하게 해 주는 복잡한 매크로 명령을 만들 수도 있다.
• GUI의 장점은 여러분이 보는 것이 여러분이 얻는 것이라는 점이지만, 단점은 여러분이 보는 것이 여러분이 얻는 전부라는 것이다.
• GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.

=> MacOS로 개발하고 있지만, 셸은 여전히 낯설기만 하다. 내일부터라도 조금씩 방 구석에 박혀있는 리눅스 책을 보며 셸과 친해지도록 노력해야겠다.

어떤 것이 '유창'한 것인가?

• 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라.
• 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈등 다양한 문법 단위로 커서를 이동하라.
• 변경한 코드를 들여쓰기를 자동으로 맞춰라.
• 여러 줄의 코드를 명령 하나로 주석 처리했다가 다시 주석을 해제하라.
• 실행 취소를 여러 번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라.
• 에디터 창을 여러 구역으로 조개라. 그리고 각 구역 사이를 이동하라.
• 특정 줄 번호로 이동하라.
• 여러 줄을 선택한 후 가나다순으로 정렬하라.
• 문자열로, 또 정규 표현식으로 검색하라. 이전에 검색했던 것을 다시 검색하라.
• 선택 영역이나 패턴 검색을 이용하여 일시적으로 여러 개의 커서로 만든 다음, 동시에 여러 곳의 텍스트를 편집하라.
• 현재 프로젝트의 컴파일 오류를 표시하라.
• 현재 프로젝트의 테스트를 실행하라.
• 우리는 더 실용적인 접근 방법을 제안한다. 여러분의 삶을 편하게 해 주는 명령어를 배워라.
• 사용 중인 에디터에서 명백한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라.

=> 인텔리제이로 개발하면서 마우스를 자주 사용하면 여러모로 생산성이 떨어지는 느낌을 받았다. 그럴때마다 해당 기능의 단축키를 인터넷에서 찾아서 익혔는데, 자주 사용하지 않는 명령어는 쉽게 잊어버리고 새로운 명령어는 검색해서 찾아보는 작업이 반복되면서 그마저도 생산성이 떨어지는 느낌을 받았다. 그래서 plugin "key promoter x"을 설치하고, 단축키를 의도적으로 사용하려고 노력했다. 그 덕분인지 현재는 스크롤을 제외하곤, 거의 마우스를 사용하지 않는다. 더 좋은 기능은 없는지 찾아봐야겠다.

디버깅의 심리

• 디버깅은 많은 개발자에게 예민하고 감성적인 주제다.
• 디버깅을 풀어야 할 퍼즐로 공략하는 대신 현실 부정이나 손가락질, 어설픈 변명, 무관심으로 대하는 사람과 마주치기도 한다.
• 비난 대신 문제를 해결하라.
• 그 버그를 해결해야 하는 사람은 여러분이다.

=> 나는 처음 개발할 때, 디버깅하는 방법을 몰라서 print를 찍으며 문제점을 찾곤 했다. print찍으며 문제점을 찾는 비생산적인 행위밖에 하지 못했던 시절이라 혹시라도 내가 만든 코드에 문제가 생기면 잔뜩 예민해지고 어떻게 해결해야 할지 막막했다. 그때마다 애써 현실을 부정하고 되도않는 변명거리를 생각하기도 했다. 그 시절의 나에게 이런 말을 해주고 싶다. "이상한 소리할 시간에 어디서부터 잘못된건지 생각해봐!"

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

• 먼저 문제가 무엇인지 보자.
• 빨간색 예외 메시지가 튀어나오면 냅다 탭 키를 눌러서 코드로 직진하는 개발자가 얼마나 많은지 늘 놀라울 따름이다.
• 그놈의 오류 메시지 좀 읽어라.

=> 아.. 정말 과거의 내 이야기다. 뒤통수를 쎄게 맞은 기분이다! 과거에 나는 오류가 발생하고, 빨간 글씨가 열댓줄씩 나오면 메시지를 읽지도 않고 문제 원인을 "추측"하고 코드에 손을 갖다댔다. 이런 내 잘못된 행동으로 혼도 많이 났다. 오류 메시지는 모든 것을 설명해준다.(정말 어쩌다가 예외적인 한두개빼고..) 몇 번을 강조해도 부족하다. 오류가 발생하면 메시지를 확인하자!

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

이번 장은 현명한 개발자가 되기 위한 도구가 어떤 것이 있는지 알아보았다. 다른 개발자들이 셸을 이용해서 개발하는 모습을 보고 "나도 저렇게 하고 싶다"라는 생각도 많이 했었는데, 역시나 이 책에서도 셸은 필수라고 지칭하고 있다. 진짜 셸 잘 쓰도록 노력해야겠다. IDE를 처음 사용하면서 낯설게만 느껴졌던 과거와 제법 능숙하게 사용하게 된 현재를 비교해 보았을 때, 개발 생산성이 상당히 증가하였다고 스스로 느껴진다. 이래서 사람은 도구를 써야한다고 하나보다. 개발에 도움이 되는 다른 도구는 없는지 더 찾아봐야겠다.

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

기본 도구에 좋은 키보드 혹은 마우스도 해당이 되는 것일까? 해당 된다면 어떤 이유때문일지 궁금하다. 정말 비싼 해피해킹이라던지, 리얼포스 같은 키보드를 사용해서 개발을 한다면 더 생산성이 증가하는 것일까...?