2011/01/16 15:04 Developer
컴포넌트의 R&R, 그리고 시스템R&R
내가 기능을 구현할 때도 컴포넌트(클래스) 간에 R&R도 애매할 때가 있다. R&R은 비즈니스 로직을 어디에 두는 가를 결정해야 하기때문에 객체지향설계 시에 매우 중요한 요소이다.
R&R은 boundary하고도 밀접하다. 이 기능에 대한 문제의 해결의 R&R은 My boundary안에 있다면 문제를 해결하는 곳에서 처리를 해야 한다. 어떤 구조적인 문제로 문제가 전파가 되는 경우라면 그 문제를 My boundry에 갇아두고 다른 곳에는 영향을 끼치기 않게 해야 한다.
그렇게 R&R과 boundary를 만들어도 애매할 때 가장 중요한 원칙은 중복제거과 I/O throttling이다. 중복없이 역할을 가질 수 있는 방법을 찾거나 중복을 최소화해야 한다. 변경에 대해서 도메인 지식으로 가장 많이 알고 부분에서 주도권을 갖는 것으로 엑세스는 권한을 한군데로 집중해서 분산되지 않아야 한다. 둘다 애매한 경우에는 새로운 R&R을 가지는 컴포넌트를 만드는 경우가 있다. 새로운 R&R을 가지는 컴포넌트는 애매한 역할을 명확하게 만들고 그 역할의 문제를 해결해야 한다.
지난 주에는 2개의 인프라성 서비스와 회의를 할 시간이 있었다.
하나의 인프라는 새로운 기능 추가에 대한 업무를 최소화하기 위해서 중복을 허용하면서 R&R을 줄이려는 얘기를 계속한다. 원칙이나 룰도 없이 "어렵다/힘들다/공수가 많이 든다/자신이 없다"만 반복한다.
또 하나의 인프라는 이미 추가된 기능일지라도 인프라성으로 가져갈 수 있는 부분을 더 제공해서 서비스에서는 서비에 충실한 비즈니스 로직에만 집중을 할 수 있게 해준다. 오히려 너무 많은 부분에서 고려를 하는 것 같아서 메인Role에 집중을 할 수 있게 의견을 주었다.
정확한 분석/설계으로 통해서 R&R을 정확하게 만들지 않고 업무량을 줄이기 위한 방법으로 방향성을 정하는 경우가 있다. 주로 꼼수라는 표현을 많이 쓰는데 꼼수는 또 다른 꼼수를 하게 되고 변경에 제약사항이 계속 늘어가게 된다. 이 부채의 비용은 시간이 흐를 수록 급속도로 높아져서 결국에는 전체 시스템에 부담을 주게 된다.
객체지향설계/개발을 통해서 얻는 배움은 올바른 객체지향시스템에 대해서 알수 있게 하고 더 나아가서는 조직업무에도 적용을 할 수 있는 사고이다. 다양한 사람과 큰 그림에 대해서 이야기를 하다가보면 코드를 작성할 때도 어떤 식으로 하는지 뻔히 보인다. 구분하고 나누는 것은 쉽지 않은 일은 맞지만 원칙에 맍게 끊임없이 좋은 방향에 대해서는 고민을 해야 한다. 이미 잘못되어있다면 개선하는 것 그게 우리가 해야할 일 아닌가?
