[실용주의 프로그래머]를 읽고 #8. 3장. 기본 도구. Topic 16 ~22

실용주의 프로그래머라는 책을 읽으며, 삼색볼펜 독서법을 적용. 줄 친 내용에 대한 단상을 정리합니다.
삼색볼펜 스터디란? 책에서 중요하다고 생각되는 문장을 빨강 > 파랑 > 검정 순으로 줄을 치며 공부하는 방식.
🔴 가장 중요한 문장
🔵 그래도 꽤 중요한 문장
⚫ 그럭저럭 내 마음에 와닿은 문장
🤔 짧은 생각 (단상은 단상일뿐!!)
볼드체 중요한 문장은 아니지만 단락 구분 표시

---

3장. 기본 도구
🤔 기본 도구가 무슨 말인고 하니, 소프트웨어 개발자가 사용하는 모든 툴을 통칭한다. IDE가 될 수도 있고, VIM이 될 수도 있고, 스크립트 언어가 될 수도 있고.

 

🔴 아무리 흐린 먹물일지라도 가장 훌륭한 기억력보다 낫다는 중국 속담이 있다.
🤔 기본 도구라기 보단, 기본 습관에 해당하는 말이겠지만, 임팩트 있는 속담이기하다. 자신의 기억력을 절대 확신하지 말자..!!

Topic 16. 일반 텍스트의 힘
🔵 일반 텍스트라면 데이터 그 자체만으로 의미가 드러나는 데이터를 만들 수 있다. 즉, 데이터가 데이터를 만드는 애플리케이션에 독립적인 것이다.
🤔 무슨 말이냐 하면,  일반 텍스트로 만들어진 데이터는 그 누구라도 이해할 수 있고, 그 어떤 보조 툴에서도 활용할 수 있다. 특별한 요구사항이 없는 이상, 굳이 일반 텍스트를 해시처리한다거나 특별한 네이밍 룰로 알아보기 힘들게 만들 필요가 있는지 생각해봐야 한다.

Topic 17. 셸 가지고 놀기
🔴 명령어 셸의 힘을 사용하라.
🤔 뜨끔한 부분. 셸을 잘 사용하지 않고 GUI에 기대니문제가 있다. 어떤 개발자는 마우스를 일절 안쓰고 키보드로만 개발한다고 한다. VIM 모드로 개발하는 사람도 있다. 그런데 난 여전히... 허허 많이 찔리는 대목이다.

🔵 별칭과 셸 함수. 만날 사용하는 명령어에 간단한 별칭을 만들어서 작업을 단순화하라.
🤔 이건 꿀 팁인듯. 모두가 사용하는 공용서버에 이런 별칭을 해두면 지탄받을 일이지만, 나만 사용하는 로컬 개발환경에서는 이정도 별칭은 설정해두고 편하게 쓰는게 좋을 듯 싶다.

Topic 18. 파워 에디팅
🔵 무언가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라. ‘분명 더 나은 방법이 있을 텐데.’ 
🤔 에디터 = IDE로 이해했다. 참고로 난 인텔리제이를 사용한다. 인텔리제이를 업데이트 할 때마다 새로운 기능도 무궁무진하고, 심지어 편리한 플러그인도 엄청 많다. 그런데 내가 막상 쓰는건 딱히 없다…기껏해봤자 테마를 바꾸거나 정도…간간히 신기한 플러그인을 추천받아 사용하긴 하지만 이걸 100% 쓰는거 같진 않다. 이런것도 공부를 좀 해야지..

Topic 19. 버전 관리
⚫ 또 다른 장점은 다소 놀라울 수도 있을 텐데, 브랜치가 팀의 프로젝트 업무 흐름에서 핵심이 되는 경우가 많다는 것이다.
⚫ 그리고 바로 이 부분이 좀 혼란스러워지는 부분이기도 하다. 버전 관리에서 브랜치와 테스트 구조는 공통점이 있다. “나한테는 이게 괜찮았어”
🤔 보충 설명이 많지 않은 단락이라 무슨 말인지 이해가 잘 안가지만, 자의적으로 해석해보자. 개발 브랜치를 어떻게 운용할 것인가는 은근 몇가지 선택지가 없을 것 처럼보이지만, 의외로 각자가 생각하는 개발 프로세스가 다를 때가 있다. Develop 브랜치에는 feature 브랜치를 머지하고, 테스트 브랜치는 어떻게 관리하는지, 운영 브랜치는 어떤지 등 브랜치 전략에 따라서 개발 문화와 프로세스가 좌우될 수도 있다. 맞다 틀리다는 없어서, 이런 대목이 나온거같긴 하다.

 

Topic 20. 디버깅
디버깅의 심리
🔵 디버깅은 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.
🤔 버그는 마치 감기처럼 언제든지 발생할 수 있는 것인데, 이걸 문제 풀이로 받아들이기 위해선 팀 문화가 상당히 중요하다. 버그 하나 생겼다고 개발자 쥐 잡듯이 비난하지 않고, 같이 문제를 해결하고 너그럽게 이해해주는 문화가 전제되어야 문제 풀이처럼 여길 수 있다. 그게 아니라면 당연히 변명부터 시작할 수 밖에…
이 대목에서 살짝 찔렸던 건, 크리티컬 하지 않은 버그라고 해서 ‘무관심’으로 대응하고 있지 않았나 라는 부분...

 

⚫ 버그가 여러분의 잘못인지 다른 사람의 잘못인지는 중요치 않다. 어쨌거나 그 버그를 해결해야 하는 사람은 여러분이다.
🤔 본인이 실수로 만든 버그던지, 우연히 발견한 버그던지, 책임감을 가지고 적극적으로 해결하자는 의미.

디버깅 사고방식
🔴 당황하지 말라
🤔 이게 쉬운가!! 크리티컬한 영향이 있는 버그가 발생하면, 식은땀이 나고 손발이 차가워지기 마련이다…이 기분은 정말 느껴본 사람만 안다..

 

🔵 디버깅할 때 근시안의 함정에 주의하라. 표면에 보이는 증상만 고치려는 욕구를 이겨 내라.
🤔 욕구는 보통 이겨내기가 힘들다…가능한 빨리 문제를 해결하려고 하다보니, 눈 앞에 문제만 해결하자! 라는 생각으로 가득하니까..으 생각만 해도 긴장이 빡 든다.

미지의 세계에 온 프로그래머
🔴 그놈의 오류 메시지 좀 읽어라.
🤔 당연한 거 아닌가 싶긴 하지만, 도저히 용납할 수 없는 버그를 맞닥뜨렸을 땐 에러메시지를 미처 보지도 않는 것 같다. 이게 왜 발생하지?? 내가 아니라 이 시스템이 이상하다!! 발생할 수 없는 오류인데! 라는 강한 확신 때문이랄까

고무오리
🔵 문제의 원인을 찾는 매우 단순하지만 꽤 유용한 기법으로 그냥 누군가에게 문제를 설명하는 방법이 있다.
🤔 머언 옛날 영화인 ‘캐스트 어웨이’에 ‘윌슨’이라는 무언의 동반자가 나온다. 고무오리도 역할이 비슷하다. 그게 사람이던, 반려견이건, 진짜 인형이건 상관없이 문제 상황을 말로 풀어내기만 해도 원인을 파악하는데 큰 도움이 된다. 심지어 말하던 와중에 해결책이 생각나기도 한다. 제대로 공부하려면 누굴 가르쳐보라는 말도 있지 않은가? 그런 의미에서 진짜 오리 인형이라도 사야하나…

놀라운 구석
⚫ 놀라운 버그를 마주쳤을 때, 단순히 그걸 고치는 것을 넘어서 왜 이 문제가 더 일찍 발견되지 않았을까 생각해 봐야 한다. 버그를 미리 잡을 수 있도록 단위 테스트나 다른 테스트를 수정할 필요가 있는지 고민해 보라.
🤔 코드 커버리지가 100%가 된다 한들, 그 치밀한 테스트코드를 피해가는 예상치 못한 버그들은 발생하기 마련이다. 그래서 코드 커버리지만 맹신하지 말고, 버그가 생길 때마다 테스트 코드를 보충하는게 좋겠다. 물론 내가 이걸 다 실천하고 있다는건 아니다..

🔵 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체 팀과 함께 토론하라.
🤔 혼자서 비밀을 간직하면, 아무도 모르겠지만, 놀랍게도 혼자 간직한 잘못된 가정은 널리 퍼진다. 그 잘못된 가정이 코드에 반영되어 있고, 동료는 나를 신뢰하기 때문에 그 코드를 무비판적으로 받아들일 경우가 있다. 심지어 그게 단순한 코드 오류가 아니라 비즈니스적인 오해에서 비롯하면 더욱 그렇다. 그렇기 때문에 잘못된 가정이 발생하면 즉각 고치고, 주석으로 남기던 팀에 공유를 하던 해야한다.

Topic 21. 텍스트 처리
⚫ 좀 더 체계적인 도구를 선호하는 사람들은 파이썬이나 루비 같은 프로그래밍 언어를 더 좋아한다.
⚫ 텍스트 처리 언어를 익혀라
🤔 텍스트 처리 언어가 뭔가 했는데, 일종의 스크립트 언어를 말하는게 아닌가 싶다. 작정하고 사용하던 언어로 코드를 작성하기엔 짜치는 경우가 있다. 뭐, 일반 텍스트를 단순 매핑하는 코드라던지 그런 것들…그런건 그냥 스크립트 언어로 간단하게 돌릴 줄 알면 삶의 질, 아니 업무의 질이 높아질 듯.

Topic 22. 엔지니어링 일지
⚫ 일지를 쓰면 좋은 점이 크게 세 가지 있다.
- ⚫ 기억보다 더 믿을 만하다.
- ⚫ 진행 중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아 놀을 수 있는 곳이 생기다.
- ⚫ 고무 오리와 같은 역할을 할 수 있다.
🤔 나도 이 책을 읽기 시작하면서, 회사에서 엔지니어링 일지를 쓰고 있다. 엔지니어링 일지라기 보단 업무노트 같은 건데, 아래 내용을 적어서 관리한다
- 오늘 업무 목표. TO DO와는 다르다. 오늘 내가 해낼 분량을 목표로 잡는 것.
- 오늘 실제로 수행한 내용. 업무 목표에 있는 내용을 처리할 때마다 여기에 갱신한다.
- 오늘 부족했던점. 수행한 내용과 업무 목표간의 괴리가 있을때 그 이유를 찾아 적는다.
‘오늘 업무 목표’는 매일 퇴근 하기 바로 직전에, 내일 분량을 적는다. 그리고 당일에 처리해야하는 목표가 생길 경우 유연하게 추가한다. 이러면 내가 어떤 업무를 잘 진행하고 있는지 파악할 수 있어서 좋다.

이 일지에 매일 겪었던 엔지니어링 이슈를 추가해두는 것도 좋긴 할텐데, 자세하게 적기는 시간이 너무 많이 소요될 거 같긴하다. 흠… 그래도 기억해야할 이슈가 생기면 추가해봐야겠다.

 

실용주의 프로그래머(20주년 기념판)

《실용주의 프로그래머》는 당신이 읽고, 또 읽고, 수년간 또다시 읽게 될 몇 안 되는 기술 서적이다. 당신이 이 분야에 처음 발을 디딘 사람이건, 경험 많은 전문가이건 매번 새로운 통찰을 얻게 될 것이다. 데이비드 토머스와 앤드류 헌트는 소프트웨어 산업에 큰 영향을 미친 이 책의 1판을 1999년에 썼다. 고객들이 더 나은 소프트웨어를 만들고 코딩의 기쁨을 재발견하도록 돕기 위해서였다. 이 책의 가르침 덕분에 한 세대에 걸친 프로그래머들이 어떤 언어

저자

데이비드 토머스, 앤드류 헌트

출판

인사이트

출판일

2022.02.24