블로그를 대함에 있어 머리와 손이 따로 움직이는 느낌입니다. 갈수록 블로그의 활용 가치가 높아져서 열심히 써야겠다는 마음은 드는데 글쓰기는 안하고 초저녁에 잠만 자고 있습니다.
블로그의 활용 가치중에 요즘 느끼는 것은 블로그를 배움의 도구로 쓸수 있다는 것입니다. 예를 들어 ‘객체 지향’은 이런것이다~ 라고 뜬구름 잡듯 어렴풋이 인식하고 있는 지식을 명쾌하게~ 글로 써서 독자에게 설명할 수 있을 정도까지 쓰려면, 그야말로 머리를 꽝꽝~ 벽에 부딪쳐 가며 사고력 부족의 한계를 이겨내야만 쓸 수 있습니다. 그래서 글쓰기로 프로그래밍 역량이든 교양능력이든 많이 향상시킬수 있다는 것을 느끼고 있습니다.
최근에 산고의 고통 끝에 배움의 기쁨을 얻기 위해 쓴 글중에 객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?) 등이 있습니다. 내용이 좋고 나쁘고를 떠나서 이런 '묵직한' 글을 쓰려면 하루나 일주일 동안 날 잡아서 써야 합니다.
예전에 우리 회사 동료들이 업무분석이면 분석, x-internet 등의 각분야에 일가를 이룬 분들이라고 쓴 적이 있습니다. 그 중에 데이터베이스를 잘 다루는 선배가 있습니다. 업무 회의를 하면 바로 데이터베이스 그림(ERD)이 그려지는 분입니다. 예를들어 "우리가 그린 이 UI설계서를 보니 PK는 이놈으로 잡고 테이블 관계는 이렇게 연결 하면 되겠고 혹시 데이터량이 많아질 때를 대비하여 집계 테이블을 별도로 만들자고~"
그 선배를 통해 최근에 데이터베이스 분석을 할일이 생겼습니다. 저는 머리를 긁적였습니다. 관계형 데이터베이스 공부는 했지만 실전 경험이 많이 없는 편이라 어색했거든요. 버벅거렸습니다. 객체지향적으로 생각하는 것은 그나마 익숙한데 관계형 데이터베이스 식으로 업무분석을 하려니 쉬운것도 생각이 잘 나지 않았습니다.
이번에 관계형 데이터베이스 식으로 버벅거리며 사고하면서 몇가지 생각을 해보았습니다.
이 물음은 일단 저한테 해당이 되는데 혹시 전반적으로도 해당이 되지 않을까 하여 던져보는 물음입니다.
저 같은 경우 객체지향 사고라고 하는 디자인 패턴, 리팩토링등의 기술들은 주로 어플리케이션 개발을 깔끔하게(흔히 말하는 유지보수와 확장성을 지향하는..) 하는데 쓰곤 하지 업무분석에 쓰지는 않았습니다.
예를들어 저 같은 경우 최근에 두어가지 프레임워크를 개발하면서 디자인패턴, 리팩토링등의 객체지향 기법과 객체지향 기술을 도와주는 스프링 프레임워크를 써서 개발하였듯이 객체지향은 주로 어플리케이션 개발을 도와주는 기법이었고요.
관계형 데이터베이스 사고는 업무분석할 때 업무분석의 결과가 데이터베이스의 테이블, 속성, 관계와 밀접하게 연동되어 표현될 수 있기 때문에 좀더 피부에 와닿게 쓰이는 것 같습니다.
제가 이렇게 생각해본 이유는 이런 경험도 해봤기 때문입니다. 예전에 CBD(컴포넌트 기반 개발 방법론=객체지향과 비슷한 개발 방법론)기반의 개발을 추구하는 프로젝트에 투입된적이 있는데 CBD 기반의 개발방법론에서는 산출물이 엄청나게 쏟아져 나와야 해서 제가 CBD문서만 전담하는 개발자로 참여한적이 있었습니다.
그래서 당시 CBD 관련 산출물, 유즈케이스 명세서, 아키텍트 기술서외 각종 UML 다이어그램 여러가지 그려봤는데요. 이것들이 대상 업무를 하나하나 차근차근 분석해가는 산출물이라는 느낌은 들긴 했는데 뭔가 대상업무와 착~ 달라붙는 맛은 없었습니다. 뭔가 겉돈다는 느낌이었다고 할까요.
그런데 CBD 프로젝트 공정 중간에 데이터베이스 설계를 하는 부분이 있었습니다. ERD가 한장 나왔는데 이 ERD 한장이 수많은 다른 CBD 산출물보다도 대상업무를 밀접하고 깔끔하게 표현한다는 느낌이 들었습니다.
'일단'이라고 한 이유는 풍부한 경험에 따른 완벽한 통찰이 아니고 이러지 않을까~ 라는 짐작이기 때문입니다. 설익은 지식일수 있음에도 이렇게 쓰는 이유는 지금의 제 생각을 글로 정리하면서 고수 개발자들의 가르침도 받고 싶기 때문이죠.
앞으로 저는 객체지향과 관계형 사고에 대하여 좀더 비교 공부하여 다시한번 치열하게 두 사고의 특징과 차이점을 파악하고 두 사고를 통합, 맵핑하여 업무분석이든 어플리케이션 개발이든 잘 활용할 수 있는 역량을 키우겠다는 다짐을 하였습니다.
객체지향과 관계형 사고를 둘 다 자유롭게 다룰 수 있다면 마치 스타크래프트에서 하이 탬플러가 합체하여 막강한 아콘이 되는 것처럼 엄청난 시너지 효과를 내리라 기대합니다.
그리하여 언제가 될지 모르지만 머리를 벽에 부딪치며 사고력의 한계를 절감하면서도 언젠가는 객체-관계 맵핑을 통한 업무분석과 어플리케이션 개발 잘하기~에 대한 글을 쓰려고 합니다. 기대해 주세요.
제가 IT에 대한 글을 쓰면 개발자를 위한 IT기사의 보물창고 IBM developerWorks를 꼭 찾아보곤 합니다. 그런데 객체-관계 맵핑에 관한 기사는 별로 없네요.
결국 이 기사를 소개하려고 합니다. '바쁜 자바 개발자를 위한 db4o 가이드: 소개와 개요
' 인데요. 친절하게 영어로 되어 있습니다. ^ ^; db4o 데이터베이스는 객체지향 데이터베이스라고 합니다. 기사중에..
라는 문장이 와 닿습니다.
> IBM developerWorks
바쁜 자바 개발자를 위한 db4o 가이드: 소개와 개요
IBM developerWorks에서 '데이터베이스'로 검색한 기사들
IBM developerWorks에서 '객체지향'으로 검색한 기사들
> 산골 블로그 developerWorks
객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?)
추상화의 고수가 되자. (생각의 탄생)
블로그의 활용 가치중에 요즘 느끼는 것은 블로그를 배움의 도구로 쓸수 있다는 것입니다. 예를 들어 ‘객체 지향’은 이런것이다~ 라고 뜬구름 잡듯 어렴풋이 인식하고 있는 지식을 명쾌하게~ 글로 써서 독자에게 설명할 수 있을 정도까지 쓰려면, 그야말로 머리를 꽝꽝~ 벽에 부딪쳐 가며 사고력 부족의 한계를 이겨내야만 쓸 수 있습니다. 그래서 글쓰기로 프로그래밍 역량이든 교양능력이든 많이 향상시킬수 있다는 것을 느끼고 있습니다.
최근에 산고의 고통 끝에 배움의 기쁨을 얻기 위해 쓴 글중에 객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?) 등이 있습니다. 내용이 좋고 나쁘고를 떠나서 이런 '묵직한' 글을 쓰려면 하루나 일주일 동안 날 잡아서 써야 합니다.
예전에 우리 회사 동료들이 업무분석이면 분석, x-internet 등의 각분야에 일가를 이룬 분들이라고 쓴 적이 있습니다. 그 중에 데이터베이스를 잘 다루는 선배가 있습니다. 업무 회의를 하면 바로 데이터베이스 그림(ERD)이 그려지는 분입니다. 예를들어 "우리가 그린 이 UI설계서를 보니 PK는 이놈으로 잡고 테이블 관계는 이렇게 연결 하면 되겠고 혹시 데이터량이 많아질 때를 대비하여 집계 테이블을 별도로 만들자고~"
그 선배를 통해 최근에 데이터베이스 분석을 할일이 생겼습니다. 저는 머리를 긁적였습니다. 관계형 데이터베이스 공부는 했지만 실전 경험이 많이 없는 편이라 어색했거든요. 버벅거렸습니다. 객체지향적으로 생각하는 것은 그나마 익숙한데 관계형 데이터베이스 식으로 업무분석을 하려니 쉬운것도 생각이 잘 나지 않았습니다.
이번에 관계형 데이터베이스 식으로 버벅거리며 사고하면서 몇가지 생각을 해보았습니다.
객체지향 사고는 어플리케이션 개발에 특화되고, 관계형 데이터베이스 사고는 업무분석에 특화된 것이 아닐까.
이 물음은 일단 저한테 해당이 되는데 혹시 전반적으로도 해당이 되지 않을까 하여 던져보는 물음입니다.
저 같은 경우 객체지향 사고라고 하는 디자인 패턴, 리팩토링등의 기술들은 주로 어플리케이션 개발을 깔끔하게(흔히 말하는 유지보수와 확장성을 지향하는..) 하는데 쓰곤 하지 업무분석에 쓰지는 않았습니다.
예를들어 저 같은 경우 최근에 두어가지 프레임워크를 개발하면서 디자인패턴, 리팩토링등의 객체지향 기법과 객체지향 기술을 도와주는 스프링 프레임워크를 써서 개발하였듯이 객체지향은 주로 어플리케이션 개발을 도와주는 기법이었고요.
관계형 데이터베이스 사고는 업무분석할 때 업무분석의 결과가 데이터베이스의 테이블, 속성, 관계와 밀접하게 연동되어 표현될 수 있기 때문에 좀더 피부에 와닿게 쓰이는 것 같습니다.
제가 이렇게 생각해본 이유는 이런 경험도 해봤기 때문입니다. 예전에 CBD(컴포넌트 기반 개발 방법론=객체지향과 비슷한 개발 방법론)기반의 개발을 추구하는 프로젝트에 투입된적이 있는데 CBD 기반의 개발방법론에서는 산출물이 엄청나게 쏟아져 나와야 해서 제가 CBD문서만 전담하는 개발자로 참여한적이 있었습니다.
그래서 당시 CBD 관련 산출물, 유즈케이스 명세서, 아키텍트 기술서외 각종 UML 다이어그램 여러가지 그려봤는데요. 이것들이 대상 업무를 하나하나 차근차근 분석해가는 산출물이라는 느낌은 들긴 했는데 뭔가 대상업무와 착~ 달라붙는 맛은 없었습니다. 뭔가 겉돈다는 느낌이었다고 할까요.
그런데 CBD 프로젝트 공정 중간에 데이터베이스 설계를 하는 부분이 있었습니다. ERD가 한장 나왔는데 이 ERD 한장이 수많은 다른 CBD 산출물보다도 대상업무를 밀접하고 깔끔하게 표현한다는 느낌이 들었습니다.
이렇게 제 경험에 미루어 볼때 객체지향은 주로 어플리케이션 개발에 유익하게 쓰이고, 관계형 데이터베이스식 사고는 업무분석에 유익하게 쓴다고 ‘일단’ 생각해봤습니다.
'일단'이라고 한 이유는 풍부한 경험에 따른 완벽한 통찰이 아니고 이러지 않을까~ 라는 짐작이기 때문입니다. 설익은 지식일수 있음에도 이렇게 쓰는 이유는 지금의 제 생각을 글로 정리하면서 고수 개발자들의 가르침도 받고 싶기 때문이죠.
앞으로 저는 객체지향과 관계형 사고에 대하여 좀더 비교 공부하여 다시한번 치열하게 두 사고의 특징과 차이점을 파악하고 두 사고를 통합, 맵핑하여 업무분석이든 어플리케이션 개발이든 잘 활용할 수 있는 역량을 키우겠다는 다짐을 하였습니다.
객체지향과 관계형 사고를 둘 다 자유롭게 다룰 수 있다면 마치 스타크래프트에서 하이 탬플러가 합체하여 막강한 아콘이 되는 것처럼 엄청난 시너지 효과를 내리라 기대합니다.
그리하여 언제가 될지 모르지만 머리를 벽에 부딪치며 사고력의 한계를 절감하면서도 언젠가는 객체-관계 맵핑을 통한 업무분석과 어플리케이션 개발 잘하기~에 대한 글을 쓰려고 합니다. 기대해 주세요.
제가 IT에 대한 글을 쓰면 개발자를 위한 IT기사의 보물창고 IBM developerWorks를 꼭 찾아보곤 합니다. 그런데 객체-관계 맵핑에 관한 기사는 별로 없네요.
결국 이 기사를 소개하려고 합니다. '바쁜 자바 개발자를 위한 db4o 가이드: 소개와 개요
' 인데요. 친절하게 영어로 되어 있습니다. ^ ^; db4o 데이터베이스는 객체지향 데이터베이스라고 합니다. 기사중에..
데이터베이스 전쟁은 끝났고, 관계형 데이터베이스가 승리한 것으로 알려졌습니다.
라는 문장이 와 닿습니다.
> IBM developerWorks
바쁜 자바 개발자를 위한 db4o 가이드: 소개와 개요
IBM developerWorks에서 '데이터베이스'로 검색한 기사들
IBM developerWorks에서 '객체지향'으로 검색한 기사들
> 산골 블로그 developerWorks
객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?)
추상화의 고수가 되자. (생각의 탄생)