스파르타쿠스 시즌1(망할!) 13화

한 시즌으로 끝맺지 않고 시즌 2로 넘어가디니 너무합니다.

계속 전개가 느리다가 13화에서 갑자기 초고속으로 후르릅챱챱 해치우는걸 보니 뭔가 이상한 느낌이 드네요. 얘들 원래 한 시즌 20화 정도로 계획해놨다가 반응이 괜찮으니까 시즌 늘려보려는 것 같습니다.

그래도 시즌 3까지 가지는 않겠죠? 뭐..몇 개월 내로 다 죽고 끝날테죠. 아무리 디테일하게 들어가도 뭐..

시즌 2 기다리기 힘들 것 같습니다.ㅠ 시즌 1을 다시 보며 기다리자니 두 번 볼 작품은 아닌것 같고..흑

정적분석 = 냄새 맡기

작은 개인 프로젝트에 CI를 적용해 보며 자연스레 떠오르게 되는 생각이 있네요. 정적분석이란 코드 냄새맡기를 자동화 해주는게 아닐까 하고요.

CI 도입이 그닥 간단한 일은 아니기에(공부할게 얼마나 많던지;) ant 빌드 스크립트를 작성하는 것 부터 시작해서 조금씩 도입 수준을 높여가고 있습니다. 아직 CI 툴은 도입하지 못하고 빌드 스크립트를 계속 확장하고 삽질하고 다듬고 있습니다. 프로젝트의 한 부분이 완성될 때마다 잠시 멈춰 CI 진도를 나가는 거지요.

코드 정적분석 툴을 도입해 보려고 이것저것 찾아보는데 문득 드는 생각이 정적분석은 리팩토링을 위한 냄새맡기가 아닐까 였습니다. CPD 같은 경우에는 복사/붙여넣기 한(중복된) 코드를 찾아주지요. 마틴 파울러는 그의 책 리팩토링에서 중복된 코드를 악취 퍼레이드의 일등으로 꼽아놓았습니다. 이런 중복된 코드를 치유하기 위한 적당한 리팩토링은 Extract Method, Pull Up Method, Extract Class와 같은 것들이 있지요. 순환 복잡도를 계산해주는 툴도 있습니다. 순환 복잡도가 높으려면 아무래도 긴 메소드가 되기 마련입니다. 역시 리팩토링 대상이 됩니다.

그 외에도 코드 속 나쁜 냄새로 지적되는 긴 파라미터 리스트(CheckStyle로 찾을 수 있겠죠?), 확산적 변경 등도 많은 부분은 정적분석을 통해 찾아낼 수 있는 것 같습니다.

리팩토링 공부하면서 느꼈던게 '나쁜 냄새' 맡는 부분이 가장 어렵다는 것이었습니다. 코드를 읽는다는 것 자체가 쉬운 일이 아니니까요. 그런 걸 도와줄 수 있는게 정적분석 도구들인 것 같습니다.

긍정적 피드백

지속 가능한 관계의 핵심은 '긍정적 피드백'이 아닐까요? 오늘 출근길에 오징어가 되어가며 그런 생각을 해봤습니다.

연애도 결혼도 가족도 '긍정적 피드백'이 있어야 건강한 관계가 생기는 것 같아요. 그런것..같아요. 다들 아는 얘기아닌가;;

테스트의 레벨

 보통 회사에서 테스트를 3가지 정도의 레벨로 구분하여 다루곤 합니다. 첫 번째로 개발자 테스트, 산출물도 작성하게 되는 단위 테스트 그리고 시스템의 최상위 수준(UI)부터 최하위 수준(데이터)까지를 다루는 통합테스트가 있습니다. 그런데 막상 테스트를 하자면 다 그게 그겁니다. 구현된 시스템 자체도 정확히 레벨을 구별할 수 없는데 테스트라고 구분할 수 있을리가 없기 때문입니다.

 예전에 학교 홈페이지 개발실에서 일할 때는 주로 PHP나 ASP로 프로그래밍을 했습니다. 작은 단위의 시스템에 적용할 수 있는 가장 가벼운 개발 방법인 model-1으로 말이죠. 하나의 php 함수에서 파라미터 처리와 데이터 조작, 출력화면 구성까지 모든 걸 다 합니다. php 프로그램의 가장 작은 단위를 함수로 생각해 본다면 기능 단위와 구현 단위가 함수 하나로 동일한 경우이죠. 단위 테스트와 시스템 테스트를 거의 동일하게 화면에서 버튼을 눌러보고 반응을 살펴보는 방식으로 하게 됩니다. 구현의 최상위 수준(UI)부터 최하위 수준(데이터)까지 버무려져 있다고 볼 수 있겠습니다.

 출근길에 지금 만들고 있는 애플리케이션에 어떻게 자동화 테스트를 할까 고민하다가 저런 생각이 들었습니다. CI 책에서의 가르침에 따르자면 단위 테스트는 (자바를 기준으로) 최소한의 의존성을 가진 클래스 단위로, 단위 테스트의 상위 레벨인 컴포넌트 테스트는 아직 어떤건지 감이 오지 않습니다. 시스템 테스트는 최상위~최하위, 외부 의존성까지 포함하여 테스트하는 것이라고 합니다.

 결국 구현하려는 시스템을 어떻게 나누고 구성하는지에 따라서 테스트할 수 있는 방법도 결정된다고 생각해 볼 수 있겠습니다. 구현 단위를 명확히 구분할 수 있고 시스템의 계층화가 잘 되어 있다면 테스트를 구성할 수 있는 방법도 역시 다양하고 보다 쉽게 자동화시킬 수 있을 것입니다.

 어떻게 시스템을 구성해야 할까? 는 별도의 문제인 것 같습니다. 그것에 대한 용어도 많고 조언도 많고 방법도 많습니다. 나중에 직접 체험해 보며 따로 다뤄보겠습니다.