anti-pattern.md

안티 패턴

작성자 : 정희재

본 자료는 '파이썬 디자인 패턴 2/e (Chetan Giridhar)' 책을 토대로 작성되었습니다. 따라서 모든 예시 코드에는 저자를 표시하는 __author__ = 'Chetan' 이 포함됩니다.

Table of Contents

• 안티 패턴 개요
• 소프트웨어 개발 안티 패턴
• 소프트웨어 개발 안티 패턴의 예
• 소프트웨어 설계 안티 패턴
• 소프트웨어 설계 안티 패턴의 예

---

안티 패턴 개요

소프트웨어 디자인 원칙은 개발자가 설계 단계에서 지켜야 할 몇가지 원칙과 가이드라인을 제시한다. 로버트 마틴에 의하면 잘못된 설계에는 4가지 특성이 있다.

1. 유연하지 않다 -> 재사용이 어렵다.
2. 융통성이 없다 -> 간단한 수정도 여러 부분을 손봐야 한다.
3. 취약하다 -> 수정할수록 시스템이 취약해진다.
4. 점성이 높다 -> 설계상의 결함에 대한 수정이 어려워 겉돌게 한다.

안티 패턴이 생기는 원인

1. 개발자의 소프트웨어 개발 방식이 미숙하다.
2. 개발자가 상황에 맞지 않는 디자인 패턴을 사용한다.

안티 패턴을 방지했을 때 유용한 점

1. 소프트웨어 개발 단계에서 자주 발생하는 문제를 해결할 수 있다.
2. 문제를 찾아내는 툴을 개발해 원인을 분석할 수 있다.
3. 애플리케이션과 설계를 개선할 수 있는 다양한 방법을 찾을 수 있다.

---

소프트웨어 개발 안티 패턴

보통 애플리케이션이나 프로젝트 개발을 시작할 때 코드 구조부터 설계한다. 제품 설계와 디자인, 사용 패턴 등을 생각해 결정한다.
개발이 진행될수록 최초의 코드 구조에서 벗어나게 되는 원인은 다음과 같다.

1. 개발이 진행되면서 개발자의 사고력이 높아진다.
2. 고객의 피드백에 따라 사용 패턴이 바뀐다.
3. 기능 추가 및 확장성을 고려해 초기에 구성한 자료 구조가 수정된다.

위와 같은 이유로 리팩토링을 하게 된다. 리팩토링은 부정적인 의미로 받아들여 질 수 있지만 실제로는 자료 구조를 다시 살펴보고 확장성과 끊임없는 고객의 요구를 다시 생각해 볼 수 있는 소프트웨어 개발에 꼭 필요한 단계다.

---

소프트웨어 개발 안티 패턴의 예

스파게티 코드

가장 흔하게 접하는 안티 패턴이다. 코드가 뒤죽박죽 복잡하게 서로 엮여 있는 경우다. 소프트웨어를 충동적으로 개발하다 보면 자주 발생한다. 이런 스파게티 코드는 유지보수와 최적화가 어렵다.

스파게티 코드의 원인

1. 객체지향 프로그래밍 및 분석에 대한 이해 부족
2. 깊게 생각하지 않은 제품 설계 및 디자인
3. 대충 빨리 고치려는 성격

황금 망치

특정 솔루션이 다른 프로젝트에서 성공적이었다는 이유로 여러 곳에서 쓰이는 경우가 많다. 하지만 각 솔루션은 적합한 환경과 목적에서 사용해야 한다. 그럼에도 불구하고 개발자는 적합하지 않은 상황에도 한 번 사용해본 솔루션을 반복적으로 사용하는 경향이 있다. 어떤 못도 박을 수 있는 황금 망치다.

황금 망치의 원인

1. 주어진 문제와 환경에 대해서 잘 알지 못하는 외부인이 관여하는 경우
2. 전혀 다른 목적의 프로젝트에서 성공적으로 적용된 솔루션을 재사용하는 경우
3. 이전에 한 번 교육받은 솔루션을 지속적으로 사용하는 경우

황금 망치의 결과

1. 특정 솔루션이 모든 프로젝트에서 사용된다.
2. 소프트웨어가 제품의 기능이 아닌 개발에 사용된 기술 위주로 설명된다.
3. 개발자들이 “저 솔루션을 사용했어야 하는데.”라는 탄식을 자주한다.
4. 사용자의 요구가 충족되지 않는다.

용암류

프로그램이 망가질까 봐 두려워서 건드리지 못하는 죽은 코드나 쓸 수 없는 코드를 일컫는다. 용암이 굳어서 단단한 돌이 되듯이 이런 코드는 계속 프로그램 속에 남아 자리만 차지한다. 특정 목적에 맞춰 개발한 애플리케이션의 사용 용도가 변경되는 경우에 주로 생긴다.

용암류의 원인

1. 테스트 코드와 에러 코드가 지나치게 많은 경우
2. 리뷰 없이 단독적으로 코드를 작성하고 인수인계 없이 다른 팀에 넘기는 경우
3. 코드를 이해하는 사람이 아무도 없는 경우

용암류의 특징

1. 테스트 코드의 범위가 좁다.
2. 알 수 없는 주석된 코드가 많다.
3. 쓰이지 않는 인터페이스가 생기거나 기존 코드를 우회하는 방식으로 개발한다.

복사-붙여넣기 프로그래밍

가장 흔한 안티 패턴이다. 숙련된 개발자는 자주 발생하는 문제에 대한 해결책으로 자신의 코드를 온라인(StackOverflow, GitHub)에 올려둔다. 그리고 다른 개발자가 이 코드를 그대로 복사해 자신의 코드에 붙여 넣는다. 붙여 넣은 코드가 최적화 되었는지 또는 상황에 적합한지 생각하지 않아 결국 유지보수가 어려운 불규칙한 코드가 되어버린다.

복사-붙여넣기의 원인

1. 코딩 및 개발이 미숙한 초보 개발자인 경우
2. 빠르게 버그를 수정하고 넘어가야 하는 경우
3. 모듈 간의 표준화 또는 구조 단일화를 위한 코드 중복이 생길 때
4. 장기적인 사고의 부재

복사-붙여넣기의 결과

1. 유사한 문제가 애플리케이션의 여러 부분에서 발생한다.
2. 높은 유지보수 비용과 버그 발생률
3. 코드 중복으로 인해 모듈식 코드가 줄어든다.
4. 동일한 문제가 계속 발생한다.

---

소프트웨어 설계 안티 패턴

소프트웨어 설계는 전체 시스템 설계에서 가장 중요한 부분이다. 시스템 설계는 디자인과 툴, 하드웨어에 중점을 두지만 소프트웨어 설계는 개발 및 테스트 팀과 PM등의 관계자들이 함께 모델링한다. 기초 설계는 제품의 성공을 좌지우지한다.

---

소프트웨어 설계 안티 패턴의 예

시간 낭비

여기서 시간 낭비란 설계의 재사용을 의미한다. 예를 들어 설계 단계에서 해결한 문제와 비슷한 또 다른 문제가 발생한다면 앞서 해결한 방식 및 과정을 재사용해야 한다. 같은 문제를 또 분석하고 고민할 필요가 전혀 없다.

시간낭비의 원인

1. 문서 또는 설계 단계의 문제점 및 해결책 공유 부재
2. 집단 내 소통 부족
3. 처음부터 새롭게 개발하는 방식이 습관인 집단
4. 개발 프로세스 및 규칙이 없는 경우

시간낭비의 결과

1. 간단한 문제에 대한 쓸데없는 논의
2. 시간과 리소스 증가로 인한 예산 낭비와 늦춰지는 출시일
3. 한 제품에만 적용되는 폐쇄적인 설계와 노력의 중복, 부실한 위기관리

제품/기술 종속

개발사는 다른 벤더사가 제공하는 기술에 의존하는 경향이 있다. 특정 기술이 시스템에 종속되어 떼어낼 수가 없는 구조가 되어버린다.

제품/기술 종속의 원인

1. 벤더사와의 유착 관계 또는 사용 요금 할인
2. 기술 및 성능이 아닌 마케팅과 세일즈 관점에서 선택한 제품
3. 수익적으로 성공한 다른 프로젝트에 쓰인 제품을 목적 및 요구사항이 다른 상황에 그대로 접목하는 경우
4. 기술자나 개발자가 이미 익숙한 제품을 선택

제품/기술 종속의 결과

1. 제품의 출시 및 유지보수 주기를 벤더사의 제품의 출시 시기에 맞춘다.
2. 고객의 요구보다는 제품의 기술을 중심으로 개발한다.
3. 출시일이 불확실하고 고객의 기대치에 미치지 못한다.

다수 디자인

조직의 프로세스에 따라 여러 사람이 모여 함께 시스템을 설계하는 경우가 있다. 이런 경우 너무 다양한 의견이 나오거나 지식 및 경험이 부족한 기술자의 의견이 더해져 결과물이 복잡해지고 수준에 못 미치게 될 수 있다.

다수 디자인의 원인

1. 많은 관계자들의 의견을 수렴하는 분위기의 조직인 경우
2. 설계를 맡은 총책임자가 없는 경우
3. 고객의 요구가 아닌 마케터나 기술자의 의견이 우선시될 때

다수 디자인의 결과

1. 설계가 끝난 뒤에도 개발자와 설계자 사이에 의견이 갈린다.
2. 문서화하기 힘들 정도로 설계가 복잡해진다.
3. 수정사항이 여러 사람을 거쳐야 하고 개발 시간이 지연된다.