데이터 쓰임새 관찰과 표기

실전 시스템 수준 리팩토링 사례 4회

지난 2회에 작성한 테이블을 클래스로 묘사한 클래스도를 보면 이름이 같은 두 클래스(혹은 테이블)은 너무나도 다르게 생겼습니다. 인위적 사례가 아닌데, 놀랍게도 두 개 테이블은 너무나 다른 생각으로 만들어졌음을 짐작할 수 있습니다. 

여러 가지 생각을 할 수 있지만, 이 테이블을 만든 두 개발자가 서로 대화를 많이 하지 않았다는 사실이 느껴졌습니다. 코드를 다루는 조직에서 기술 부채란 표현을 쓰는 이들이 많습니다. 저는 기술 부채를 만드는 가장 큰 요인은 의사소통 부재에 있다고 믿습니다.

정규화 vs 역정규화

아무튼 위 그림에서 좌측의 테이블과 우측의 테이블을 보면 직관적으로 이분법으로 나눠볼 수도 있습니다. 좌측은 역정규화를 강조한 듯이 보입니다. 반면, 우측은 교과서적으로 정규화를 강조한 듯이 보입니다. 하지만, 이런 인상으로 작업을 시작하면, 편향의 함정에 빠지기 쉽습니다. 그래서, 쓰임새(Use Case)에 집중하기를 권합니다. 나의 선호가 아니라 어디서 쓰이느냐를 데이터로 사용하는 의사결정 방식이라 설명할 수도 있습니다. (조금 거창한가요?)

그래서, 클래스도를 보여주고 개발자에게 이 데이터를 사용하는 모든 화면을 뽑아 달라고 요구했습니다. 100%는 아닐지라도 대부분 화면에서 데이터를 입력하고 조회하니까요. 데이터에 대한 쓰임새를 돌아보는 훌륭한 출발점은 제공하죠.

화면 입출력과 속성 연결하기

대화를 효과적으로 하기 위해 개발자가 캡춰해준 화면을 보고 의문이 들긴 하지만 세부요인을 뒤로 하고, 당장 포착 가능한 화면 입출력을 클래스도에 표기해봅니다.

첫 시도는 아래 화면인데 물품기부신청 화면이라고 부르겠습니다.

위의 물품기부신청 화면을 대상으로 앞서 보여드린 donations 클래스에 입출력 속성을 표기하면 아래와 같습니다. 클래스도이니 속성이라고 표기했는데, donations 테이블의 필드라고 부르거나 인식해도 크게 무리는 없습니다.

당초에 색상만 구분하려다가 통상 속성의 타입(type)을 표기하는 공간에 화면 이름을 넣었습니다. 변칙 사용이지만, 방언을 써도 대화만 가능하다면 큰 문제가 없는 것처럼 당장은 가독성만 생각하겠습니다. plant uml에서 이걸 어떻게 하는지는 매뉴얼을 봐도 모르겠다는 분이 있을까봐 관련 스크립트를 남깁니다.

     <font color="#0067a3">물품기부신청화면 member_id

행 단위로 파싱을 하는지 굳이 닫는 </font> 태그는 없어도 됩니다. 속성 명 앞에 한글을 넣어줘도 문제가 없습니다.

앞서 보여드린 화면의 낱낱의 데이터와 그것의 보관장소로 추정되는 속성 사이에 연결을 클래스도에 색상으로 표현한 것입니다. 제가 자주 인용하는 함수 정의에 해당하는 매핑(mapping) 행위입니다.

단순 추정인데, 굳이 해석이 들어간 부분은 campaign_id와 member_id 정도입니다. 이 둘은 화면에 보이지는 않기 때문이죠. 일단, 이 화면만 보면 campaign_id와 member_id 속성 자체가 필요가 없습니다. 이 화면과 연관이 있는 다른 객체(혹은 테이블)가  campaign_id와 member_id를 이용할 경우 가치가 있는 것이죠. 그렇군요. 글 쓰면서 배운 내용인데, 위에 쓴 해석은 붉은 색으로 구분해 놓는 것이 더 풍부한 클래스도를 만들겠네요.

다른 화면도 이와 같은 작업을 할 수 있습니다. 화면이 여럿인데, 모두 이렇게 해볼 때 어떤 이슈들이 나타나는지를 다음 글에서 다루기로 하겠습니다.

글을 마치기 전에 클래스도와 같은 것을 그리는 이유가 의사소통에 있다는 점을 잊지 마시기 바랍니다. 또한, 혼자 개발하는 경우가 아니라면(사실은 혼자 개발하는 경우에도) 시스템의 잘 만들어지기 위해서는 의사소통은 너무나도 중요합니다.