http://crosscutter.info/90
본디 의존성은 존재 할수 밖에 없는 것이다..
다만. 오래전 부터 사람들이 생각 하고 고민했던 것은 어떻게 하면!
그런 실타래를 줄여 볼 수 있냐는 것이었다..
'느슨한' 을 목표로 한 그것은. 아마도 각 개발자의 시각에 따라 무척이나 달라 질수 있을것이다.
때마침 근래에 애자일 프랙티스 란 책을 읽으면서 내 생각을 달라 지게 했던 부분이 있는데..
개발을 시작 할때 부터 그 API에 대한 사용자가 되어 TDD(testcase)를 적용해 보자란
의견이었다..기본적 TDD에서 서비스적 TDD를 구성해 보란 의미가 아닐까 라고 생각이 되는데..(내 생각 일뿐;)
그것이 생각외로 좋은 아이디어가 아닐수 없었다.
실제 핵심적이고 실용적인 부분에 집중 할수 있고,
최소한의 노력으로 최대의 효율을 내는 목표에 충분히 부합이 가능한 방법이다..
(물론. 익숙해 지는데 시간은 투자해야 함은 마땅!)
이런 방식은 크게 보면 의존성에 대한 고민을 충분히 해결해 주지 않을까란 생각을 하게 한다.
최소한의 개발투자은 최소한의 의존성과 기존 API의 재사용을 이야기 하는 것이기 때문이다..
결과적으로 의존적 관계의 code들 보다는 기본적 API 인터페이스를 이용한 TDD 가능한 결과물을
산출 할수 있는 것이 된다.
현재 나의 스타일에도 이렇게 해봄을 목표로 하고 있다.
의외로 testcase 작성은 나로 하여금 여러 상황과 문제에 대한 집중을 유도 하고 있고,
더딘 시작을 뒤로 하고 효율적인 결과물을 내지 않을까란 고민과 기대를 같이 해보고 있다..
P.S
어차피 이런 답이 없는 명제는 개인의 경험과 노력의 산물로 터득되어 질수 있을것이다.
본디 의존성은 존재 할수 밖에 없는 것이다..
다만. 오래전 부터 사람들이 생각 하고 고민했던 것은 어떻게 하면!
그런 실타래를 줄여 볼 수 있냐는 것이었다..
'느슨한' 을 목표로 한 그것은. 아마도 각 개발자의 시각에 따라 무척이나 달라 질수 있을것이다.
때마침 근래에 애자일 프랙티스 란 책을 읽으면서 내 생각을 달라 지게 했던 부분이 있는데..
개발을 시작 할때 부터 그 API에 대한 사용자가 되어 TDD(testcase)를 적용해 보자란
의견이었다..기본적 TDD에서 서비스적 TDD를 구성해 보란 의미가 아닐까 라고 생각이 되는데..(내 생각 일뿐;)
그것이 생각외로 좋은 아이디어가 아닐수 없었다.
실제 핵심적이고 실용적인 부분에 집중 할수 있고,
최소한의 노력으로 최대의 효율을 내는 목표에 충분히 부합이 가능한 방법이다..
(물론. 익숙해 지는데 시간은 투자해야 함은 마땅!)
이런 방식은 크게 보면 의존성에 대한 고민을 충분히 해결해 주지 않을까란 생각을 하게 한다.
최소한의 개발투자은 최소한의 의존성과 기존 API의 재사용을 이야기 하는 것이기 때문이다..
결과적으로 의존적 관계의 code들 보다는 기본적 API 인터페이스를 이용한 TDD 가능한 결과물을
산출 할수 있는 것이 된다.
현재 나의 스타일에도 이렇게 해봄을 목표로 하고 있다.
의외로 testcase 작성은 나로 하여금 여러 상황과 문제에 대한 집중을 유도 하고 있고,
더딘 시작을 뒤로 하고 효율적인 결과물을 내지 않을까란 고민과 기대를 같이 해보고 있다..
P.S
어차피 이런 답이 없는 명제는 개인의 경험과 노력의 산물로 터득되어 질수 있을것이다.
반응형
'emotional developer > detect-pattern' 카테고리의 다른 글
Achieving Immutability with Builder Design Pattern (0) | 2010.08.05 |
---|---|
Refactoring Workbook (0) | 2007.11.18 |
Adapter pattern (0) | 2007.04.02 |