고객과 대화를 하면서 업무 요청에 대해서 다음과 같은 응답을 받았다.
음 과연 15개 이상의 사이트를 커버하는것과 Loosely Coupled 방식과의 상관관계가 어디 있는지 이해할 수 없는 말이었다.
Loosely Coupled라는 뜻을 과연 제대로 이해하고 있는지에 대해서 의심스러웠다.
Loosely Coupled라는 의미는 프로그램간의 연관성을 최소화 하여 각 모듈들을 Atomic하게 구성하는 의미이다. 그렇게 함으로 해서 모듈 변경이 전파하는 파급 효과를 최소한으로 줄여주는 역할을 도모하기 위한 것이다.
즉, 1모듈 1기능의 원칙을 지키고자 하는 방식이며, 그것을 실현하기 위한 실천적인 용어이다.
Coupling과 대비되는 단어를 Cohesion이라는 단어가 있다.
코히즌은 하나의 모듈 내부가 하나의 기능을 위해서 서로 일사분란하게 이루어지는 작업을 수행할 수 있도록 내부적으로 응집력을 향상시키고자 하는 목적이 있다.
가령 Member이라는 클래스가 있다고 하면 응집력 높은 클래스는, 멤버에 관련된 대부분의 속성과, 행동을 Member이라는 클래스에서 처리한다는 것을 말한다. 클래스 내부에서 사용되는 각 메소드는 서로 상호작용을 해도 전체 시스템이 아무런 문제가 없기 때문에 응집력은 높은것이 좋다.
위에서 이 고객이 이야기할 용어는 바로 Backward Compatible라는 용어이다.
이것은 버젼 1.0의 패키지가 있다고 할때, 기능을 추가하여 v2.0을 만들어도 그것이 1.0을 사용하던 15개의 사이트가 2.0을 사용하더라도 아무런 영향없이 자신의 기능을 그대로 사용할 수 있도록 만드는 것을 말한다.
즉, 낮은 버젼을 사용하던 시스템이 높은 버젼의 부품을 사용하더라도, 동작하는데는 아무런 문제가 없게 만드는것이다.
그리고 Backward Compatible를 수행하는데는 API를 수정한다고 해서 아무런 문제가 발생하지 않는다.
보통 자바에서는 버젼 1.0에 test()라는 메소드가 주로 사용되고 있었는데, 2.0버젼에서 새로운 기능을 추가하고자 한다면 1.0의 test()라는 메소드는 그대로 놓아두고 주석으로 deprecate 시켜놓고, 2.0에 필요한 새로운 메소들르 만들어 이용하게끔 한다.
즉, 기존 시스템이 깨어지지 않도록 1.0에서 쓰던 메소드는 그대로 놓아두고, 권고사항으로 쓰지말라는 디프리케이트를 준다는 것이다.
음..
요즘 개발을 하다보면 용어를 남발하는 경우가 많이 생긴다.
이것은 개발자로서의 신뢰도를 깍아먹는 행동임을 알아야 할 것이다.
참고로 API를 사소하게 변경하지는 않습니다.
XX패키지는 15개 이상의 사이트를 커버해야 하기 때문에 Loosely Coupled방식으로 사용합니다.
추가되는 항목같은 경우 Notes필드(비고필드)등을 사용하고 프론트페이지에서 그것을 꺼내서 필요에 따라 가공해서 사용하게 됩니다.
음 과연 15개 이상의 사이트를 커버하는것과 Loosely Coupled 방식과의 상관관계가 어디 있는지 이해할 수 없는 말이었다.
Loosely Coupled라는 뜻을 과연 제대로 이해하고 있는지에 대해서 의심스러웠다.
Loosely Coupled라는 의미는 프로그램간의 연관성을 최소화 하여 각 모듈들을 Atomic하게 구성하는 의미이다. 그렇게 함으로 해서 모듈 변경이 전파하는 파급 효과를 최소한으로 줄여주는 역할을 도모하기 위한 것이다.
즉, 1모듈 1기능의 원칙을 지키고자 하는 방식이며, 그것을 실현하기 위한 실천적인 용어이다.
Coupling과 대비되는 단어를 Cohesion이라는 단어가 있다.
코히즌은 하나의 모듈 내부가 하나의 기능을 위해서 서로 일사분란하게 이루어지는 작업을 수행할 수 있도록 내부적으로 응집력을 향상시키고자 하는 목적이 있다.
가령 Member이라는 클래스가 있다고 하면 응집력 높은 클래스는, 멤버에 관련된 대부분의 속성과, 행동을 Member이라는 클래스에서 처리한다는 것을 말한다. 클래스 내부에서 사용되는 각 메소드는 서로 상호작용을 해도 전체 시스템이 아무런 문제가 없기 때문에 응집력은 높은것이 좋다.
위에서 이 고객이 이야기할 용어는 바로 Backward Compatible라는 용어이다.
이것은 버젼 1.0의 패키지가 있다고 할때, 기능을 추가하여 v2.0을 만들어도 그것이 1.0을 사용하던 15개의 사이트가 2.0을 사용하더라도 아무런 영향없이 자신의 기능을 그대로 사용할 수 있도록 만드는 것을 말한다.
즉, 낮은 버젼을 사용하던 시스템이 높은 버젼의 부품을 사용하더라도, 동작하는데는 아무런 문제가 없게 만드는것이다.
그리고 Backward Compatible를 수행하는데는 API를 수정한다고 해서 아무런 문제가 발생하지 않는다.
보통 자바에서는 버젼 1.0에 test()라는 메소드가 주로 사용되고 있었는데, 2.0버젼에서 새로운 기능을 추가하고자 한다면 1.0의 test()라는 메소드는 그대로 놓아두고 주석으로 deprecate 시켜놓고, 2.0에 필요한 새로운 메소들르 만들어 이용하게끔 한다.
즉, 기존 시스템이 깨어지지 않도록 1.0에서 쓰던 메소드는 그대로 놓아두고, 권고사항으로 쓰지말라는 디프리케이트를 준다는 것이다.
음..
요즘 개발을 하다보면 용어를 남발하는 경우가 많이 생긴다.
이것은 개발자로서의 신뢰도를 깍아먹는 행동임을 알아야 할 것이다.
'Architect' 카테고리의 다른 글
Pratical Java 기본정의 (1) | 2008.10.15 |
---|---|
리스크관리 개요 (0) | 2008.07.17 |
Ship It - 부록 소스코드 관리 도구 - (0) | 2008.06.27 |
Ship It - 부록 Tip 조언 요약 - (0) | 2008.06.27 |
모래상자(Sandbox) 안에서 개발하기 -- Ship IT -- (0) | 2008.06.24 |