디자인 패턴 Stifle Creativity

몇 년 전 저는 경제학 교수와 디자인 패턴, 프로그래머가 공통 언어를 설정하는 방법, 잘 알려진 문제를 어떻게 잘 해결했는지 등에 대해 이야기했습니다.

그리고 나서 그는 이것이 경제학 학생들에게 사용하는 것과 정반대의 접근법이라고 내게 말했습니다. 그는 일반적으로 문제를 제시하고 먼저 해결책을 찾도록 요청했습니다. 그래서 먼저 문제에 대해 생각하고 먼저 문제를 해결하는 방법을 찾도록 시도한 후에야 "고전적인"해결책을 제시했습니다.

그래서 "디자인 패턴"접근 방식이 실제로 프로그래머를 더 똑똑하거나 어리석게 만드는 것이라고 생각했습니다. 새롭고 혁신적인 방법.

어떻게 생각해?

경제학 교수는 절대적으로 정확합니다.

소프트웨어 디자인 패턴은 주로 숙련 된 소프트웨어 개발자 가 서로 통신 할 수 있는 방법입니다 . 알려진 문제에 대한 기존 솔루션의 약어입니다.

그러나 패턴없이 문제를 해결하는 방법을 이해하거나 비슷한 패턴을 스스로 찾은 사람들 만 사용해야합니다. 그렇지 않으면 복사 / 붙여 넣기 코더와 동일한 문제가 발생합니다. 코드가 있지만 작동 방식을 이해하지 못하므로 문제를 해결할 수 없습니다.

또한 많은 디자인 패턴은 엔터프라이즈 패턴으로, 대규모 회사 소프트웨어 시스템 에서 사용하기위한 패턴입니다 . Inversion of Control 컨테이너의 경이를 배우면 대부분의 프로그램이 실제로 필요하지는 않지만 작성하는 모든 프로그램에서 컨테이너를 사용하려고 할 것입니다 (작은 프로그램에 의존성을 주입하는 더 좋은 방법이 있습니다) IoC 컨테이너가 필요하지 않습니다).

패턴을 배우십시오. 패턴과 적절한 사용법을 이해하십시오. 패턴없이 동일한 문제를 해결하는 방법을 알아야합니다 (모든 소프트웨어 패턴은 기본 알고리즘에 대한 추상화입니다). 그러면 소프트웨어 패턴이 적절할 때 자신있게 소프트웨어 패턴을 사용할 수 있습니다.

사람들이 디자인 패턴을보고 싶어하는 방식은 비슷한 문제가 발생하는 경우 적용 할 수있는 일련의 솔루션입니다. 그들은 당신이 그들을 산 위에 돌판에 새겨진 모세에게 주신 유일한 해결책이라고 생각하기를 원하지 않습니다.

불행하게도, 어떤 사람들은 그것들을 배울 수있는 여러 가지 예시적인 디자인보다는 성서에 더 가까운 것으로 받아들입니다. 그것은 창의력을 죽이고화물 컬트를 설정합니다.

당신의 경제학 교수는 학생들에게 문제를 제시하고 그들이 먼저 해결하도록 노력하는 것을 언급했습니다. 이것은 훌륭한 교육 기법이지만, 그것을 보여줄 해결책이있었습니다. 당신의 머리에있는 많은 다른 문제들에 대한 많은 해결책을 갖는 것은 좋은 일이며, 그것은 Design Patterns가 시도하는 것입니다. 나는 그것이 어떤면에서 실패한다고 생각하지만 (Singleton은 나쁜 접근 방식, 명령 OO에 대한 근시 초점 등) 지능과 취향에 잘 사용될 수 있습니다. 그러나 소프트웨어의 모든 가능한 예제 솔루션은 반드시 공식적인 디자인 패턴이어야한다고 생각하는 것은 실수입니다.

문제를보고 "이것에 대한 디자인 패턴은 무엇입니까?"라고 스스로에게 물어 보면, 잘못하고있는 것입니다. 그리고 당신을 응시하는 해결책을 찾지 못할 것입니다.

문제를보고 "어떻게 해결할 수 있습니까?"라고 스스로에게 물어 보면 패턴이 아닌 솔루션이있는 경우이를 볼 수 있으며, 맞는 패턴이있는 경우에도 해당 패턴을 볼 수 있습니다.

또한 경제학 교수가 정확하다고 생각합니다. 이것이 처음부터 무엇이든 배울 수있는 방법입니다. 그러나 다음과 같이 봅시다 : 창의성을 위해 휠을 비밀로 유지하고 모두가 재창조하도록 하시겠습니까 ? 모든 사람들이 바퀴를 발명 할 수있는 것은 아니기 때문에 아니오라고 말할 것으로 기대합니다. 그렇다면 어느 시점에서 바퀴를 만들 것인지, 바퀴의 존재를 알고 있는지 여부는 중요하지 않습니다. 아니.

프로그래머에게 돌아가 봅시다. 나는 매일 웹 개발자이기 때문에 MVC는 내가 매일 상호 작용하는 것들 중 하나입니다. 여러 번 내 자신의 구조를 만들려고했지만 많은 것을 배웠지 만 기본적으로 모두 실패했습니다. 최선을 다했지만 MVC가 없으면 어떻게됩니까? 글쎄, 내 소스 코드는 신뢰성, 유지 보수성 및 확장 성 측면에서 짜증납니다.

나는 그것이 우리 대부분에게 동일하다고 생각합니다. 모범 사례로서 DI에 대해 아무도 말하지 않는다면 개발자가 교훈을 배울 때까지 얼마나 많은 엔터프라이즈 애플리케이션이 어려움을 겪거나 실패해야합니까?

두 번째 요점은 산업 표준 입니다. 웹 개발자에게 MVC를 가르치지 않으면 먼저 비표준 구조에 직면 할 준비가되었으므로 먼저 일을 수행하는 방법을 배우기 위해 시간을 소비해야합니다. 그런 다음 그 구조 중 일부는 좋은 아이디어를 가지고 있지만, 대부분은 소프트웨어 프로젝트에 심각한 결과를 초래할 수있는 심각한 디자인 결함이있을 수 있습니다. 잘 알려진 프레임 워크도 여전히 디자인 결함으로 인해 어려움을 겪고 있습니다.

그러나 우리가 멋진 아이디어를 모두 모아서 함께 모아서 똑똑한 개발자가 모든 실험에서 좋은 것을 취하고 특정 문제에 가장 적합한 정말 멋진 구조를 만들면 어떻게 될까요? 그런 다음 디자인 패턴을 만들었습니다 . 당신이 살아있는 생물이라면, 다른 방법은 없습니다. 동물조차도 일상 생활에서 모범 사례와 디자인 패턴을 따릅니다.

망치를 재발 명하지 말고 모든 문제를 못처럼 다루지는 마십시오.

프로그래밍 패턴은 즉시 사용할 수있는 솔루션을 제공하고 쉽게 문서화하고 쉽게 잊을 수있는 일반적인 사례로 테스트했기 때문에 시간을 절약 할 수 있습니다. 그러나 언제 사용해야하는지 배우고 생각해야합니다.

당신의 질문을 역설 : 운전을 배우는 것이 나를 더 빨리 움직이게합니까, 아니면 천천히 걷습니까?

프로그래밍 패턴을 사용하는 방법을 학습한다고해서 자체 솔루션을 찾는 연습을해서는 안된다는 의미는 아닙니다. 창의력을 발휘하기에는 여전히 충분한 문제가있을 것입니다. 프로그래밍 패턴을 아는 것은 잘 알려진 문제에 빠르게 대처하고 사소한 문제에 집중할 수있게합니다.

당신의 질문의 두 번째 부분으로 돌아 가기-당신의 교수가 맞습니까?

네, 그렇습니다 . 연구의 주요 목표는 학생들이 생각 하는 것을 배우는 것 입니다. 문제에 대한 자신의 솔루션을 찾은 다음 기존 솔루션과 직면해야합니다. 그런 식으로 만 그들은 정말로 그들을 이해할 수 있습니다. 패턴을 먼저 배우면, 그 뒤에 무엇이 있는지 이해하지 못하고 기계적으로 적용하는 것만 기계적으로 배울 위험이 있습니다.

이것이 학생들에게 처음으로 프로그램을 가르치는 이유이며, 패턴은 다음 학기에 소개됩니다.

디자인 패턴을 교육함으로써 프로그래밍 교육에 대해 절대적으로 조언합니다. 배후의 원리를 이해하지 않고는 제대로 적용 할 수 없으므로 해당 원리를 가르치는 것이 훨씬 중요합니다.

어쨌든 디자인 패턴이 실제로 프로그래머에게 가치있는 것은 아니라고 생각하는 경향이 있습니다. 주어진 디자인 패턴과 관련된 원칙을 완전히 이해한다면, 좋은 솔루션 인 상황에서는 당연히 알지 못하더라도 당연히 그 개념을 구성하는 경향이 있습니다. 그것은 이름을 가진 패턴이었다. 패턴을 배우는 데 시간이 오래 걸리면 일반적으로 코드에 대해 생각하는 방법을 배우는 것이 좋습니다. "일반적인 문제 해결"기술이 처음부터 다뤄지지 않은 경우, 패턴 세트를 얼마나 잘 적용하더라도 좋은 코드를 작성할 수 없습니다. "일반적인 문제 해결"기술이 우수하면 단일 패턴을 모르더라도 문제를 해결할 수 있습니다.

또한 이상적인 세계에 존재하지 않을 것이라고 생각 될 아이디어 일반적인만큼이 패턴이 모든 라이브러리에서 잘 구현 될 것이며, 우리가 실제로 할 것이라고 할 수 있기 때문에, 어떤 디자인 패턴 재사용 지속적으로 코드를 대신 재 작성 을. "정규 표현식 디자인 패턴"이 있다면, 사용할 때마다 작은 정규식 엔진을 구현해야한다고 상상해보십시오. 디자인 패턴은 언어가 올바른 추상화 기능을 제공하지 않기 때문에 작성할 수없는 라이브러리 일뿐입니다.

그것이 실제로 그들에 대해 크게 신경 쓰지 않는 또 다른 이유입니다. 그것들은 때때로 주장되는 것만 큼 보편적 인 곳은 아니지만, 실제로 특정 언어가 허용 / 장려하는 프로그램을 구성하는 특정 방법과 매우 밀접한 관련이 있습니다. Python으로 작성된 디자인 패턴 책은 Java 용으로 작성된 책과 완전히 다르며 Haskell과 같은 비 제한적 언어로 작성된 책과는 훨씬 다릅니다. 더 깊은 수준에서 이해하는 것이 더 좋으며, 익숙한 모든 언어로 디자인 패턴을 직접 발견 할 수 있습니다.

상업과 교육의 목표는 다릅니다. 학생들에게 디자인 패턴을 가르치고 있다면 같은 방식으로 접근 할 것입니다. 그러나 프로덕션 환경에서는 시간과 효율성이 가장 중요합니다.

또한, 교실 밖에서의 (매크로) 경제학은 다릅니다. 당신은 정부가 "누가! 이제 세금과 같은 방식으로 지루해하고 있으므로 이번에는 엉뚱한 무언가를 시도하자"고 말하는 것을 보십니까? 아니, 당신은 그런 야생 실험이 수리 이상의 경제를 산산조각 낼 수 있기 때문에 아닙니다. 대신, 이자율 상승, 세금 공고 발표 등과 같은 검증 된 접근 방식을 고수하는 경향이 있습니다. 즉, 디자인 패턴에 의존하고 있습니다.

대답은 물론입니다 : 예.

디자인 패턴은 작동 방식과 가치를 가져 오는 이유를 파악하는 데 시간이 걸리는 한 훌륭한 학습 도구입니다.

또한 항상 발생하는 문제에 대해 친숙한 솔루션을 제공하기 때문에 설계 프로세스를 빠르게 추적하여 생산성을 높일 수 있습니다.

그러나, 회로 설계가 너무 많이 단락되거나 사람들이 독단적으로 사용하여 사용에 대해 지나치게 정밀하게되면 반대의 효과가 있습니다.

디자인 패턴은 물론 창의성이 떨어집니다. 그게 전부입니다. 창의력은 희소 한 자원입니다. 창의성을 필요로하지 않는 문제로 낭비해서는 안됩니다. 이전에 수백 명의 개발자와 같은 방식으로 문제를 해결하면 훨씬 쉽고 빠르며 작동하기 쉽습니다. 작업을 수행하는 지루하고 흥미 진진한 코드가 실제로 좋습니다.