프로그래밍로그

비난 대신 문제를 해결하라

다른 사람의 버그를 발견한 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 들이는 수가 있다. 어떤 회사에서는 비난이 문화의 일부고 거기서 카타르시스를 얻을 수도 있다. 하지만 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중하고 싶어 한다.

버그가 여러분의 잘못인지 다른 사람의 잘못인지는 그리 중요한 게 아니다. 어쨌거나 그 버그는 여러분의 문제로 남는다.
 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

GUI 인터페이스는 훌륭한 것이고, 몇 가지 간단한 조작에는 그게 더 빠르고 편리 할 수도 있다. 파일을 이동하고, MIME 형식으로 인코딩 된 이메일을 읽고, 글자를 쳐 넣고 하는 것들은 모두 그래픽 환경에서 하는 게 좋을 수 있다. 하지만 모든 작업을 GUI로만 한다면, 여러분이 가진 환경의 전체 능력을 이용하지 못하게 된다. 일반적인 작업을 자동화 할 수 없고, 쓸 수 있는 도구의 풀파워를 사용 할 수 없다. 게다가 도구를 결합해서 자신에게 꼭 맞는 매크로 도구를 만들 수가 없다. GUI의 장점은 WYSIWYG (What You See Is What You Get) 이지만, 반면에 단점은 WYSIAYG (What You See Is All You Get)이다.

GUI의 환경의 기능은 일반적으로 설계자의 의도에 따른 제약을 받는다. 설계자가 제공하는 모델 이상을 필요로 하더라도 대개는 어쩔 수 없다. 그런데 여러분은 종종 그 모델 이상을 필요로 한다. 실용주의 프로그래머들은 단지 코드를 자르거나, 객체 모델을 개발하거나, 문서를 작성하거나, 빌드 과정을 자동화하거나 하지만은 않는다. 이 모든 일을 다 한다. 어떤 도구든지 사용 범위는 보통 그 도구가 사용되리라고 예상되는 작업에 한정된다.

실용주의 프로그래머로서 여러분은 늘 임시변통의 작업을 수행하길 원한다. 해당 GUI가 지원하지 않을 수도 있는 그런 작업 말이다. 명령줄은 쿼리나 기타 다른 작업을 수행하기 위해 몇 개의 명령어를 재빨리 결합하려 할 때 사용하기 좋다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

프로토타입은 나중에 버릴 수 있는 코드를 만든다.
예광탄 코드는 기능은 별로 없지만 완결 된 코드이며, 최종 시스템 골격의 일부를 이룬다.
프로토타입을 예광탄이 하나라도 발사되기 전에 먼저 일어나는 정찰과 정보 수집으로 생각하면 되겠다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

프로토타입은 세부사항을 생략하고 시스템의 특정 측면에 초점을 맞추기 때문에 프로젝트를 진행하는 언어보다 고수준 언어 (예를 들면 펄, 파이썬, 혹은 Tcl)을 이용하여 구현 할 수 있다. 고수준 스크립트 언어는 (데이터 타입을 지정하는 등의) 많은 세부사항을 피할 수 있게 해주면서도 (비록 불완전하거나 느릴지라도) 작동하는 코드를 생성하게 해준다.

만약 프로토타입 사용자 인터페이스가 필요하다면 Tcl/Tk, 비주얼베이직, 파워빌더, 델파이 등을 고려 해 보라.

스크립트 언어는 또한 저수준의 요소들을 새롱누 조합으로 엮어 내는 '접착제'로 좋다. MS 윈도우즈를 이용한다면 비주얼베이직을 사용해 COM 컨트롤들을 조합 할 수 있다. 좀 더 일반적으로는 펄이나 파이썬 같은 스크립트 언어를 사용해 저수준의 C 라이브러리들을 조합 할 수 있는데, 이때 손으로 할 수도 있지만 무료로 사용가능한 SWIG 같은 도구를 이용해 자동화 할 수도 있다. 이러한 접근 방식을 취한다면 기존의 컴포넌트들을 빠르게 조합해 이들이 어떻게 동작하는지 볼 수 있을 것이다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

양자 역학 분야의 유명한 메타포인 슈뢰딩거의 고양이 이야기를 소개하려 한다. 어떤 고양이가 밀폐 된 상자에 갇혀있다. 상자 안에는 1시간에 1/2 확률로 알파 입자를 분해하는 알파 입자 가속기와 청산가리 통이 있다. 알파 입자가 분해되어 방출되면 청산가리 통의 센서에 감지되는데 이 경우 청산가리 통이 깨져 고양이는 죽게 된다. 1시간 후에 고양이는 살았을까, 죽었을까? 슈뢰딩거에 따르면 둘 다 옳은 답이다.

알파입자의 분해 주기마다 두 가지 가능한 결과가 있고, 이 때마다 우주는 복사 된다. 한 곳에서는 분해가 일어나고, 한 곳에서는 그렇지 않다. 그러므로 고양이는 한 우주에서는 살아있고, 다른 우주에서는 죽는다. 상자를 열어보았을 때 비로소 여러분이 어떤 우주에 속해 있는지를 알 수 있게 된다.

모든 상황을 대비한 코드를 작성하는 것은 어려운 일이다.

하지만 코드의 진화를 슈뢰딩거의 고양이로 가득 찬 상자로 생각하라. 각각의 결정은 다른 버전의 미래를 야기한다. 여러분의 코드는 몇 가지 가능한 미래를 지원 할 수 있는가? 어떤 미래가 일어날 가능성이 높을까? 그 미래가 닥쳤을 때, 이를 지원하는 것이 얼마나 어려울까?

상자를 열 용기가 있는가?

 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

직교적으로 설계, 구현한 시스템은 테스트하기 더 쉽다. 시스템 컴포넌트 간의 상호작용이 형식화되고 제한되었기 때문에 시스템 테스트의 더 많은 부분을 각각의 모듈 수준에서 수행 할 수 있기 때문이다. 이는 모듈 수준의 테스트가 통합 테스트보다 테스트케이스를 만들고 수행하기 훨씬 쉽다는 점에서 좋은 소식이라고 할 수 있다. 우리는 모든 모듈이 자신만의 단위 테스트를 위한 테스트케이스를 갖고, 테스트가 정규 빌드 과정의 일부로 수행되어야 한다고 생각한다.

단위 테스트를 만든다는 것 자체가 직교성을 테스트 해 볼 수 있는 흥미로운 작업이다. 단위 테스트를 빌드하고 링크하기 위해서는 어떤 작업이 필요한가? 시스템 나머지의 상당 부분을 끌어들여 테스트케이스를 만들고 컴파일 혹은 링크해야 하지는 않는가? 만약 그렇다면 이는 모듈과 시스템의 나머지 부분과의 결합도를 적절히 줄이지 못했다는 증거다.

버그 수정은 시스템의 직교성을 총체적으로 점검 해 볼 수 있는 값진 시간이다. 문제가 발생했다면 버그 수정이 얼마나 지역화 되어 있는지 평가해 보라. 모듈 하나만 변경하면 되는가? 변화가 시스템 전반에 걸쳐 분산되어 있지는 않은가? 수정을 했다면 모든 것이 제대로 고쳐졌는가? 수정이 끝난 후 생각지도 못 했던 곳에서 새로운 문제가 발생하지는 않는가? 만약 그렇다면 자동화에 집중 할 좋은 기회다. 만약 소스코드 관리 시스템을 사용한다면 버그를 수정하고 테스트를 마친 뒤 버그 수정에 대한 태그를 붙여라. 이렇게 하면 각 버그 수정에 의해 영향 받은 소스 파일의 개수에 대해 경향을 분석한 월 단위 리포트를 받아 볼 수 있을 것이다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

특정 기능에 대한 요구사항을 변경했을 경우, 몇 개의 모듈이 영향을 받는가?
직교적인 시스템에서는 답이 '하나' 여야 한다.
(이상적인 경우. 실제로는 직교적일지라도 하나보단 많은 경우가 많다)

 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

생산성 향상

변화가 국소화되서 개발 시간과 테스트 시간이 줄어든다. 상대적으로 작고, 자족적인 컴포넌트를 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 더 쉽다. 간단한 컴포넌트들은 설계하고, 코딩하고, 단위 테스트하고, 그러고는 잊어버릴 수 있다. 새로운 코드를 추가할 때마다 기존의 코드를 계속 바꾸어야 할 필요가 없다.

직교적인 접근법은 또한 재사용을 촉진한다. 컴포넌트들에 명확하고 잘 정의된 책임이 할당되어 있다면 애초의 구현자들이 미처 생각하지 못했던 방식으로 새로운 컴포넌트와 결합할 수 있다. 시스템이 더 느슨하게 결합되어 있을수록 재설정하고 리엔지니어링하기 쉽다.

직교적인 컴포넌트들을 결합하는 경우 꽤 미묘한 생산성 향상이 있다. 컴포넌트 하나가 M가지 서로 다른 일을 한다고 치고, 또 다른 컴포넌트 하나가 N가지 다른 일을 한다고 가정하자. 만약 그것들이 직교적이라면 결합했을 때 결과물은 M X N개 만큼  일을 한다. 그렇지만, 두 개의 컴포넌트가 직교적이지 못하면 겹치는 부분이 있을 테고, 결과물이 할 수 있는 일은 그 이하일 것이다. 직교적인 컴포넌트들을 결합함으로써 단위 노력당 더 많은 기능을 얻을 수 있다.

리스크 감소

감염된 코드는 격리된다. 어떤 모듈이 병에 걸렸다 해도 시스템의 나머지 부분으로 증상이 전파될 확률이 낮다. 게다가 그 부분만 도려내고 새롭고 건강한 놈으로 이식해 넣기도 쉽다.

시스템이 잘 깨어지지 않는다. 어떤 부분을 골라서 약간 바꾸고 수리해도 거기서 생기는 문제점들은 그 부분에만 한정될 것이다.

직교적인 시스템은 해당 컴포넌트들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기 때문에, 아무래도 더 많은 테스트를 하게 된다.

써드파티 컴포넌트로 연결되는 인터페이스들이 전체 개발의 작은 부분에 한정되기 때문에 특정 벤더나 제품, 플랫폼에 덜 종속될 것이다. 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

프로그래머는 자신의 코드에 주석을 달도록 교육받는다. 훌륭한 코드에는 주석이 많다고 배운다. 불행히도 그들은 코드에 왜 주석이 필요한지 배우지 않는다. 나쁜 코드야 말로 많은 주석을 필요로 한다.

Don't repeat yourself 원칙은 낮은 차원의 지식은 그것이 속하는 코드에 놔두고, 주석은 다른 높은 차원의 설명을 위해 아껴두라고 말한다. 그러지 않으면 지식을 중복하게 되며, 변경 할 때마다 매번 코드와 주석 모두를 바꾸어야 한다. 주석은 필연적으로 낡게 될 것이고, 믿을 수 없는 주석은 주석이 전혀 없는 것보다 더 심각한 문제를 만들어 낸다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기