안티패턴

안티패턴 소개

안티패턴은 패턴의 정반대입니다. 디자인 패턴은 좋은 프로그래밍 방식, 즉 특정 문제를 해결하기 위한 패턴의 예임을 상기하십시오. 그러나 반 패턴은 완전히 반대입니다. 즉, 다양한 문제를 해결할 때 저지르는 실수 패턴입니다.

좋은 프로그래밍 관행의 일부는 정확하게 안티 패턴을 피하는 것입니다. 이것이 이해할 수없는 이론적 쓰레기라고 생각하지 마십시오. 이것은 거의 모든 개발자가 직면 한 특정 문제입니다. 누가 알겠는가, 그는 무장하고 있다!

초보자들 사이에서 흔히 볼 수 있는 몇 가지 안티 패턴을 살펴보겠습니다.

• 매직 넘버와 문자열
• 갓 클래스
• 조기 최적화
• 자전거의 발명
• 외발 자전거의 발명

매직 넘버와 문자열

매직 넘버는 코드에서 무엇인가(대부분 데이터 식별)에 사용되는 상수로, 숫자 자체는 해당 주석 없이는 의미가 없습니다. 숫자에는 의미가 전혀 없습니다.

의미가 명확하지 않은 프로젝트 코드에 숫자가 나타나기 시작하면 이는 매우 나쁩니다. 그러한 코드의 작성자가 아닌 프로그래머는 그것이 어떻게 작동하는지 설명하기 어려울 것입니다. 시간이 지남에 따라 매직 넘버가 있는 코드 작성자도 설명할 수 없게 됩니다.

숫자는 코드를 이해하고 리팩토링하기 어렵게 만듭니다. 이 오류의 주요 원인은 개발의 서두름과 프로그래밍 연습 부족입니다. 이 반패턴은 개발을 시작하기 전에 숫자 상수의 사용을 규정함으로써 싹을 막아야 합니다.

이 문제를 해결하려면 숫자 상수의 목적을 설명하는 이름을 가진 변수를 만들고 원하는 값을 할당해야 합니다.

갓 클래스

신성한 객체는 OOP 개발자들 사이에서 꽤 흔한 안티 패턴입니다. 이러한 개체는 너무 많은 기능을 수행하거나 거의 모든 데이터를 저장합니다. 결과적으로 우리는 이해하기 어려운 이식 불가능한 코드를 갖게 되었습니다.

또한 전체 시스템이 거의 전적으로 코드에 의존하기 때문에 이러한 코드를 유지 관리하기가 매우 어렵습니다. 이 오류의 원인: 개발자의 무능력, 한 명의 개발자가 작업의 많은 부분을 담당(특히 작업량이 해당 개발자의 경험 수준을 초과하는 경우).

작업을 여러 개발자가 처리할 수 있는 하위 작업으로 나누어 이 접근 방식을 처리해야 합니다.

조기 최적화

조기 최적화는 프로그래머가 어디서 어떻게 수행할지에 대한 정보에 입각한 결정을 내리는 데 필요한 모든 정보를 갖기 전에 수행되는 최적화입니다.

실제로 병목 현상이 발생할 위치를 예측하기는 어렵습니다. 경험적 결과를 얻기 전에 최적화를 시도하면 코드가 복잡해지고 오류가 발생하지만 이점은 없습니다.

피하는 방법? 먼저 잘 알려지고 입증된 알고리즘과 도구를 사용하여 깨끗하고 읽기 쉽고 작동하는 코드를 작성합니다. 필요한 경우 프로파일링 도구를 사용하여 병목 현상을 찾습니다. 추측이나 가정이 아닌 측정에 의존하십시오.

예 및 기능

프로파일링 전 캐싱. 수학적으로 올바른 알고리즘 대신 복잡하고 입증되지 않은 휴리스틱을 사용합니다. 로드 시 오작동할 수 있는 테스트되지 않은 새로운 프레임워크 선택.

어려움이 무엇입니까

최적화가 시기상조인지 판단하는 것은 쉽지 않습니다. 미리 성장의 여지를 남겨두는 것이 중요합니다. 쉽게 최적화하고 확장할 수 있는 솔루션과 플랫폼을 선택해야 합니다. 또한 때로는 조기 최적화가 나쁜 코드에 대한 변명으로 사용됩니다. 예를 들어, 그들은 알고리즘이 O(n)이 더 어려울 것이기 때문에 O(n2) 알고리즘을 사용합니다.

자전거의 발명

이 안티 패턴의 의미는 프로그래머가 이미 존재하는 솔루션과 종종 훨씬 더 성공적인 문제에 대한 자체 솔루션을 개발한다는 것입니다.

개발자는 자신이 더 똑똑하다고 생각하므로 전임자의 경험에도 불구하고 각 작업에 대한 자신의 솔루션을 찾으려고 노력합니다. 대부분의 경우 이것은 시간 손실과 프로그래머의 효율성 감소로 이어집니다. 결국 솔루션이 발견되더라도 차선책일 가능성이 높습니다.

물론 독립적인 솔루션의 가능성을 완전히 버릴 수는 없습니다. 이는 직접적인 방식으로 복사-붙여넣기 프로그래밍으로 이어지기 때문입니다. 개발자는 기성 솔루션을 사용하거나 자신의 것을 발명하여 유능하게 해결하기 위해 앞에 나타날 수 있는 작업을 탐색해야 합니다.

매우 자주, 이 안티 패턴의 이유는 단순히 시간이 부족하기 때문입니다. 그리고 시간은 돈입니다.

사각바퀴 자전거의 발명

이 안티 패턴은 단순히 바퀴를 재발명하는 것과 매우 밀접하게 관련되어 있습니다. 즉, 더 나은 솔루션이 존재할 때 자신의 나쁜 솔루션을 만드는 것입니다.

이 반패턴은 두 배의 시간이 걸립니다. 먼저 자체 솔루션을 발명하고 구현하는 데 시간이 소요되고 그 다음에는 이를 리팩토링하거나 교체하는 데 시간이 걸립니다.

프로그래머는 특정 범위의 작업에 대한 다양한 솔루션의 존재를 인식하고 장점과 단점에 따라야 합니다.

프로그래머로서 직면하게 될 모든 문제는 두 부분으로 나눌 수 있습니다.

• 똑똑한 사람들이 30년 전에 이 문제를 해결했습니다.
• 똑똑한 사람들이 50년 전에 이 문제를 해결했습니다.

대부분의 프로그래밍 문제는 당신이 태어나기도 전에 성공적으로 해결 되었습니다 . 아무것도 발명 할 필요가 없습니다. 다른 사람들의 경험을 연구하십시오 (이것이 책이 쓰여진 이유입니다).

2022년에는 다음과 같은 생일을 축하할 수 있습니다.

• 프로그래밍 언어
  • C언어 50주년(1972년)
  • 자바 언어 탄생 27주년(1995년)
  • 파이썬이 31살이 됨(1991년)
• 연결
  • 인터넷이 39살이 되다(1983)
  • 49세가 된 휴대전화(1973년)
  • 최초의 SMS는 30년 전(1992년)에 발송되었습니다.
• 패턴
  • MVC 패턴이 44살이 됨(1978년)
  • SQL은 48년 전(1974년)에 발명되었습니다.
  • Java Beans는 26년 전(1996년)에 발명되었습니다.
• 도서관
  • 최대 절전 모드는 21년 전(2001년)에 발명되었습니다.
  • 스프링이 발명된지 20년전(2002년)
  • 23년 전(1999년) 출시된 Tomcat
• 운영체제
  • 유닉스는 51년 전(1971년)에 출시되었습니다.
  • Windows가 빛을 본 것은 37년 전(1985년)
  • 21년 전(2001년) 출시된 Mac OS

그리고 이 모든 것들은 단지 발명된 것이 아니라 그 당시 매우 일반적이고 관련된 문제에 대한 해결책으로 개발되었습니다.