프로그래밍 안티패턴 (Anti-pattern)

* 이 글은 작성자가 안티패턴을 접할 때 마다 추가될 예정입니다.

 

프로그래밍을 하면서 상황에 따라 자주 쓰이는 설계방법을 정리한 '디자인 패턴' 이라는 게 있다.

하지만 반대로 자주 사용되는 프로그래밍 패턴이지만, 잘 모르고 사용한다면 정말 커다란 장애를 만들 수 있는 패턴도 있는데 이를 프로그래밍의 안티패턴이라고 부른다.

 

안티패턴은 정말 여러가지 종류가 있지만, Java에서 대표적으로 많이 언급되는 몇가지를 소개하고자 한다.

 

# 한줄짜리 안티패턴

• if/ for/ while 문의 한줄 짜리 블럭을 생략하는 것은 좋지 않은 방법이다.
  (Java는 파이썬이 아니다. 이는 코드 구조를 애매하게 만들어 가독성과 디버깅을 어렵게 만든다.)
• 배열 순회시 array.length 같은 정보는 매번 호출하지말고 캐시하고 사용하자.
• if-else로 처리할 수 있는 간단한 로직을 예외로 처리하지 말자. 예외는 자주 발생하면 안된다.
• 싱글톤을 제공하는 객체는 무상태(Stateless)를 지향해야 한다. 상태를 가지면 심각한 장애를 만들 수 있다.
• 대부분의 경우 생성자와 초기화 작업은 따로 분리해서 관리하는 것이 유지보수에 좋다. (엄청 간단한 경우는 예외)

---

# 화물숭배 프로그래밍(Cargo cult)

프로그래밍 패턴에는 정말 여러가지가 있다. 팩토리, 전략, 싱글톤...

하지만 각각의 패턴이 왜 필요하고, 어떤 것을 주의해야하는지 모르고 무작정 숭배하듯이 패턴을 쓰는 것은 좋지않다는 말이다. 아무리 검증되고 좋은 설계라 할지라도 그것을 내 코드에 적용하기위해서는 그 설계의 필요성과 이해는 선택이 아닌 필수이다. 만약 비즈니스 요구사항이 복잡하지 않다면, 굳이 패턴이나 방법론을 적용시키는 거보다 그냥 코드를 만드는게 더 깔끔하고 성능이 좋을 수도 있다.

• 검증된 다른 프로그래밍 코드를 무작정 복사해올 때
• 디자인이 나오게된 이유와 원칙을 이해하지 않고 적용하려 했을 때
• 코드만 봐도 설명이 확실한데 굳이 거창한 주석을 추가하는 경우
• GC에 의해 자동으로 제거되는 객체를 굳이 삭제 메서드를 통해 삭제할 때

 

---

# 금도금 (Gold plating)

비즈니스적인 가치를 창출할 수 있는 일정 시점을 넘어서도 계속해서 리팩토링, 개발을 진행하는 것을 의미한다. 물론 좋은 설계와 더 나은 코드를 만드는 것은 좋은 일이지만 고객이 요청한 정도만 처리하고 다른 서비스 구현을 먼저하는 것이 우선이다. 필요 이상의 리팩토링은 중지해야한다. 

 

---

# 매직 넘버 (Magic Number)

마법의 숫자. 직접 숫자가 입력된 하드코딩 된 값이다.

• 의미를 가지고 있지만 설명되지 않은 상수로 있는 값 (Enum이나 메서드를 통해 의미를 전달 받아야 한다.)
• 다른 의미로 착각하면 안되는 값이, 충분히 착각하기 좋은 상태로 있을 때