격리(Isolation)
프로그램의 규모가 커지면 커질수록 실패할 확률이 높아집니다.
수많은 서브모듈이 복잡하게 통신하면서 개발자가 미쳐 생각하지 못했던 경우의 수가 발생하여 예외나 오류가 발생하여 전체적인 시스템 다운으로 이어집니다.
이는 개발 시에도 이 문제는 그대로 들어나는데, a클래스를 수정하면 그 여파가 a클래스의 자식, a클래스를 소유한 모든 객체, 인자로 a클래스를 받는 녀석 등으로 번집니다. 또한 여기서 끝나지 않고 b클래스가 a클래스를 소유했기 때문에 다시 b클래스의 자식, b클래스를 소유한 객체 등으로 끝없이 확장되어 번집니다.
일반적으로 이러한 문제를 회귀테스트의 문제라고 합니다.
회귀테스트란 어떤 내용을 수정하면 그 여파로 모든 내용을 처음부터 다시 검토해야하는 현상을 말합니다.
이 악몽에서 벗어나려면 어떻게 해야할까요?
TDD(테스트 주도 개발)
요즘 세상사람들이 말하는 테스트주도개발방법론이란게 있습니다. 어떠한 클래스를 개발하면 그 클래스나 메쏘드에 대해서 테스트도 같이 만들어서 테스트를 걸도록 하는 방법론입니다. 이는 듣는 순간 단순해보이지만 사실은 전혀 단순하지 않습니다.
1. 어떠한 클래스를 작성해도 테스트가 작성되기 되기 때문에 회귀테스트가 생기는지 아닌지를 즉시 알 수 있습니다.
2. 따라서 회귀테스트 문제가 생기지 않는 클래스만 작성해가기 때문에 전체적으로도 회귀테스트가 생기지 않고
3. 또한 어떤 모듈을 고쳤을때 이 문제가 시스템에 회귀테스트를 일으킬지 아닐지도 즉시 알 수 있습니다.
Isolation(격리)
사실 TDD는 실천적인 내용입니다. 즉 설계 상의 기술이나 개념이 아니라 코딩시 실천하면 좋은 실천강령같은 것이죠(물론 애자일개발론으로 연결하면 설계상의 개념으로 확대됩니다. 저도 개인적으로 켄트백팬입니다)
하지만 격리라는건 개발시에 항상 고려해야하는 개념같은 것으로 중복코드방지나, 단일책임의 원칙처럼 항상 근본적으로 고려해야하는 부분입니다.
격리라는건 간단히 말해 절대로 격리시킨 부분에서는 문제가 생기지 않는다는 확신입니다. 어떻게 그렇게 될까요?
가장 기본적으로는 런타임에 결정되는 내용을 없애면 가능합니다. 즉 아래와 같은 예를 볼까요?
function test($val:*):void{}
function test($val:Number):void{}
function test($val:int):void{}
function test($val:uint):void{}
function test($val:CintOverZero):void{}
test의 내용이 양수인 정수를 기반으로 개발되었다고 했을때 격리수준은 위에서 아래수준으로 높아집니다. test의 인자를 이미 양수임을 확신시켜주는 전용클래스(CintOverZero)로 받는 마지막 샘플은 격리의 전형적인 예를 보여줍니다. 사람보단 컴파일러가 확인하게 하고 그렇게 통과된건 컴파일러는 믿는 범위내에선 문제가 안생긴다고 확신할 수 있습니다.
따라서 test함수의 내부 로직이 잘못되어도 그건 인자로 음수나, 0이나 소수가 들어와서가 아니다라고 문제의 범위를 격리할 수 있습니다.
