디자인 패턴이 눈에 띄는가?


135

저는 20 년 동안 사업을해온 수석 개발자 중 한 명과 토론을했습니다. 그는 온타리오에서 자신이 작성한 블로그로 유명합니다.

이상한 것은 그가 나에게 말한 것입니다. 그는 교과서에서 작성되었으므로 실제 세계를 설명하지 않기 때문에 악몽이되는 코드가 있다고 말했습니다. UI / 데이터베이스 / 데이터 레이어에 새 필드를 추가하는 데 2-3 시간이 걸리지 만 코드에서는 30 분이 걸립니다.

또 다른 문제는 대부분의 프로그래머가 디자인 패턴을 이해하지 못하고 유지 관리 측면에서 좋지 않기 때문에 디자인 패턴을 피한다는 것입니다.

캐나다의 대부분의 웹 개발자는 데이터 모델을 격리하지 않고 데이터 계층 클래스에서 상속받는 것을 선호한다는 생각도 있습니다. "모델이 데이터 계층과 분리되는 것이 업계 표준이 아닙니까?" 그는 때때로 말했다. 그러나 대부분의 사람들은 너무 많은 일을하기 때문에 그렇게하지 않는 것을 선호한다.

모범 사례를 사용하여 코딩하지 않는 이유는 유지 관리의 악몽이기 때문에 직원 중 일부가 자신을 이해하지 못하고 며칠 안에 새로운 기능이나 필드를 푸시 해야하는 경우 작업 속도가 느리기 때문입니다. 시각.

Stack Overflow는 대부분 사람들이 업계 표준을 따르도록 권장한다는 점을 고려하면 이와 같은 의견을 듣는 것은 매우 이상합니다. 우리가 며칠 만에 새로운 분야와 기능을 끊임없이 끌어 내야 만하는 문제가 충분히 유연한 패턴을 추론하는 것이 불가능합니까? 이것이 내가 이해하는 것의 요지 인 것 같습니다.

이 진술에서 무엇을 만드십니까?



67
개인적으로 난 아무것도 신경이 보통 "이 좋은 생각하지만 난 당신이 어쨌든하고 싶은 이유를 모르겠어요, 토론의 끝"을 의미하기 때문에 (정당화없이) "가장 좋은 방법"이라고 대해 참조 해요
리처드 설렘

34
업계 표준, 디자인 패턴 및 모범 사례는 "누군가가 자신의 상황에서 더 잘 작동하여 자신에게도 영향을 줄 것이라고 말한 것"에 대한 용어 일뿐입니다. 수석 개발자의 권리.
CptEric

86
이것은 애자일과 관련이 없습니다.
궤도에서 가벼움 경주

68
"상위 mvc 개발자" "디자인 패턴이 나쁘다"인지 부조화
Dan Pantry

답변:


239

이것들은 성공을 거둔 사람의 말이며, 자신이 이해하지 못하는 패턴 전문 용어로 무엇을해야하는지 말하는 사람들을 무시합니다.

디자인 패턴과 모범 사례는 동일하지 않습니다. 어떤 사람들은 자신을 생각하고 자신이하는 일을 알고있는 사람들을 몰아냅니다. 그들이하는 일에 대한 올바른 이름을 모르더라도.

디자인 패턴은 이름이 있기 전에 존재했습니다. 우리는 그들에게 이야기하기 쉽도록 이름을 지어주었습니다. 이름이있는 패턴은 좋은 것이 아닙니다. 그것을 인식 할 수 있게 만듭니다 .

이 녀석은 여러분 중 누구도 들어 본 적이없는 패턴을 사용했을 것입니다. 어떤 일이 어떻게되는지 그에게 이야기해야 할 때까지는 괜찮습니다. 그는 당신과 대화하는 법을 배워야하거나 당신과 대화하는 법을 배워야 할 것입니다. "옳은"사람과는 아무 상관이 없습니다.


12
요즘 대부분의 사람들이 "디자인 패턴"이라는 용어를 사용할 때 일반적으로 그들은 Gang of Four를 언급한다는 경고에 동의 합니다.
Robert Harvey

35
그렇습니다. 저는 영어를 사용하는 것을 좋아합니다. 왜 프랑스 사람들이 그것을 채택하는 데 너무 오래 걸 렸는지 모릅니다. 그들이 할 때까지 내가 계속 듣는이 메트릭 시스템에 대해 조금 배울 것입니다.
candied_orange

6
그가 이해하지 못하는 것이 아닐 수도 있고, 이해하는 것이 될 수도 있지만 모든 상황에 모든 것이 적용되는 것은 아님을 알고 있습니다.
whatsisname

148
"이름을 가진 패턴은 좋은 것이 아닙니다. 인식 할 수있는 것입니다." 오 세상에 이것이 내가 들어 본 문제의 가장 좋은 요약입니다 : D
궤도에서 가벼움

7
@JanDoggen 소프트웨어 개발에서 흔히 사용되는 패턴 (일부 디자인 관련 패턴)이기 때문에 (반) 패턴이라고합니다.
JAB

95

당신과 당신의 친구가 묘사하는 종류의 많은 디자인 패턴은 실제로 프로그래밍 언어의 결함에 대한 해결책입니다 . 보다 표현적인 프로그래밍 언어를 사용하면 이러한 디자인 패턴에 대한 필요성이 사라집니다.

가능한 많은 사용 시나리오를 충족시키기 위해서는 우수한 디자인 패턴이 필요하기 때문에 과도하게 엔지니어링되는 경향이 있습니다. 과도하게 엔지니어링 된 코드에는 비용이 발생합니다. 코드를 읽고, 수행하는 작업을 이해하고, 전체 소프트웨어 시스템의 맥락에서 작동하는 방식을 이해해야합니다. 결과적으로 다른 소프트웨어 개발 기술과 마찬가지로 기술 사용 비용과 비교하여 기술을 평가하고 이점이 비용을 초과하는지 결정해야합니다.

다른 모든 것들은 같고 코드는 적을수록 좋습니다. 나는 여러 프로젝트를 통해 문자 그대로 3-6 개의 홉을 만들어서 흥미로운 코드, 즉 실제로 오버 헤드를 추가하는 이외의 다른 것을 수행 하는 코드를 찾아야하는 계층 구조를 사용했습니다 .

잘 알려진 소프트웨어 패턴은 설계 전략을 전달할 수있는 공통 어휘를 제공합니다. 불행히도 많은 소프트웨어 개발자는 소프트웨어 패턴 어휘를 프로그래밍 문제에 적절히 적용 할만큼 충분히 이해하지 못합니다. 경험이 부족한 개발자는 이러한 패턴이 전문가 영역 내에있는 것으로 간주합니다. 그들은 전문가로 여겨지기를 원하므로 준비하기 전에 패턴을 너무 빨리 배우고 적용하려고합니다. 그들이 실제로해야하는 것은 프로그래밍의 기본 원리를 먼저 배우고 각 패턴이 스스로 해결하는 문제를 해결하는 것입니다. 이렇게하면 패턴을 올바르게 이해하고 적용 할 수있는 훨씬 나은 위치에있게됩니다.


19
글쎄, 그것은 당신이 당신의 질문에 묘사 한 것과는 다른 문제입니다. 내가 지금 일하는 상점은 민첩 할 수 있고 유지 관리가 쉬운 매우 깨끗하고 마른 코드를 가지고 있다는 살아있는 증거이지만 대부분의 Java 상점에서 볼 수있는 일반적인 기업, 다층 물건은 아니며 상당히 공정합니다. 접근 방식에서 "비표준". "엔터프라이즈"방식으로 앱을 구축 할 년이 없습니다.
Robert Harvey

34
@ Igneous01 : 실제 경험이 없었던 교수가 "좋은"것으로 간주하는 것은 돈을 벌려고하는 기업이 "좋은"것으로 간주하는 것과 근본적으로 다를 수 있습니다.
Robert Harvey

8
"안타깝게도 많은 소프트웨어 개발자는 소프트웨어 패턴 어휘를 프로그래밍 문제에 적절하게 적용 할만큼 충분히 이해하지 못합니다." 이것은 요컨대. =) 내가 이름을 본 적은, 나는 그들의 실제 구현을 발견하는 것은 매우 어려운 시간이 있습니다. 필자가 작성 한 코드 블록을 가지고 패턴을 구현하는 것으로 분류 될 수 있지만 어떤 패턴을 말할 수는 없었습니다. 패턴이 실제로 해독 가능한 코드보다 훨씬 덜 중요하며 요구 사항 변경은 일부 코드 위치에만 영향을 미칩니다.
jpmc26

35
나는 그것이 brainfuck 처럼 보이는 코드로 이어지기 때문에 "낮은 코드가 항상 더 낫다"라는 문제에 대해 문제를 제기 할 것이지만 , 나는 "패턴 어휘"요점에 열성적으로 동의 할 것이다. 교과서에서 코드를 찾을 수 없기 때문에 내 코드가 잘못되었다고 불평하지 마십시오. 내 코드를 헛소리라고 부르는 데는 충분한 이유가 많이 있지만 그중 하나가 아닙니다.
candied_orange

23
"실제로 오버 헤드를 추가하는 것 이외의 것을 달성하는 코드"– 엔터프라이즈 소프트웨어의 목표는 실제로 어떤 것도 달성하는 코드가 없어야 한다는 생각이었습니다 . 소프트웨어가 가질 수있는 실제 동작은 계층화 된 디자인의 새로운 속성이거나 코드가 데이터로 취급하는 비즈니스 규칙에서 테이블 중심이어야합니다. 나는 단지 50 % 농담입니다.
Steve Jessop

86

Stackoverflow.SE와 Programmers.SE는 대부분 업계 표준이 아닌 SOLID와 같은 모범 사례 를 따르도록 권장 합니다 . 그리고 믿거 나 말거나, 사실상의 업계 표준은 종종 "진흙의 큰 공" 아키텍처입니다.

그러나 귀하의 질문에 직접 대답하기 위해 : 디자인 패턴의 문제는 상속의 경우와 유사합니다. 많은 평범한 개발자가이를 과도하게 사용하여 과도하게 엔지니어링되고 유지하기 어려운 코드를 생성 할 위험이 있습니다. 그러나 이것에 대한 대답은 디자인 패턴 (또는 상속)의 사용을 완전히 피하거나 금지하는 것이 아니며, 대답은 의미가있는 상황에서만 이러한 도구를 사용하는 법을 배우는 것입니다. 그리고 이것은 "민첩한"작업과는 완전히 독립적입니다.


나는 당신의 진술의 특이성 "디자인 패턴의 문제는 상속과 비슷한 문제입니다. 종종 그것을 오용하고 차선책을 작성합니다. 이것은 일반적으로 개발의 공리로 간주 될 수 있습니다.
Jeremy Holovacs

1
@ JeeremyHolovacs : 정확하지 않습니다. 내가 본 문제는 교육받은 개발자조차도 그들을 과도하게 사용한다는 것입니다. 숙련 된 개발자가 문제를 "어떻게"맞는 패턴으로 바꾸려고 시도했지만 해결책이 자주없는 솔루션을 너무 자주 보았습니다.
Doc Brown

45
  1. 디자인 패턴은 아이디어를 전달하는 데 사용되는 이름 일뿐입니다. 나는 종종 나 자신이 이름을 가진 것들을하는 것을 발견했다. 따라서, "비 디자인 패턴 방식"과 달리 "디자인 패턴 방식"은 없다.

  2. 디자인 패턴은 지침입니다. 모든 것과 마찬가지로 각각의 장단점이 있습니다. 핵심은 패턴을 배우고 그것이 맞는 곳에 적용하는 것이 아니라 패턴의 아이디어, 장점과 단점을 이해하고 문제 해결에 영감을주기 위해 사용하는 것입니다.

  3. 충분한 이유가있는 경우 모든 모범 사례 및 지침을 무시할 수 있습니다. 유효한 이유에는 개발 시간과 응용 프로그램의 기대치가 포함됩니다. 예를 들어, 값을 하드 코딩하는 것은 좋지 않지만 (어리석은 예) 개념 증명의 경우 이점이 비용보다 중요 할 수 있습니다 (이 경우 대부분 개발 시간). 그러나 이와 같은 결정이 내려지면 역효과가 발생할 수 있으며 어느 시점에서 리팩토링이 필요할 수 있습니다.


5
RE : 1 번입니다. 템플릿 패턴을 발명했습니다. 난 그냥 먼저하지 않았다. 또는 먼저 같은 것.
Opiner Grimm

29

수프에 또 다른 비유를 추가하기 위해 디자인 패턴은 Microsoft Office 도우미 인 Clippy입니다. "당신은 많은 것들에 대해 똑같은 일을하고있는 것 같습니다. 반복 자나 방문자를 제공함으로써 당신을 도울 수 있습니까?"

이러한 패턴을 잘 작성하면 이전에 여러 번 수행했던 것과 같은 방식으로 유용한 것이 언제 유용한 지, 처음 시도 할 때의 실수 및 이러한 실수를 피하기 위해 발견 된 일반적인 방법을 알 수 있습니다 . 따라서 디자인 패턴을 읽거나 메모리에서 검토 한 다음 작업을 시작합니다. 당신이 할 수없는 것은 Clippy와 마법사 사용하는 것입니다.

경험이없는 사람들이 실수를하고 현실을 고려하지 않는 코드를 작성할 수있는 곳은 디자인 패턴 목록이 소프트웨어의 문제를 해결하기위한 모든 가능한 접근 방식의 완전한 목록이라고 생각하고 디자인을 연결하여 코드를 디자인하려고하는 경우입니다 끝날 때까지 패턴. 야생에서 관찰 된 또 다른 열악한 전술은 디자인 패턴이 "모범 사례"라는 사실에 근거하여 디자인 패턴을 실제로 적합하지 않은 상황으로 끌어 올리는 것입니다. 아니요, 실제로 해결되는 문제 클래스에 대해서는 모범 사례 일 수도 있고 아닐 수도 있지만, 해결 하지 못한 문제 또는 더 간단한 솔루션이있을 때 불필요한 복잡성을 도입하여 해결해야하는 문제에 대해서는 최상의 사례가 아닙니다. .

물론 누군가가 YAGNI를 기반으로 패턴을 피할 수 있으며, 그것이 필요하다는 것을 깨닫고 정상적인 솔루션을 향해 모색하는 것이 가능합니다. 이는 일반적으로 처음부터 요구 사항을 실현하는 것보다 항상 나쁜 것은 아니며, 민첩한 개발에서도 완전히 예측 가능한 요구 사항이 조기에 발견되지 않으면 실망스러운 이유입니다. Java가 처음에는 일반 컨테이너를 불필요하게 복잡한 것으로 거부 한 다음 나중에 다시 볼트로 고정한다는 것을 매우 기쁘게 생각한 유일한 C ++ 프로그래머가 될 수 없었습니다.

따라서 디자인 패턴을 피하는 것을 선호하기 때문에 원칙적 으로 Iterator 작성하지 않는 것은 거의 실수 입니다.

UI / 데이터베이스 / 데이터 레이어에 새 필드를 추가하는 데 2 ​​~ 3 시간이 걸리며 코드에서 30 분이 걸립니다.

당신은 그것에 대해 실제로 논쟁 할 수 없습니다 :이 측정 항목에 의해 그의 디자인은 다른 것보다 훨씬 좋습니다. 그가 디자인 패턴을 피 했는지 여부 는 의심의 여지가 있지만, 디자인 할 때 올바른 "실제"문제를 고려했을 가능성이 높으며 경험상의 이점이 있으면 교과서만으로 무장 한 사람보다 자신의 직업에서 더 낫습니다. 높은 이상.

따라서 코드에서 필드를 추가하기 위해 여러 지점을 터치해야하는 패턴은 "필드를 쉽게 추가 할 수 있도록"하는 작업에 나쁜 패턴이며 이러한 패턴을 사용하지 않았다는 것을 인식했습니다. 계층 적 아키텍처는 실제로 그런 점에서 어려움을 겪을 수 있으며, 단점을 인식하지 않고 디자인 패턴을 사용하는 것은 잘못입니다.

이에 반해 디자인에 새 UI를 작성하는 데 시간이 얼마나 걸리고 계층 구조에서 시간이 얼마나 걸립니까? 프로젝트가 필드를 지속적으로 추가하는 대신 고정 된 데이터 모델을 통해 새로운 UI를 지속적으로 구축하고 배포하도록 요구했다면, 대신 그를 위해 설계했을 것입니다. 또는 또한. 그러나 "애자일을하고있다"고 슬프게도 다른 이점을 얻지 않아도된다는 의미는 아닙니다!

디자인 패턴 메뉴에서 선택하면 가장 중요한 문제에 대한 생각을 멈출 수 있습니다. 그러나 방문자를 작성할 때 인식하고 독자가 신속하게 정보를 얻는 데 도움이되도록 "방문자"를 문서화하거나 명명하는 것은 아무 것도 방해가되지 않습니다. "이것은 방문자는"작성 하는 대신 제대로 문서화하면 수석 디바이스가 제공하는 이유 끔찍한 실수입니다 - 프로그래머가 이해되지 않습니다. 방문자가 무엇인지 아는 프로그래머조차도 "이것은 방문자입니다"보다 더 많은 정보가 필요합니다.


5
"디자인 패턴은 Microsoft Office 도우미 Clippy입니다"오늘 밤 악몽을 겪을 것입니다.
MetalMikester

"경험이없는 사람들이 잘못 될 수있는 곳은 [디자인 패턴이 끝날 때까지 디자인 패턴을 연결하여 코드를 디자인하려고 할 때입니다." 들려 나는 여러 개의 공감대를 주었으면 좋겠다. :)
Quuxplusone

또한 마지막 단락에 대해 여러 개의 투표를했으면 좋겠습니다. 디자인 패턴은있는 어휘 프로그래밍 : 당신이 더 나은 수 있습니다 선명 당신은 큰 어휘가 있다면 작가. 나는 그들이 볼 때 빌더 에게 팩토리 를 말할 수 있지만, 디자인 패턴에 관한 책을 읽음으로써 그것을 얻지 못했습니다 . 영어 사전을 읽음으로써 허풍 에서 울음 을 말하는 법을 배웠습니다 .
Quuxplusone

20

동료가 NIH 증후군 ( "발명되지 않음") 으로 고통 받고있는 것 같습니다 .

그의 코드로 인해 새로운 필드를 쉽게 추가 할 수 있다는 것은 완벽하게 그럴듯합니다. 다른 사람이 작성한 코드보다 내 코드를 업데이트하는 것이 훨씬 빠릅니다. 그러나이 단기 속도는 코드의 유지 관리 성과 이식성에 대해 아무 것도 말하지 않습니다. 나는 그에게 의심의 이익을 줄 것이다. 기존의 코드가 교과서를 잘못 따르거나 잘못된 맥락에서 좋은 레시피를 따랐다면 실제로 구조가 잘못되었을 수있다.

디자인 패턴을 피하는 것은 정말 놀라운 일입니다. 지난 30 년간 코더를 코딩하고 관리하는 데있어 디자인 패턴은 본능적으로 수행 된 것에 대해 단어를 넣는 데 도움이되었으며, 의도, 장점, 불편, 위험, 기회 및 관련 패턴을보다 신속하게 이해하는 데 도움이되었습니다. 디자인 패턴은 복잡한 마스터 링을위한 진정한 가속기임이 입증되었습니다!

  • 아마도 당신의 동료는 우리 대부분보다 훨씬 더 지능적이며 눈에 띄는 생산성 저하없이 패턴을 재발 명하는 오버 헤드를 감당할 수 있습니까?

  • "프로그래머가 디자인 패턴을 이해하지 못한다"는 주장은 "내가하는 일을 실제로 설명 할 수 없다"는 것처럼 들린다. 또는 "내 자신의 디자인에 대해 논쟁하고 싶지 않다". 패턴 화는 전체적인 이해를 활용할 수 있으며, 선임 동료가 덜 소중한 의견을 공유 할 수 있다고 생각합니다. 그러나 어쩌면 당신의 선임 동료는 그것을 피하고 싶어 할 것입니다.

계층화 된 접근 방식은 대부분의 엔터프라이즈 응용 프로그램에서 다른 아키텍처보다 우수한 것으로 입증되었습니다. 세계적인 수준의 패키지는이 아이디어를 중심으로 구성되며 장인 아키텍처보다 성능이 뛰어납니다. Martin Fowler는 "엔터프라이즈 아키텍처 패턴"에 대한 그의 훌륭한 저서 에서이 접근 방식제시합니다 . 오! 다시 한 번 죄송합니다. 입증 된 패턴에 관한 것입니다. 동료의 NIH 관점에서 기회가 없다 ;-)


흥미로운 NIH 증후군은 전에는 들어 본 적이 없습니다. 아마도 그것은 대부분의 북미 고용주가 직원 관리 방법에 직면하고있는 문제입니다!
지불

@pay 이것이 북미 지역으로 제한되어 있는지 확실하지 않습니다 ;-) 과거에 우리가 이미 어떤 성공을 거두어 왔던 솔루션을 원합니다. 편안한 구역입니다. 그러나 도전적인 동료들과 항상 새로운 아이디어와 건설적인 대화에 항상 열려 있어야합니다. 결국, " 당신은 더 빨리 혼자 여행하지만 더 멀리 여행합니다. "
Christophe

16

많은 사람들이 놓친 핵심 통찰력은 소프트웨어 디자인이 맥락 적이라는 것입니다. 비즈니스 목표를 달성하기 위해 존재하며 다른 목표에는 다른 접근 방식이 필요할 수 있습니다. 다르게 말하면, 항상 최고의 디자인이 있지만 항상 최고의 디자인은 없습니다.

디자인 패턴은 표준 문제에 대한 표준 솔루션입니다. 그러나 문제가 없으면 해결하는 데 많은 노력이 필요합니다.

폭포와 애자일 소프트웨어 디자인의 주요 차이점은 디자인 결정이 이루어집니다. Waterfall에서는 모든 요구 사항을 수집하고 필요한 디자인 패턴을 식별 한 다음 코딩을 시작합니다. 민첩한 아키텍처에서 우리는 YAGNI 원칙에 따라 가능한 한 선택에 대해 많은 것을 알고있을 때 책임있는 마지막 순간까지 설계 결정을 연기합니다.

즉, 폭포에서 디자인 패턴 은 실제로 필요할 때 민첩 하게 요구가 예상 되는 경우에 적용되는 경향이 있습니다 . 결과적으로, 민첩한 프로젝트는 예상되는 모든 요구가 실제가 아니기 때문에 설계 패턴을 덜 자주 적용하는 경향이 있습니다.


1
일에 대한 Design patterns are standard solutions to standard problems. 나는 좀 더 찬란한 답변으로 그것을 보지 못해서 약간 실망했다. 따라서 문제가 발생하는 문제가 표준 문제와 일치하는지 확인해야하며 실제로 문제가 발생할 수도 있습니다.
Walfrat

8

디자인 패턴은 무엇을해야하는지 규정하기 때문에 실제로 디자인 패턴이라고하는 것은 아닙니다. 디자인 패턴은 이전에 수행 된 작업설명 하기 때문에 디자인 패턴 입니다. 일부 개발자는 특정 작업을 잘 수행하는 방법을 설계했으며 유사한 결과를 비슷한 상황에 적용 할 수있었습니다. 그게 다야. 많은 패턴에는 고유의 강점과 약점이 있으며, 적용 할 적절한 패턴을 결정하기 위해 기술 및 비즈니스 요구를 평가하는 것은 교육을받은 개발자의 몫입니다.

이러한 관점에서, 100 % 일회성 코드 작성에 전념하지 않는 한, 어떤 유스 케이스에서 다음 유스 케이스까지 개념이나 구현을 사용할 수없는 경우, 최소한 일부 디자인 패턴을 사용하고있을 것입니다. "리포지토리"또는 "작업 단위"또는 "MVC"와 같이 화려하고 일반적인 이름은 없지만 "디자인 패턴"이 아닙니다.


6

나는 보통 GPS를 이용한 "탐색"의 방식으로 생각하고 싶습니다. '모범 사례'및 '디자인 패턴'을 학습 할 때 GPS 탐색 경로를 사용하는 방법을 배웁니다. 그러나 그 지역을 알면 길가를 운전하면 과거의 문제 지역을 이끌고 더 빠르고 더 나은 곳으로 갈 수 있다는 것을 종종 알게 될 것입니다. 이러한 일에 관해서도 마찬가지입니다. 경험을 통해 툴박스를 해체하고 바로 가기를 할 수 있습니다.

학습 설계 패턴과 "모범 사례"학습은 주어진 상황에서 선택할 수 있도록 배후에있는 아이디어에 대한 이해를 얻는 것을 의미합니다. 실제 상황은 이론적 인 상황에 비해 종종 더 복잡하기 때문에 종종 교과서에는없는 제약과 문제가 있습니다. 고객 / 고객은 빠르고 저렴한 제품을 원합니다. 레거시 코드로 작업해야합니다. 블랙 박스이고 효과가없는 타사 도구와 상호 작용해야합니다. 그리고 모든 종류의 것들. 상황이 구체적입니다-모범 사례와 패턴이 더 일반적입니다.

SE와 같은 사이트의 많은 사람들이 '모범 사례'답변과 '디자인 패턴'답변을 제공하는 주요 이유 중 하나는 일반적인 솔루션과 추상적 솔루션으로 답변하기 때문에 일반적인 유형의 언어를 제공하는 데 도움이되기 때문입니다. 문제. 그리고 당신이 배울 수 있습니다.

따라서 애자일 개발 환경에서는 디자인 패턴이 눈에 띄지 않습니다. 그러나 개발은 패턴에 완벽하게 맞을 정도로 일반적이고 추상적이지 않으며 (경험있는) 개발자는 이것을 알고 있습니다.


5

UI / 데이터베이스 / 데이터 레이어에 새 필드를 추가하는 데 2 ​​~ 3 시간이 걸리며 코드에서 30 분이 걸립니다.

디자인을 "최적화"하려면 최적화하려는 것을 말해야합니다.

예를 들어, 경주 용 자전거는 최적화 된 차량이며 Boeing 747은 최적화 된 차량이지만 다른 요구 사항에 맞게 최적화되었습니다.

예를 들어, "MVC"패턴의 아이디어는 다음과 같은 것들을 최적화합니다.

  • 동일한 모델의 다른보기 (보기는 모델과 무관)
  • 각 계층은 통합 전에 개별적으로 (예 : 다른 팀에 의해) 개발하고 개별적으로 테스트 (단위 테스트) 할 수 있습니다.
  • 기타

그의 코드가 다른 것을 위해 최적화하는 반면, 예를 들면 다음과 같습니다.

  • 최소 코드 줄
  • 한 사람이 모든 레이어에 영향을주는 변경을 쉽게 수행 할 수 있습니다 (실제로 별개의 레이어를 가지지 않음)
  • 기타

패턴 설명은 패턴이 해결하려는 문제에 대한 설명으로 시작합니다. 그는 특정 패턴을 사용하지 않는 것이 "모범 사례"라고 생각한다면 (어쩌면 유용한 패턴이라고 가정하고 어리석은 패턴이 아니라고 가정) 패턴이 주장하는 특정 문제가 없거나 경험이 있다고 가정합니다. 해결하기 위해, 그리고 / 또는 그는 대신 최적화하려고하는 다른 (더 큰 또는 더 시급하고 경쟁적인) 문제가 있습니다.


"실제로 별개의 층을 갖지 않음"또는 공정을 위해 층을 통해 전파되는 수용 가능한 "기본 행동"을 갖는 것. 예를 들어, 웹 기반 SQL 관리 앱은 데이터베이스 계층이 변경 될 때 자동으로 업데이트되는 프리젠 테이션 계층입니다. 단지 제한된 용도 이외의 용도로 사용자가 원하는 방식으로 데이터를 실제로 제공하지는 않습니다 .-) 30 분 동안 새로운 필드를 추가하는 것이 엄청나게 빠르므로 디자인 할 UI가 중요하지 않습니다. 새 필드와의 연결, 계층화 또는 기타.
Steve Jessop

4

디자인 패턴은 도구입니다. 도구와 마찬가지로 도구를 사용하는 두 가지 방법이 있습니다. 올바른 방법과 잘못된 방법입니다. 내가 당신에게 드라이버와 못을,주고 함께 나무의 두 조각을 가입하도록 요구하는 경우 예를 들어, 당신은 해야 망치을 올려주세요. 손톱에는 망치가 사용되며 나사에는 나사가 사용됩니다.

너무 자주, 디자인 패턴은 하나의 진정한 방법으로 광고되며, 특정 문제가 발생할 때만 사실입니다. 주니어 개발자는 새로운 것을 가지고 놀 때 종종 아이들과 같습니다. 그들은 그 디자인 패턴을 모든 것에 적용하려고합니다 . 그리고 패턴 A가 문제 B에 적용되고 패턴 C가 문제 D에 적용된다는 것을 배우는 한, 본질적으로 잘못된 것은 없습니다. 손톱을 박는 데 드라이버를 사용하지 않는 것처럼, 당신은 손톱을 운전하지 않습니다. 존재하기 때문에 패턴; 패턴은 작업에 가장 적합한 도구로 사용됩니다.

패턴의 반대쪽은 안티 패턴입니다. 일반적으로 실행 시간 또는 메모리 측면에서 시간이 지나고 나쁘다는 것이 입증 된 것. 그러나 패턴과 반 패턴은 모두 존재 하는지 이해하지 못하는 개발자에게는 좋지 않습니다. 개발자는 자신이하는 일이 새롭고 독창적이라고 생각하지만 대부분은 그렇지 않습니다. 이전에 생각한 것 같습니다. 그들 앞에있는 사람들은 경험 때문에 패턴을 만들었습니다.

물론, 주니어 개발자는 종종 새로운 방식으로 오래된 일을하는 것처럼 보이며 때로는 그러한 방식이 더 좋습니다. 그러나 너무 자주 Dunning-Kruger 효과가 발생합니다. 개발자는 기능적 프로그램을 만들기에 충분하다는 것을 알고 있지만 자신의 한계를 이해하지 못합니다. 이를 극복 할 수있는 유일한 방법은 긍정적이고 부정적인 경험을 통한 것 같습니다. 그들은 자신이 우수하다고 생각하기 때문에 패턴을 무시하지만 실제로 10,000 명의 개발자가 이미 특정 디자인을 사용한 다음 실제로 나쁘기 때문에 버렸다는 것을 모릅니다.

애자일은 진화하는 고객 요구에 신속하게 적응하는 것과 관련하여 "응답 적으로 작업 수행"을 선호합니다. 디자인 패턴을 선호하거나 멸시하지 않습니다. 패턴이 가장 빠르고 가장 안정적인 방법 인 경우 개발자는이를 사용해야합니다. 특정 패턴이 단순히 "완료"하는 것보다 더 많은 시간이 소요된다면 패턴이 아닌 것을 사용하는 것이 좋습니다 (물론 성능이 심각하게 저하되지 않는다고 가정). 알려진 패턴을 찾을 수 없으면 클라이언트에게 "아니오"라고 말하는 것보다 고유 한 패턴을 설계하는 것이 좋습니다. 클라이언트, 특히 지불하는 클라이언트는 일반적으로 옳습니다.

패턴이 길이라고 주장하거나 패턴이 존재의 독이라고 주장하는 사람은 모두 잘못입니다. 패턴은 특정 상황에 적용하기위한 도구이며 상황에 따라 다양한 수준의 성공을 거두고 있습니다. 이것은 진실이며, MVC를 선택했는지 여부, 데이터 전송 객체 사용 여부 등에 의존하지 않는 것입니다. 중요한 것은 코드를 합리적으로 짧은 시간 내에 구현하는 것입니다. 논리적 인 버그가 없다.

일반적 으로 패턴은 일관된 형태의 디자인을 허용하며 100 % 독창적 인 아이디어를 작성하기 위해 모든 패턴을 무시하는 것보다 성능이 우수하지만 모든 패턴을 피할 수는 없습니다. 예를 들어, y = x + 5 인 경우, 실제로 x + 5를 쓰는 패턴을 피하기 위해 y = x + (5 * 3 + 15/3) / 4를 쓰시겠습니까? 아뇨 y = x + 5를 작성하고 다음 문제로 넘어갑니다.

사람들은 매일 패턴을 사용 하지만 괜찮습니다 . 가장 중요한 것은 논리적으로 작동하고 거의 충돌하지 않으며 사용하기 쉬운 코드를 사용하는 것입니다. 그 이상은 중요하지 않습니다.


이것에 대한주의는 문제와 도메인에 대한 '현재'의 이해에 따라 새로운 클래스를 만들거나 상황에 적용되는 패턴을 따를 수 있지만 다음 날 고객이 당신을 원한다고 생각합니다. 다른 클라이언트가 자신의 버전에서 원하지 않는 작은 패싯에 맞게 사용자 정의하십시오. 24 명의 고객의 요구에 부응하고 복사 파스타를 피하는 코드베이스를 통합하는 것은 불가능한 것 같습니다. 나는 오래된 편지 병합 프로세스를 리팩토링 할 때 오늘 이것에 부딪쳤다.
Igneous01

2

시스템의 두 부분을 같은 방식으로 디자인하지 않는 것 외에는 '디자인 패턴을 피할 수 없습니다'(권장하지 않으며 수석 개발자가하고있는 것을 의심합니다). 그가 의미하는 바는 '디자인 패턴을 고수하기 때문에 디자인을 맹목적으로 사용하지 않는 것'입니다. 당신이하고있는 것에 대해 생각하는 것은 분명히 '모범 사례'이며, 한 대학 은 존재 해야 합니다. 슬프게도, 그런 일은 일어나지 않는 것 같습니다.


2

디자인 패턴은 민첩한 관행에 반 추론이 아닙니다. 민첩한 관행에 반추 론적 인 것은 디자인 패턴을 사용하기 위해 디자인 패턴을 사용하는 것인데, 신입생과 학생들 사이의 공통 관행은 "공장 패턴을 사용하여이 문제를 어떻게 해결할 것인가"라는 선을 따라 생각하는 것입니다.

민첩성은 선택한 도구에 맞게 작업을 구성하지 않고 작업에 가장 적합한 도구를 선택하는 것을 의미합니다.
그리고 tbh는 모든 상식 개발 관행으로 귀결됩니다 (물론 선택할 수있는 도구 선택은 일반적으로 회사 표준, 라이센스 제한 (GPL 및 때로는 다른 오픈 소스 도구와 같은)에 의해 제한되기 때문에 타협해야합니다. 특히 재판매 용 소프트웨어를 구축 할 때는 사용할 수 없습니다.)

동료 / 친구는 아마도 디자인 패턴 자체를 사용하기 때문이 아니라 다른 디자인이 더 좋았을 때 특정 패턴의 사용을 보여주기 위해 설계된 인공 구조이기 때문에 아마도 코드에 반대했을 것입니다 (주관적이지만 주관적이지만 많은 사람들이 의심의 여지없이)) 특정 디자인 패턴을 강제로 사용하면 추악하고 유지하기가 어렵고 비효율적 인 코드로 이어진 많은 예를 보았습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.