happyness

1. 문제점
재사용은 바람직한 소프트웨어 기술이고, 복사-붙이기는 종종 재사용에 있어 가장 간단한 방법인 것처럼 보임. 사실, 복사-붙이기 해서 약간의 수정을 통해 코드를 재사용하는 것이 쉽고 빠르기 때문.
하지만 이 방법은 개발과 유지보수 사이클이 몇 번 반복되어짐에 따라 몇 가지 문제점이 발생.
어플리케이션이 복사-붙이기 방식을 사용할 경우, 해당 코드의 여러 개의 복사본이 존재하고, 코드 변경시 이 복사본들을 다 변경해 주어야 함.


2. 징후 및 결과 (Symptoms and Consequences)

• 버그가 시스템의 여러 부분에서 발생되고 있음. 시스템의 한 부분에서만 버그를 해결하는 것이 아니라, 같은 버그를 시스템의 다른 부분에서도 해결해야 함.
• 코드의 라인수가 증가함. 따라서 코드를 리부하고 유지관리하기 위해 필요한 노력 또한 증가하게 됨.

3. 리팩토링된 해결방안 (Refactored Solutions)
복사-붙이기 기술을 이용해 코드를 재사용하기 보다는, 코드를 복사하거나 수정하지 않으면서 코드를 재사용할 수 있어야함.
사이즈가 작으면서 응집력이 높은 클래스들은 사이즈가 크거나 응집력이 낮은 클래스보다 훨씬 더 재사용성이 높음.


4. 관련 패턴 (Related Pattern)

• Adapter
  기능을 정의하고 있는 콤포넌트가 제공하는 인터페이스와 다른 인터페이스를 사용하는 콤포넌트의 코드를 재사용할 수 있도록 함.
  

happyness Programming/J2EE Patterns Cut-and-Paste, 안티패턴

1. 문제점
Spaghetti Code는 구조화가 잘 안되어 있어서 코드가 변화함에 따라 점차적으로 해결하기 어렵게 되는 코드를 말함.

Spaghetti Code는 컴퓨터 프로그래밍 환경에서 가장 일반적이면서, 가장 오래된 안티 패턴일 것임. 그러나 잘 구조화되어 있지 않아서 이해하고, 변경하고, 재사용하고, 유지보수하기가 어려운 코드 임.

OOP 언어에서, Spaghetti Code는 많은 메소드를 가지고 있는 사이즈가 큰 클래스에서 자주 발견됨.


2. 징후 및 결과 (Symptoms and Consequences)

• 메소드 선언부에 선언되어 있는 파라메터가 거의 없으면서, 메소드 바이에서는 많은 클래스와 전역 변수를 사용하고 있음.
• 인터페이스 상속과 폴리모피즘이 효율적으로 사용되고 있지 않음.
• 단지 오브젝트와 메소드의 일부분만이 재사용 가능하고, 이때 재사용도 복사-붙이기 방식을 사용해야 함.
• 캡슐화가 효율적으로 사용되고 있지 않음.
• 새로운 특성을 추가함으로써 코드가 점점 더 엉키게 됨에 따라 유지보수하고 변경시키기가 어려워짐.

3. 리팩토링된 해결방안 (Refactored Solutions)
오브젝트 중심의 프로그래밍 언어에서, Spaghetti Code를 피하는 방업은 좋은 오브젝트 중심의 프로그래밍 기술을 정확히 잘 이해해서 사용하는 것으로 시작. 오브젝트 중심의 기술을 사용하면서 잘 설계되어 있는 아키텍쳐와 디자인은 구조화된 코드를 작성하는 데 있어 중요한 역할을 하게 됨.

좋은 디자인, 아키텍쳐와 더블어 좋은 프로그램밍 스타일은 Spaghetti Code를 줄이 수는 있지만 없앨 수는 없음. Spaghetti Code를 없앨 수 있는 방법은?
프로그래밍은 어렵고 코드가 항상 좋은 구조로 구현되지 않음은 피할 수 없는 사실임. 이런 코드는 새로운 특성이 추가됨에 따라 문제를 더 악화시키게 됨.
따라서, 코드 리팩토링 또한 좋은 프로그래밍을 위해 중요한 부분임. 리팩토링은 코드의 기능에 전혀 영향을 주지 않으면서 코드의 구조와 스타일을 개선시키는 과정임. 코드를 리팩토링할 때는 기능을 추가한다거나, 버그를 해결한다거나, 수행속도를 개선해야 하는 것과 같은 추가 작업을 하지 않으면서 코드의 가독성을 높이고 유지보수하기 쉽도록 하는데 많은 신경을 써야 함.


4. 관련 패턴 (Related Patten)

• GoF Pattern
• J2EE Pattern
• Architecture Pattern
• AntiPattern
  

happyness Programming/J2EE Patterns Spaghetti Code, 안티패턴

1. 문제점
언테프라이즈 어플리케이션과 같은 복잡한 소프트웨어 개발시 보통 웹 서버, 어플리케이션 서버와 같이 기초가 되는 기술 사용이 필요. 이때, 프로젝트가 특정 벤더 제품에 고정되어질 경우, 다른 벤더 제품간 변경이 쉽지 않음.
이것은 어플리케이션을 장기적으로 사용하게 될 경우, 많은 문제를 발생시키게 됨.


2. 징후 및 결과 (Symptoms and Consequences)

• 벤더사의 제품에 있는 결함으로 인해 어플리케이션 기능이 제한적임.
• 벤더사의 제품에서 다양한 문제가 발생함으로써 어플리케이션의 유지보수가 어렵고 또한 비용이 많이 듬.
• 어플리케이션이 다른 벤더사의 제품에서 동작하기 위해서는 어플리케이션의 대부분이 재작성되어야 함.

3. 리팩토링된 해결방안 (Refactored Solutions)
대중적인 스펙을 구현하고 있는 제품을 사용함으로써 문제점을 많이 줄일 수 있음. 그러나, 보통 특정 벤더사와 제품에 의존적인 코드를 완전히 제거하는 것은 불가능 함.

그렇다면, 특정벤더사 제품에 의존적인 코드를 완전히 제거할 수 있는 방법은?
특정 벤더사 제품에 의존적인 코드는 별도의 레이어를 만들고, 이 레이어에 별동의 클래스를 만들어 놓아야함. 이 방법을 사용했을 경우, 벤더가 바뀌어도 대개 별도의 레이어에 존재하는 클래스들만 재프로그래밍 하면 됨.


4. 관련 패턴 (Related Patterns)

• Data Access Object
  

happyness Programming/J2EE Patterns Vendor Lock-In, 안티패턴

1. 문제점
어떤 기술에 익술해졌을 때, 다른 직면한 문제에도 이 기술을 적용하려고 함. 심지어 이 기술이 직면한 문제를 해결하기에 부적절한 경우에도 적요하려함.


2. 징후 및 결과 (Symptoms and Consequences)

• 어떤 특정 기술이 다방면에서 다양한 목적을 위해 사용되고 있음.
• 사용되고 있는 기술을 이용해 기능적 또는 비기능적 요구사항을 만족시키기가 어려움.
• 개발자는 다른 종류의 기술을 이용해 이들이 가지고 있는 경험과 지식을 확장할 수 없음.

3. 리팩토링된 해경방안 (Refactored Solutions)
최첨단 기술을 계속해서 학습해야 함.

따라서, 다양한 기술의 장정과 단점을 알게 되고 다른 툴들이 개발하고자 하는 시스템의 개발목적에 적합한지 이해할 수 있어야 함.
게다가, 시스템을 별도의 티어 또는 별도의 개발 영역으로 나우어서 상호운영 가능한 기술을 이용해 개발함으로써 더 쉽게 서로 다른 기술을 혼합하여 사용할 수 있음.


4. 관련 패턴 (Related Patterns)

• Movel View Controller
  어플리케이션 개발 영역을 분명히 나누어 줌으로써 서로 다른 기술을 적용할 수 있도록 도와줌
  
• Layers
  어플리케이션 개발 영역을 분명히 나누어 줌으로써 서로 다른 기술을 적용할 수 있도록 도와줌
  
• Facade
  서로 다른 기술을 사용하고 있는 영역간 커플링을 느슨하게 할 수 있음.
  

happyness Programming/J2EE Patterns Golden Hammer, 안티패턴

1. 개요
여기서 소개하는 안티 패턴들은 자바 프로그래밍 언어가 만들어지기 전부터 존재하던 패턴들로, 대부분의 개발 팀이 사용하는 프로그램밍 언어 또는 개발 플랫폼이 무엇이든 상관없이 직면하게 되는 공통적이면서 심각한 문제를 다루고 있음.


2. 종류

• Golden Hammer AntiPattern
  모든 문제를 해결하기 위해 항상 하나의 툴만을 사용.
  
• Vendor Lock-in AntiPattern
  프로젝트가 특정 벤더 제품에서만 동작.
  
• Spaghetti Code AntiPattern
  잘 구조화되지 않은 코드는 유지보수 및 관리하기가 어려움.
  
• Cut-and-Page AntiPattern
  코드가 복사-붙이기 기술을 이용해 개발됨
  

happyness Programming/J2EE Patterns 안티패턴

1. 정의 및 목적

• 안티 패턴이란?
  안티 패턴은 잘 알려져 있는 소프트웨어 시스템에 부정적인 영향을 주는 코드 개발 습관으로 디자인 패턴에서 확장되어 안티 패턴이 나오게 된 것은 자연스러운 일임.
  안티 패턴은 아키텍쳐 개념과 실제 구현간의 차이를 줄여줌. 잘못된 코드 개발 습관을 찾아서 문서화함으로써 향후 개발자들이 안티 패턴을 이해하고, 이와 같은 실수를 반복하지 않도록 함.
• 목적
  소프트웨어 개발시 이전에 했던 실수를 반복하지 않도록 함.
  안티 패턴은 이미 안티 패턴을 포함하고 있는 시스템을 리팩토링하는 방법을 제공.
  안티 패턴은 약간의 리팩토링 작업을 통해 최고 실행 사례를 찾아 낼 수 있도록 함.

2. 연구 기법


3. 구조

• 안티 패턴 문제점 (AntiPattern Problem)
  대개 부정적인 결과가 나오게 되는 부정적인 안티 패턴 문제점
• 징후 및 결과 (Symptoms and Consequences)
  대개 부정적인 징후 및 결과 리스트
• 리팩토링된 해결방안 (Refactored Solutions)
  해당 안티 패턴이 없애고 있는 리팩토링된 해결방안
• 관련 패턴 (Related Patterns)
  해당 안티 패턴과 관련된 기타 다른 안티 패턴 및 디자인 패턴

4. 분류

• General AntiPatterns
• Integration Tier AntiPatterns
• Business Tier AntiPatterns
• Presentation Tier AntiPatters
  

happyness Programming/J2EE Patterns 안티패턴