[3주 완독 Daily 서평] 실용주의 프로그래머 - 4

범위 : [3장 기본도구]

태그 - TIL, nomadcoder, 개발자북클럽, 노개북, 서평, 책

3장 기본도구

도구는 (목수의) 손의 연장이 된 것이다..

목수는 분명 처음부터 늘 함께했던 도구를 사용할 때 가장 행복할것이다. 대패가 나무위를 노래하듯이 미끄러져 나가는 걸 느끼면서..

새로운 산물의 도구보다 기존에 쓰던 도구를 편하게 느껴 기존 도구만 고집할수도 있다. 하지만 언제나 일을 하는데에 더 나은 방법이 없는지를 살펴봐야한다. 사용하는 도구로 다룰수없는 문제를 마주쳤단 생각이 든다면 도움이 될만한 다른 무언가를 찾아봐야 한다는 것을 명심해야한다.

이런 도구들의 사용법을 배우는 데에 시간을 투자해야한다. 언젠가 별 어려움없이 키보드위를 움직이며 텍스트를 조작하고 있을 나 자신을 발견하게 될것이다. 도구가 '손의 연장'이 된것이다.

Topic 16 일반텍스트의 힘

실용주의 프로그래머로서 기본재료는 지식이다. 우리는 그 지식을 설계와 구현 테스트, 문서로 표현한다. 지식을 저장하는 최고의 포맷이 바로 '일반 텍스트'이다.

정보를 전달하는 부분이 중요하며 일반텍스트는 '사람이 이해할수 있어야 한다.'

''사람이 읽을수 있는것''과 ''사람이 이해할수있는것''은 차이가 있다.

텍스트는 컴퓨터세계의 거의 모든 도구를 다룰수 있다. (읽어보기, 유닉스의 철학 쉬운테스트 - 책 134 page)

다양한 시스템이 섞인 환경에서는 일반 텍스트의 장점이 다른 모든 단점을 덮고도 남는다. 우리는 하나의 공통 표준을 사용해서 소통하도록 해야한다. '텍스트'가 바로 그것이다.

Topic 17 셀가지고 놀기

텍스트 파일을 다루는 프로그래머에겐 명령어 셀이 '작업대'다. 셀프롬프트에서 모든 종류의 도구를 불러다 쓸 수 있다. 파이프를 이용해 원 개발자가 꿈도 꾸지못했을 방식으로 도구를 결합할 수도 있다.

실용주의 프로그래머는오직 코드만 쏟아내거나, 객체 모델만 개발하거나, 문서만 작성하거나, 빌드과정 자동화만 하지않는다. 이 모든 일을 다한다. 하지만 GUI 환경에선 설계자가 의도한 범위를 넘어설 수는 없다. 우리는 자주 그 모델 이상이 필요하다.

자신만의 작업공간 셀이 필요하다.! 개발자도 셀을 자신에게 맞춰야한다.

소라개처럼 조개껍데기(Shell) 을 자기의 집으로 만들어야 한다

Topic 18 파워에디팅

텍스트는 프로그래밍의 기본 원재료이며 텍스트를 최대한 손쉽게 조작할수 있어야한다. 에디터를 유창하게 쓸 수 있어야한다.에디팅을 잘 사용할줄 안다면 시간 절약 뿐만아니라 생각을 자유롭게 할 수 있다는 것이다. 이는 프로그래밍에 큰 도움이 될것이다. 모든 동작을 일일이 생각하며 운전하는 초보운전자와 의식하지않고 차를 모는 베테랑 운전자와는 완전히 다르다.

(어떤것이 유창한가, 책 뷰어기준 140 page)

Topic 19 버전관리

버전관리 시스템은 일종의 거대한 '실행취소' 키와 같다.

버전관리 시스템은 실수를 되돌리는 것 외에도 아주 많은 일을 한다. 변경사항을 추적할 수도있고 소프트웨어의 특정릴리스를 찾을수도있다. 또 둘 이상의 사용자가 동일한 파일을 동시에 작업할 수있다.

언제나 혼자서 한주짜리 프로젝트를 하는 경우에도 '버리기로 한' 프로토타입이어도, 작업하고있는 소스코드가 아닐지라도 모든것을 버전관리 아래로 둬야한다.

진보라는 것은 변화와 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다. - 조지 산티야나

Topic 20 디버깅

안타깝지만 지금도 컴퓨터 시스템은 여전히 여러분이 '명령하는 것'을 할 뿐, 여러분이 '원하는 것'을 알아서 하지 않는다.

하루 대부분을 디버깅으로 보낼것 이라는 건 기정 사실이다.

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

기술의 전당에서는 남을 비난하기보다 '문제'를 고치는데 집중해야한다. 자신의 자아를 보호하기위한 방어막을 꺼버리고, 우리를 짓누르고 있는 프로젝트의 압력을 무시해서 자신을 편안하게 만들어야 한다.

가장 속이기 쉬운사람은 자기 자신이다

• 에드워드 볼워-리턴

디버깅의 제 1법칙

• 당황하지 말라.

  특정 증상만 고치려 하지말고, 문제의 근본원인을 찾으려 노력해야한다.

• 실마리찾기

  버그는 정밀과학도 아니고 우연에 의해 오도되기 싶다. 우연한 사건을 디버깅하느라 시간을 낭비할 여유가 없다.

  1. 버그를 보고한 사용자를 인터뷰할 필요가있다.
  2. 인공적인 테스트는 어플리케이션을 충분히 테스트 하지 못한다. 실제 최종사용자의 사용 패턴 모두를 철저히 테스트해야한다. 그것도 체계적으로.

• 버그 재현하기

  버그는 번식해서 수가 늘지않는다. 영어로는 같은 단어지만 우리가 해야하는 일은 버그를 재현해야하는 일이다. "코드를 고치기전 실패하는 테스트부터"

• 오류메세지를 읽을것

• 고무오리

  누군가에게 문제를 설명하게 되면 혼자 코드를 살펴볼떄는 당연히 여기고 지나갈 것을 명시적으로 이야기해야한다. 이런 가정 몇가지를 입밖에내면 문제에 대한 새로운 통찰을 불현듯 얻을 수 있다. 만약 들어줄 사람이 없다면 고무오리나 곰인형, 화분도 괜찮다.

• 변경한 단 하나에 책임이 있다.

  잘 작동되다가 , 시스템이 작동을 멈춘다면 아무 관련없어보여도 직간접적으로 변경한 그 하나에 책임이 있다.

• 코드를 제대로 작동하는걸 '안다'라고 해서 대충 얼버무리고 지나치지말아라. "가정하지 말라. 증명하라"

• 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체팀과 함께 토론해라. 한사람이 오해했다면 다른사람도 충분히 그럴수 있다.

(디버깅 체크리스트, 뷰어기준 162page, 책 137page)

Topic 21 텍스트 처리

실용주의 프로그래머는 목수가 나무를 다루는것과 똑같은 방식으로 텍스트를 다룬다.

프로젝트의 중요한 컴포넌트를 자동화 하느라 하루를 보내는것은 괜찮지만 일주일을 보내는 것은 문제가 될것이다. 텍스트 처리 언어는 '기반기술' 이다.

(텍스트 처리 , 뷰어기준 163 ~167 page, 138/142page)

Topic 22 엔지니어링 일지

무엇을 했고 무엇을 배웠는지 떠오른 생각을 그려본것, 계기판의 눈금 등 기본적으로 업무에 관한 건 무엇이든지 적는다. 일지를 쓰면 좋은점이 크게 3가지가 있다.

1. 기억보다 더 믿을만하다
2. 진행중인 작업과 직접적인 관계가 없는 발상을 일단 쌓아놓을수 있는 곳이 생긴다
3. 앞서 설명한 고무오리같은 역할을 할 수 있다.
4. 내가 무엇을 했는지 돌아볼 수 있다.

총 평

저번에는 '실용주의 프로그래머' 로서의 마음가짐과 애플리케이션의 설계방법이었다면, 오늘은 애플리케이션을 개발하는 와중의 연장사용방법을 배운것 같다.

먼저 ,

첫 토픽,

에선 '텍스트'의 이야기를 다뤘는데 컴퓨터가 읽는것이 아닌 '사람'이 읽고 이해할수 있는 그런 텍스트였다. 결국 모든 텍스트는 사람이 읽고 이해할수 있어야 하는것이다. 이를 바탕으로 유지보수와 수정을 쉽게 할 수 있는것 같았다.

두번째 토픽,

어떤 작업대에서 일할것이냐? 라는 느낌의 주제 같았다. GUI는 눈으로 보이기 때문에 작업하기 쉽다는 생각이 들법하지만 결코 그 한계를 벗어날 순없다. 우리는 개발자다. 우리는 설계자가 최초 의도한 범위를 넘어 그것 이상이 필요하다. 또 목수는 자기 공구가 손에 익듯 우리도 공구에 우리만의 색깔을 입혀야한다. (손에 익히게끔)

세번째 토픽,

파워에디팅. 우리는 텍스트를 최대한 손쉽게 조작해야하고 그러기위해선 에디터 사용에 능숙해져야한다. 한다는것을 알게되었다.

네번째 토픽,

버전관리. 사실 이부분은 아직 어렵게 느껴진다. 일종의 거대한 '실행취소' 버튼느낌인데, 왜 모든 프로토타입과 그것이 아닐지라도 버전관리를 해야하는지 아직 잘 모르겠다.

브랜치에 관해 언급하기도 했다.

다섯번째 토픽,

디버깅의 기법에대해 배워왔다. 문득 프로젝트를 수행했을떄의 내 모습이 떠올랐다. 내가 사실 실수해서 저질렀던 오류였는데 변명은 하진않았지만 팀원들에게 많이 미안했다. 문득 어느정도는 뻔뻔해져야(?)할 필요가 있다.

여섯번째 토픽,

텍스트 처리. 이부분은 다시 이해하기위해 총평을 쓰는와중 빠르게 읽어보았다. '중요기반기술' 언어가 중요하다는점, 빠르게 프로토타입을 만들수있고 필요한 유틸리티를 금방 만들어 낼 수있기 때문이라한다.

마지막 토픽,

엔지니어링 일지로 , 개발자에게 우리가 무엇을 배웠고 무엇을 했는를 타임라인으로 제시한다.