안티팬이 아니라 안티 패턴이요?

안티 패턴이란 자주 사용되지만 실제로는 비효율적이거나 해로운 결과를

초래하는 반복적인 나쁜 해결책을 말한다.

코드 수준의 안티 패턴

- 무엇을 의미하는지 알 수 없는 숫자나 값을 직접 적어 하드 코딩했을 경우

- 비슷한 로직을 코드 여기저기에 복사 붙여 넣기 했을 경우

 

문제점

하드 코딩된 값을 수정해야 할 경우 같은 목적으로 사용된 모든 하드 코딩을 수정해줘야 하는 문제가 있다.

그리고 복사 붙여 넣기를 자주 사용할 경우 코드가 길어지고 원본 코드에 문제가 있을 경우

복사 붙여넣기한 모든 코드를 일일이 찾아서 수정해줘야 한다.

 

설계 수준의 안티 패턴

- 하나의 클래스가 너무 많은 책임과 역할을 가지고 있을 경우

- 내부 구현에  너무 깊이 의존하고 있을 경우

- 다른 클래스의 메서드를 호출하기 위해 필요한 클래스를 만드는 경우

 

문제점

하나의 클래스가 너무 많은 책임을 가지고 있으면 이 클래스의 책임이 무엇인지 판단하기 어렵고

사소한 기능을 수정하려 해도 이 거대한 클래스 내부를 수정하며 문제가 발생할 위험이 있다.

그리고 단순 다른 클래스의 메서드를 호출하기 위해 한번 사용하려고 만든 클래스는

클래스 수의 증가로 불필요한 관계 복잡도가 늘어난다.

프로세스 수준의 안티 패턴

- 특정 부분이 느릴 것 같다는 짐작만으로 성능 측정 없이 복잡한 알고리즘을 사용해

읽기 힘든 코드를 만들었을 경우

- 자신이 좋아하는 패턴이나 기술 하나만 가지고 모든 문제를 해결하려고 할 경우

 

문제점

기술을 보여주기 위해 무엇을 만들어야 하는지 까먹고 더 좋은 기술, 새로 배운 기술을

사용해 보려고 그 기술에 프로젝트를 맞춰버리게 되는 문제가 생긴다.

 

안티패턴을 인지하는 기준

그럼 내 코드에 안티 패턴이 있는지 어떻게 인지하나?

코드를 수정하거나 추가할 때 짜증 나거나 두렵거나 비효율적이라고 생각할 때 의심해봐야 한다.

이 지점에 안티 패턴이 존재할 확률이 높다.

 

사소한 수정을 하려는데 코드 여기저기를 뜯어고쳐야 한다면 의심해봐야 한다.

코드를 수정했더니 엉뚱한 곳에서 사이드 이펙트가 발생한다면 의심해봐야 한다.

기능을 추가할 때 기존에 코드까지 수정해야 한다면 의심해봐야 한다.

 

앞으로는 구현 단계에서 코드를 수정하기 겁나는지 스스로 질문해 보자.

수정하는 것이 부담스럽다면 안티 패턴이 있는지 찾아보고 어떻게 하면 부담을 줄일 수 있을지 생각하자.