선임 개발자가 OOP 디자인 패턴이 무엇인지 알기를 기대하는 것이 합리적입니까? [닫은]

선임 개발 직책에 대한 면접 질문을 준비 중입니다. 작업에는 객체 지향 디자인이 포함되며 기존 소프트웨어는 디자인 패턴을 사용하므로 응시자에게 몇 가지 디자인 패턴, 사용 방법, 사용 방법, 이유를 설명하도록 요청하고 싶습니다. 그들 등을 사용했습니다. 그러나 이전 인터뷰에서 5-10 년 이상 경험이있는 선임 개발자들에게 디자인 패턴에 대한 경험을 물어 봤지만 거의 들어 본 적이 없습니다. 20 명의 개발자 중 2 명은 단일 디자인 패턴 (각각 싱글 톤 및 MVC)을 지정할 수 있다고 생각합니다.

내 질문은 :이 질문을하는 것이 합리적입니까? 아니면 신입 사원이 이미 알지 못할 정도로 모호한 주제입니까?

선임 개발자가 디자인 패턴에 대한 사전 경험이 있거나 디자인 패턴이 모든 훌륭한 개발자가 교육 중에 선택할 수있는 간단한 주제라고 말하고 싶습니까? 그렇다면 디자인 능력을 측정하기 위해 어떤 질문을 하시겠습니까?

추가 지금까지 답변을 읽은 후 몇 가지 설명을해야합니다.

• OOP / OOD 경험이있는 .NET 개발자를위한 직무
• 기존의 코드는 같은 클래스 이름을 사용 IParameterGraphVisitor하고 IStorageFactory많은 장소에서를
• 디자인을 설명 할 어휘가없는 경우 사람들이 자신이 만든 OO 디자인에 대한 과거 경험에 대해 어떻게 물어 보십니까? 이것이 제가하고 싶은 일이며, "마지막 프로젝트의 디자인 / 객체 계층을 화이트 보드에 그려주십시오"라고 생각할 수 있습니다.

기회는 그들이 어떻게 그들을 알고있다. 그들은 단지 '디자인 패턴'으로 알지 못할 수도 있습니다. 즉, 그들은 그러한 것들에 대한 학문 용어에 익숙하지 않을 수 있습니다. '상태 머신'으로 보는 것은 단순히 경험이 많고 나이가 많은 프로그래머에게 문제에 대한 상식적인 접근 일 수 있습니다. 예를 들어 나는 '디자인 패턴'에 많은 관심을 기울이지 않았지만, 스테이트 머신 (State Machine)이 무엇인지 알게되면 몇 년 동안 그 일을했기 때문에 웃어야했습니다. 내가 그런 학계라는 걸 누가 알았습니까? 저는 항상 '디자인 패턴'이 아닌 기본 코딩 기술로 간주했습니다.

요점은 숙련 된 개발자가 교과서 용어를 알고 있다고 가정하지 않습니다. 대신, 학생들에게 어떻게 수업을 구성 할 것인지, 어떻게 과제에 접근 할 것인지 물어보십시오.

귀하의 기대는 선임 OO 개발자에게 매우 합리적입니다. Design Patterns를 알지 못하고 경험을 쌓아온 사람이라면 누구나 자신을 부르는 사람은 다음과 같은 세월이 지나도 경험을 자동으로 가져 오지 못한다는 것을 증명할 수 있습니다. 패턴-단지 새로운 아이디어를 배우고 자신을 개선하며 모범 사례를 채택하는 데 관심이 없음을 보여줍니다.

선임 개발자가 디자인 패턴에 대한 사전 경험이 있거나 디자인 패턴이 모든 훌륭한 개발자가 교육 중에 선택할 수있는 간단한 주제라고 말하고 싶습니까?

IMO 경험은 중요합니다. 이론적으로 괜찮은 개발자는 책이나 위키 백과에서 디자인 패턴을 읽고 15 분 안에 기본 개념을 이해할 수 있습니다. 그러나 개념을 올바르게 적용 하려면 어려운 경험이 필요합니다. 패턴에 익숙해지기 쉽고 패턴을 가능한 모든 코드 조각에 담으려고합니다. 또한 "패턴은은 총알이 아니며 가능한 가장 간단한 것을 사용하십시오"라고 말하는 것도 무시하기 쉽습니다. 실제 문제를 해결하기 위해 패턴을 사용하는시기와 방법을 배우고 사용하지 않을 때는 두 가지 경험이 필요 합니다.

디자인 능력을 측정하기 위해 어떤 질문을 하시겠습니까?

위의 내용에 따라 다음 질문 만 목록에 추가합니다.

• 디자인 패턴 (일반적으로, 명시 적으로 언급 된 패턴)의 단점은 무엇입니까?
• 언제 사용 하지 않습니까?

최신 정보

@GrandmasterB는 일부 개발자가 자신의 이름을 몰라도 특정 디자인 패턴을 사용하고있을 수 있다는 점에서 좋은 지적이 있습니다. 어떤 식 으로든 이것은 용어 / 통신 질문이라는 점에서 옳습니다. 그러나 코인의 다른 측면은 실제로 용어 / 통신 질문이라는 것입니다.-) 즉, 디자인 패턴의 주요 이점 중 하나는 개발자에게 공통 어휘를 제공하여 의사 소통을 크게 향상시키는 것 입니다. ( 단어 자체를 사용하지 않고 Adapter 의 기본 개념을 설명하려고 시도 하거나 동의어 인 "wrapper"et al!) 그러나 널리 통용되는 용어를 알지 못하고 유능하고 유능한 후보자가 될 수 있습니다. 당신의 팀에서.

수석 개발자? 명확히. 주니어 야 저는 15 살이고, 주제에 대한 공식적인 교육을받지 않았으며 심지어 그것들을 이해합니다. 그들이 알고 있다고 기대하는 것이 합리적 일뿐만 아니라, 그들이 모르면 받아 들일 수 없을 것입니다. 그들이 객체 지향 프로그래밍에 대해 알고 있다고 가정합니다.

인터뷰에서 응시자가 업무를 수행하기 위해 알아야 할 중요한 사항을 문의해야합니다.

그들이 Gang of Four에서 온 패턴의 이름을 알아야한다면 그것은 유효한 요구 사항입니다.

반면에 프로그램 아키텍처에 대한 적절한 실무 지식을 표시하고 싶다면 문제를 제기하고 코드를 구성하는 방법을 묻는 것이 좋습니다. 그들이 적절한 패턴 솔루션을 제공한다면, 사용 된 이름에 관계없이 그들이 그것을 알고 있다는 증거가 있습니다.

수석 직책에 대해 인터뷰 할 때마다 Q & A보다 "실용적"인 경향이 있습니다. 프로그래밍에 대한 기술과 편안함을 명확하게 보여주고 싶습니다. 또한 캡슐화, 알고리즘, 커플 링 / 응집 등과 같은 개념을 적용하는 방법에 대한보다 일반적인 기술을 의미하는 CS 개념의 확고한 토대를 원합니다. 여러 언어 및 패러다임의 경험과 친숙 함.

그들의 전문 분야에 달려 있습니다. 임베디드 C 개발자가 디자인 패턴에 대해 많이 알 것으로는 기대하지 않습니다. Java 또는 .NET 개발자에 대해 이야기하는 경우 디자인 패턴, 특히 너무 많이 사용하지 않는 방법에 익숙해야합니다.

OOP에서 연로를 찾고 있다고 가정하면 그 대답은 확실히 그렇습니다. 디자인 패턴은 OOP 언어의 어휘입니다.

또한, 10 년의 경험을 가진 괜찮은 OOP 프로그래머가 표준 API, 라이브러리 및 개발 프레임 워크에서 널리 채택 된 디자인 패턴 인 디자인 패턴을 지정할 수 없다는 것은 현재로서는 불합리합니다.

몇 년 전부터 인터뷰 중에이 질문을 해왔으며, 후보자가 주제에 대한 만족스러운 답변을 제공하지 않을 때 가장 중요한 토대입니다.

그렇습니다. 그러나 사람들이 들어 본 디자인 패턴을 열거하도록 요구하기보다는 디자인 질문을 함으로써 이해를 이끌어 내야합니다 . PoEAA, GoF 및 일부 기능적 프로그래밍 패턴에 설명 된 패턴에 익숙하지만 여전히 패턴 이름을 지정하여 문제를 해결하는 방법에 대해 더 많이 배우지 않을 것이라고 생각합니다.

"이미지 편집기와 같은 내장 객체를 어떻게 지원합니까? 굵은 체 및 이탤릭체? 실행 취소?"와 같은 후속 조치가있는 "텍스트 편집기를 디자인하십시오"와 같은 질문이 있습니다. 아마도 명령 패턴, 복합 패턴, 메멘토 패턴 및 짧은 대화로 몇 가지 다른 것들을 인식 할 수있을 것입니다.

디자인 패턴을 발견 하고 설명하여 디자인 결정을 전달할 공통 언어를 갖도록합니다.

불행히도 디자인 패턴의 모든 사용이 실사 때문이 아니라 단순히 그것을 알지 못했기 때문에 설명하고 정당화 해야하는 누군가를 위해 일했습니다. 재미 없어 그러나 대부분의 심각한 개발자는 우연히 또는 설계 상 가장 일반적으로 사용되는 OO 패턴의 이름을 배웠으며, 그 밖의 가치가있는 대부분의 엔터프라이즈 응용 프로그램 개발자는 최소한 가장 일반적인 PoEAA 패턴에 대해 알고 있습니다.

합리적. 물론입니다. 필요한. 아니

잠재적 후보자들에게 디자인 패턴을 알고 있는지 묻습니다. 전체적으로 측정해야하는 몇 가지 기준 중 하나 일뿐입니다. 전체 사진을 간과하지 마십시오.

예, 많은 개발자들이 자신도 모르게 일부 디자인 패턴을 사용합니다.

그렇기 때문에 제가 질문을하는 것은 아닙니다.

다른 개발자와 빠르고 효과적으로 의사 소통 할 수 있다는 것을 아는 것이 중요합니다. 나는 화이트 보드에서 상태 머신을 설명하기 위해 20 분을 "이전에 사용했지만, 무엇을 호출해야할지 몰랐다"는 것을 발견하고 싶지 않습니다. 이것은 생산적이지 않습니다.

또한 리팩토링 프로세스에 도움이됩니다. 코드를 통해 변경하면 일부 형태의 팩토리 패턴이 구현 될 수 있지만 GoF 팩토리 패턴은 시간 테스트를 견뎌냈습니다. 그렇기 때문에 아직 다른 fp가 아닌 팩토리 패턴 이 되는 이유입니다 (바퀴를 다시 만드는 것은 바람직하지 않습니다. 소프트웨어의 Joel은 그렇게하는 단점이 많습니다).

디자인 패턴의 중요성을 사용하고 인식하는 팀은 커뮤니케이션과 생산성을 향상시킵니다. 팀이 단위로 dp를 사용하지 않으면 관련성이 없어집니다.

내 경험으로 말하면, 나는 디자인 패턴을 오랫동안 무시했습니다. 나는 그들이 존재한다는 것을 알았습니다. 나는 그들에 대해 읽지 않았습니다. 마지막으로 글 머리 기호를 물고 나면 디자인 패턴을 모두 사용하고 있다는 것을 깨달았습니다.

특정 디자인 패턴이 솔루션에 잘 맞는 일련의 문제를 생각해 내고 개발자가 패턴과 비슷한 것을 생각해내는 경향이 있습니다. 그렇게한다면 훌륭합니다. 디자인 패턴 지식이있는 특정 개발자가 특정 패턴을 해결하기보다는 패턴에 적합하지 않을 때 패턴에 솔루션을 맞추려고 시도하는 것을 알면서 디자인 패턴을 사용하는 개발자를 고용하는 경향이 더 큽니다. 잘 문제.

더 좋은 질문은 다음과 같습니다. 패턴의 이름과 패턴에 대한 설명 (예 : Gang of Four 책의 팩토리 패턴)이 주어지면 응시자는 패턴이있는 시나리오를 생각해 낼 수 있어야합니다 합리적인 접근.

경험이 5-10 년인 개발자가 있으며 선임 개발자가 있습니다. 그들은 전혀 같은 것이 아닙니다. 그렇습니다. 고위급 직원을 고용하고 있고 사람들이 디자인 패턴을 알고 사용하기를 기대하는 경우에는 익숙하지 않은 노인을 고용하지 않겠습니다. 왼쪽 조인을 이해하지 못한 데이터베이스 전문가를 고용하는 것과 같습니다. 진정한 선임 개발자에게는 매우 기본적인 것입니다. 그래도 나는 주니어를 고용 할 것입니다.

그렇습니다. 그들은 실제로이 용어에 익숙해야하며, 몇 가지 패턴의 이름을 지정할 수 있어야합니다. 그러나 이론적 지식을 경험과 혼동하는 실수를 저 지르지 마십시오.

인터뷰를하기 전에 디자인 패턴을 마무리 짓고 간단한 설명만으로 문제를 해결할 수있는 사람들이 많이 있습니다. 그러나 그것은 단지 이론 일뿐입니다. 언제 사용할 것인지, 공식적인 패턴에 대한 지식이 없어도 고전적인 디자인 패턴 방식으로 문제를 해결할 수있는 것은 선임 개발자입니다.

확인하는 가장 좋은 방법은 그들이 당신 앞에 무언가를 디자인하고 탐구하는 질문을하는 것입니다. 선임 개발자는 추상화 수준에서 자연스럽게 생각할 수있는 사람입니다. 이들은 디자인 패턴을 "창조"하는 사람들입니다.

사람들에게 저글링을 요구하지 않고 저글러 를 고용하는 것에 대해 이야기하는 Peopleware 클래스와 마찬가지로, 그들이 의미가 없다고 말했기 때문에 .. 시험해보십시오.

이미 언급했듯이, 나는 유행어를 기억하지 않으면 괜찮습니다. 그러나 이것은 고위직이기 때문에 최악의 솔루션을 사용하는 대신 문제를 최적으로 해결하기 위해 패턴을 적용 할시기를 알아야합니다. 따라서 패턴을 사용하여 해결해야하는 문제 (예 : 클래스를 하드 코딩하지 않고 객체를 만드는 방법, 구현에 대한 세부 정보없이 객체의 요소에 액세스하는 방법 등)를 제시하고 방법을 확인하십시오. 그들은 그것을 공격 할 것입니다.

분명히 그들은 패턴을 알아야하지만 반드시 유행어는 아닙니다.

예를 들어 MVC에는 PAC, 3 계층과 같은 매우 유사한 대안이 많이 있습니다. 몇 년 전 MVC의 또 다른 유명한 유행어는 "모델 2"였습니다. 실제로 그 패턴을 완벽하게 알고있는 매우 훌륭한 개발자는 알고 있지만 현재 유행어는 MVC라는 것을 몰랐습니다.

아주 간단히 말해서 : 만약 당신이 그것들을 사용한다면 당신은 후보자들에게 물어볼 필요가 있습니다. 패턴을 알고 있다면 몇 가지 더하기 점을 추가해야합니다. 그러나 그들이 좋은 OOD 기술을 보여주는 경우 반드시 그들을 망치지 않아야합니다. 유지 관리 프로젝트에 참여한 개발자는 설계 패턴에 비해 디자인 패턴에 대해 많이 알지 못할 것입니다. 그것은 또한 그들이 대학에서 desing 패턴을 가르쳤는지 여부에 달려 있습니다. 내 경험으로는 그들이 할 것 같지 않습니다. 대부분의 대학과 사립 과정은 OOP를 가르치지 만 OOD는 가르치지 않습니다. 그들이 DP를 공부했을 가능성은 훨씬 적습니다.

개인적으로, 저의 프로젝트가 저를 필요로 할 때까지 DP를 공부하지 않았습니다. 그럼에도 불구하고 나는 그 책에 묘사 된 정확한 방식이 아니라면 적어도 비슷한 방식으로 몇 가지 패턴을 사용했음을 발견했다. 그들이 성문화되었다는 사실에 놀랐습니다. DP를 모르면 훌륭한 디자인 기술을 찾으십시오. 그들이 DP를 안다면, 그들은 디자인에 능숙하지만 여전히 테스트 할 것입니다. 그들은 DP에 대한 약간의 어설픈 말을하거나 일부 내부자로부터 발견되었을 수 있으며 그것들을 적용하지 않고 몇 가지 패턴을 연구했을뿐입니다.

직업을 신청하는 사람들이 산업 표준 여부에 상관없이 직업 슬롯에 필요한 것을 알고 (또는 배우고) 기대하는 것이 합리적입니다. 그렇지 않으면 평범한 것으로 자신을 정죄합니다. 그러나 실제로 필요하지 않은 경우 일부 지식 (또는 기술)을 직무 요구 사항으로 만들지 않도록주의하십시오.

대략 비슷한 배경을 가진 두 명의 후보가 있고 하나는 디자인 패턴에 대해 말할 수 있지만 다른 하나는 그렇지 않다고 가정 해 봅시다. 그들이 어떻게 업무를 수행 할 것인지에 대해 무엇을 알려줄 것입니까?

기존 소프트웨어가 디자인 패턴을 사용한다고 말합니다. 이점이 있습니까? 그렇다면 어떻게? 작성된 새로운 소프트웨어가 기존 패턴을 따르거나 새로운 패턴을 도입하는 것이 목표입니까? 왜?

다음과 같은 상황에서 디자인 패턴을 모르는 선임 개발자를 생각할 수 있습니다.

1. 디자인 패턴에 대한 책은 하나 뿐입니다 . 처음부터 인기를 끌었던 책입니다. 이 책을 읽지 않은 사람은 디자인 패턴에 대해 모르거나 들었을 수도 있지만 자신이 무엇을위한 것인지 제대로 알지 못할 수도 있습니다.
2. 대신, 그들은 uml과 같은 것을 알아야 할 것입니다 ....
3. 인터넷에서 디자인 패턴에 대한 좋은 정보를 찾는 것은 쉽지 않습니다. 좋은 디자인 패턴 지식을 가진 올바른 웹 페이지를 방문하면 매우 운이 좋습니다. 1995 년 이후 단순히 소프트웨어를 사용하면 책이 오래되어 디자인 패턴에 대해 알지 못할 수도 있습니다.

비 OO 환경의 개발자가 OO 디자인 패턴에 대해 알아야하는 이유는 무엇입니까? 저는 Cobol, PL / SQL, Progress 4GL 등을 수행하는 상점에서 일했습니다. OO 설계 원칙은 관련이 없습니다. 해당 환경의 선배들은 OO 설계가 아닌 해당 환경에 대한 관련 지식을 갖기를 기대합니다 패턴.

패턴 카탈로그에서 무의식적으로 인용 할 수 있다고해서 훌륭한 개발자가되는 것은 아닙니다 (사실 경험상 필자가 본 최악의 코드 중 일부를 생성합니다). 그러나 이것이 "고급 개발자"의 표식이 될 것으로 기대하는 것입니다. 저는 15 년 동안 업계에서 일해 왔지만 패턴 다이어그램을 그리도록 요구하지는 않습니다. 나는 많은 시간을주지 않았습니다. 필요하지 않습니다. 특정 이름을 쓰지 않고 작동하는 것을 찾을 수있는 충분한 경험을 얻었으며 공식적인 정의가 필요한 경우 어디서 찾을 수 있는지 알고 있습니다 (예, 개인 도서관에 참고 도서가 있습니다). 그것은 교과서 일부를 습득하여 얻은 지식이 아닌 숙련 된 개발자의 표식입니다.