4장. 패턴 방지
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
엔지니어로서 솔루션을 제공해야 하는 마감 기한에 쫓기거나 코드 검토 없이 일련의 패치로 코드가 포함되는 상황에 직면할 수 있습니다. 이러한 경우 코드는 항상 신중하게 작성되지 않을 수 있으며 안티 패턴이라고 하는 것을 전파할 수 있습니다. 이 장에서는 안티 패턴이 무엇이며 왜 이를 이해하고 식별하는 것이 필수적인지 설명합니다. 또한JavaScript의 몇 가지 일반적인 안티 패턴을 살펴봅니다.
안티 패턴이란 무엇인가요?
패턴이 모범 사례를 나타내는 것이라면, 안티 패턴은 제안된 패턴이 잘못되었을 때 얻은 교훈을 나타냅니다. GoF의 저서인 디자인 패턴에서 영감을 받은 앤드류 코닉은 1995년 객체 지향 프로그래밍 저널 8권에서 안티 패턴이라는 용어를 처음 만들었습니다. 그는 안티 패턴을 다음과 같이 설명했습니다:
안티패턴은 패턴과 비슷하지만, 솔루션 대신 표면적으로는 솔루션처럼 보이지만 솔루션이 아닌 것을 제공한다는 점이 다릅니다.
그는 안티 패턴에 대한 두 가지 개념을 제시했습니다. 안티 패턴:
-
특정 문제에 대한 잘못된 해결책으로 인해 불리한 상황이 발생한 경우를 설명하세요.
-
상기 상황에서 벗어나 좋은 해결책으로가는 방법을 설명하십시오.
이 주제에 대해 Alexander는 좋은 디자인 구조와 좋은 컨텍스트 사이의 균형을 맞추는 데 따르는 어려움에 대해 설명합니다:
이 노트는 기능에 반응하여 새로운 물리적 질서, 조직, 형태를 나타내는 물리적 사물을 발명하는 과정인 디자인의 프로세스에 관한 것입니다. ... 모든 디자인 문제는 문제의 형태와 그 맥락이라는 두 가지 실체 사이의 적합성을 달성하려는 노력에서 시작됩니다. 형태는 문제에 대한 해결책이고 맥락은 문제를 정의합니다.
안티 패턴을 이해하는 것은 디자인 패턴을 아는 것만큼이나 중요합니다. 그 이유를 살펴보겠습니다. 애플리케이션을 만들 때 프로젝트의 라이프사이클은 구축과 함께 시작됩니다. 이 단계에서는 사용 가능한 좋은 디자인 패턴 중에서 적합하다고 생각되는 것을 선택할 가능성이 높습니다. 그러나 초기 릴리스 이후에는 유지 관리가 필요합니다.
이미 운영 중인 애플리케이션을 유지 관리하는 것은 특히 어려울 수 있습니다. 애플리케이션 작업을 해본 적이 없는 개발자는 실수로 잘못된 디자인을 프로젝트에 도입할 수 있습니다. 이러한 잘못된 관행이 이미 안티 패턴으로 식별된 경우 개발자는 이를 미리 인식하고 알려진 일반적인 실수를 피할 수 있습니다. 이는 디자인 패턴에 대한 지식이 있으면 알려진 유용한 표준 기술을 적용할 수 있는 영역을 인식할 수 있는 것과 유사합니다.
진화하는 솔루션의 품질은 팀의 기술 수준과 투자한 시간에 따라 좋을 수도 있고 나쁠 수도 있습니다. 여기서 좋은 것과 나쁜 것은 맥락에서 고려되며, '완벽한' 디자인도 잘못된 맥락에서 적용하면 안티 패턴으로 간주될 수 있습니다.
요약하자면, 안티 패턴은 문서화할 ...