[Book] 실용주의 프로그래머 정리 - 03

실용주의 프로그래머 - 교보문고

3장 기본적인 도구

14. 일반 텍스트의 힘

  일반 텍스트는 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자로 이루어진 텍스트를 말합니다. 예를 들면 'Field19=773h26saa' 에서 733h26saa를 보고 무슨 의미인지 떠올릴 수 있는 사람은 없을 것 입니다. 그렇기 때문에 'UserId=haha123' 과 같이 인간이 이해할 수 있는 텍스트로 만드는 것이 더 나은 선택입니다. 물론 일반 텍스트로 작성하는 것은 압축된 이진 포맷을 사용하는 것 보다 공간을 많이 차지할 수도 있고 일반텍스트를 해석하고 처리하는 시간 때문에 더 많은 계산이 필요할 수도 있습니다. 하지만 그럼에도 일반 텍스트의 사용할 때 얻을 수 있는 이점은 많습니다. 

 

- 구식이 되는 것에 대한 보험

   모든 코드는 구식 코드가 되기 마련입니다. 오랜 시간이 지나 코드를 열어볼 때에 코드를 작성한 당사자가 아니라면, 심지어 작성한 당사자도 오랜 시간이 흘러 코드를 보면 해당 코드가 무엇을 의미하는지 확인하는데 많은 시간이 필요할 지도 모릅니다. 하지만 일반 텍스트를 이용한 코딩이 되어 있다면 간편하게 정보를 찾을 수 있을 것 입니다.

 

- 호환성

  소스코드 관리 시스템, 컴파일러 환경, 에디터, 단독으로 사용되는 필터에 이르기까지 컴퓨팅 세계의 거의 모든 도구들은 일반 텍스트를 다룰 수 있습니다. 만약 사이트 별로 복잡한 설정 파일을 갖는 큰 애플리케이션이 설치되어 있다고 가정할 때 설정파일들이 일반 텍스트로 되어 있다면 그것을 소스코드 관리 시스템 하에 둘 수 있을 것이고, 그 덕분에 모든 변화의 역사를 자동으로 유지할 수 있을 것 입니다.

 

-  더 쉬운 테스트

  만약 시스템 테스트를 구동하게 할 합성 데이터를 만들기 위해 일반 텍스트를 사용한다면, 특별한 도구를 만들어야 할 필요 없이 간단한 테스트 데이터를 추가, 업데이트, 수정할 수 있습니다.

 

자율적으로 서로 데이터를 교환하면서 인터넷을 여행하는 XML 기반의 에이전트의 미래에서도 어디에나 존재하는 텍스트파일은 여전히 살아남을 것 입니다. 사실, 이질적인 환경에서는 일반 텍스트의 장점이 모든 단점을 보상하고도 남습니다. 모든 이들이 공통의 표준을 사용해 소통해야만 한다면 그 표준은 일반 텍스트일 것 입니다.

 

15. 조개 놀이

  이번 장에서는 명령어 사용에 대한 중요성을 알려줍니다. 요즘은 GUI 인터페이스 속에서 IDE를 이용한 개발을 주로 배우고 진행하게 됩니다. 물론 GUI는 빠르고 편리할 수 있지만 모든 작업을 GUI 로만 하게 된다면 본인이 가진 환경의 모든 장점을 이용하지 못하게 될 수 있습니다. GUI의 장점은 화면에 보이는 모든 것을 얻을 수 있다는 것 이지만, 단점은 화면에 보이는 것이 얻을 수 있는 전부 라는 것 입니다. 말이 꽤 오묘한데 GUI를 사용하면 눈에 보이는 것 외에는 얻지 못하게 된다는 말 입니다. 

  셸을 이용한 작업은 분명히 불친절 하다고 느낄 수 있습니다. 그러나 그 사용법을 익히고 활용해 나간다면 셸 명령은 간결하지만 매우 강력항 효과를 보여 줄 수 있을 것 입니다. 

 

16. 파워 에디팅

  우리는 적어도 하나의 에디터에는 능숙해질 필요가 있습니다. 그리고 가능한 모든 편집 작업을 그 에디터를 사용하여 작업하면 좋습니다. 텍스트를 조작하는 데에 생각을 할 시간을 최소화 하고 그저 그 도구를 이용해서 어떤 코드를 작성할 지만 고민을 할 수 있어야 합니다. 만약 이미 손에 익은 에디터가 존재하지 않는다면 가능한 많은 플랫폼에서 지원하는 에디터를 선택하여 익힐 수 있다면 좋습니다.

 

17. 소스코드 관리

  컴퓨터를 이용해 작업하는 대부분의 이들이 가장 많이 사용하는 단축키는 ctrl + z(window의 경우)으로 되돌리기 버튼입니다. 글을 작성하거나 그림을 그리거나 편집을 할 때 등 모든 상황에서 대부분 사용이 가능합니다. 그러나 이는 짧은 시간 내에서만 사용이 가능하며 일주일 전의 작업까지 되돌아 가기는 불가능합니다.

  소스코드 관리 시스템을 사용하면 이를 가능하게 합니다. 물론 소스코드 관리 시스템이 코드를 저장하는 것 만 가지고 있는 것은 아닙니다. 이전 버전과 지금 버전의 차이점은 무엇인지, 어떤 파일들이 가장 많이 바뀌었는지, 이번 수정에서 코드가 몇 줄이 바뀌었는지 등등 다양한 데이터를 확인할 수 있고 이 데이터는 감사, 품질 관리 등에 사용될 수 있습니다. 또 두 사람 이상의 사용자가 동일한 파일들에 대해 동시 작업을 할 수 있도록 도와주기도 합니다.

  어떻게 보면 매우 위험해 보이는 시스템이지만 여러 크기의 프로젝트에서 잘 작동하고 있습니다. 만약 본인의 팀에 소스코드 관리 시스템을 사용하고 있지 않다면 이를 도입하는 것은 매우 큰 생산력 향상을 도와줄 수 있을 것입니다. 

 

18. 디버깅

  프로그래머들은 디버깅 하는데 대부분의 시간을 보내고 있을 것입니다. 버그가 발생했을 때 당황하지 말고 이를 해결해야할 문제 라는 것에 집중할 필요가 있습니다. 물론 디버깅을 해야하는 상황이 본인에게 편안하지 않을 수 있습니다. 마감일이 임박해 있거나 상사나 클라이언트가 재촉하고 있을 수 있는 상황일 수 있습니다. 그래도 당황하지 말고 차분하게 무엇이 버그를 일으키고 있을지 실제로 생각해 보는 것이 중요합니다.

 

  버그를 처음 발견했다면 "그건 불가능해"나 "정말 그럴 리가 없는데"같은 생각을 가지는 것은 무의미합니다. 왜냐하면 분명히 그런 일은 일어날 수 있으며, 실제로 발생했기 때문입니다.

 

어디에서 시작할까

  일단 발생한 버그를 살펴보기전에 작업하고 있는 코드가 깨끗히 컴파일된 코드인지 확인하고, 컴파일러의 경고 레벨이 최고 수준으로 높여져 있는지 확인해야 합니다. 컴파일러가 찾아 줄 수 있는 문제를 찾느라 시간을 낭비한다는 것은 말도 안되기 때문입니다. 그리고 버그가 발생하게 된 경위를 자세하게 조사할 필요가 있습니다. 되도록이면 버그를 발견한 당사자에게 직접 어떤 상황에서 어떤 동작을 했을 때 발생한 버그인지 듣는 것이 좋은 방법입니다.

 

디버깅 전략

  문제가 어떻게 발생하는지 파악했다면 이제는 프로그램의 데이터를 살펴보는 것 입니다. 데이터와 데이터들 사이에 존재하는 모든 상호관계를 시각화 할 수 있는 디버거를 사용할 수도 있고, 그렇지 않다면 의심가는 부분에 직접 출력 코드를 추가하는 방식으로라도 언제 어떤 변수가 어떤 값들을 가지고 있는지 파악하는 것이 좋습니다.

 

고무 오리

  문제의 원인을 찾는데 매우 단순하지만 유용한 기법으로는 다른 누군가에게 그걸 설명하는 방법이 있습니다. 설명을 듣는 누군가는 당신에게 설명을 들으며 여러분의 화면을 보며 계속 고개를 끄덕일 것입니다. 그 누군가는 말 한 마디 할 필요가 없으며, 그저 당신이 설명하는 코드의 역할을 듣기만 하면 됩니다. 이렇게 누군가에게 문제를 설명하게 된다면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기 해야만 하고 그 과정에서 그 동안 발견하지 못했던 부분을 발견할 수 있을 것 입니다.

 

  어떤 버그로 놀라게 될 때, 애지중지 믿고 있떤 진실들을 재평가 해야할 수도 있습니다. 정말 완벽하다고 알고, 버그의 원인이라고는 생각할 수조차 없는 바로 그 부분에서도 버그는 발생할 수 있다는 것 입니다. 만약 놀라운 버그를 마주친다면, 단순히 그걸 고치는 것을 넘어서, 왜 이 실패가 더 일찍 발견되지 않았을까 생각해 볼 필요가 있습니다. 그리고 버그를 미리 잡을 수 있또록 단위 테스트나 다른 테스트를 수정할 필요가 있는지 고려해야합니다.

 

마지막으로, 만약 버그가 누군가가 내린 잘못된 가정의 결과라면, 이 문제는 팀 전체와 함께 토론해야 합니다. 한 사람이 오해를 했다는 것은 다른 누군가도 오해하고 있다고 볼 수 있기 때문입니다.

 

19. 텍스트 처리

정리 뒤 추가 예정

 

20. 코드 생성기

정리 뒤 추가 예정