É razoável esperar que um desenvolvedor sênior saiba quais são os padrões de design do OOP? [fechadas]

Estou preparando perguntas para entrevistas de emprego para uma posição de desenvolvimento sênior. O trabalho incluiria design orientado a objetos e o software existente usa padrões de design. Por isso, gostaria de pedir aos candidatos que expliquem alguns padrões de design que eles conhecem, que usaram, como eles os usaram, por que eles usou-os e assim por diante. No entanto, em entrevistas anteriores, quando perguntei a desenvolvedores seniores com pelo menos 5 a 10 anos de experiência sobre padrões de design, quase ninguém nunca ouviu falar deles. Eu acho que dois em cada vinte desenvolvedores poderiam nomear um único padrão de design (Singleton e MVC, respectivamente).

Então, minha pergunta é: faz sentido fazer essas perguntas? Ou esse é um assunto tão obscuro que você não pode esperar que novos contratados os conheçam?

Um desenvolvedor sênior deve ter experiência prévia com padrões de design ou você diria que os padrões de design são um tópico tão simples que todo desenvolvedor decente pode buscá-los durante o treinamento? Se sim, que perguntas você faria para avaliar suas habilidades de design?

Adicionar Depois de ler as respostas até agora, devo dar alguns esclarecimentos:

• O trabalho é para um desenvolvedor .NET com experiência em OOP / OOD
• O código existente usa nomes de classe como IParameterGraphVisitore IStorageFactoryem muitos lugares
• Como você pergunta às pessoas sobre suas experiências passadas com os projetos OO que eles criaram, se eles não têm o vocabulário para explicar seus projetos? É isso que eu quero fazer, e tudo o que posso fazer é "por favor, desenhe a hierarquia de design / objeto do seu último projeto no quadro".

Provavelmente, eles os conhecem. Eles apenas podem não conhecê-los como 'padrões de design'; isto é, eles podem não estar familiarizados com a terminologia acadêmica para tais coisas. O que você vê como uma "máquina de estado" pode ser simplesmente uma abordagem de senso comum para um problema de um programador mais velho e experiente. Eu nunca prestei muita atenção aos 'padrões de design', por exemplo, mas quando soube o que era uma Máquina de Estado, tive que rir porque fazia isso há anos. Quem sabia que eu era um acadêmico? Eu sempre considerei a habilidade básica de codificação, e não um 'padrão de design'.

O ponto não é supor que seus desenvolvedores experientes conheçam os termos do livro-texto para as coisas; em vez disso, pergunte a eles como estruturariam as classes ou como abordariam uma tarefa.

Sua expectativa é bastante razoável para um desenvolvedor sênior de OO. Qualquer pessoa que se autodenomina que, sem conhecer os Padrões de Design, apenas demonstra que a experiência não é trazida automaticamente pelos anos que se passam :-( Claro, existem muitos desenvolvedores por aí que passaram anos ou mesmo décadas em campo, sem nunca ouvir falar sobre design padrões - que apenas mostram que eles não estavam interessados ​​em aprender novas idéias, melhorar a si mesmos e adotar as melhores práticas.

Um desenvolvedor sênior deve ter experiência prévia com padrões de design ou você diria que os padrões de design são um tópico tão simples que todo desenvolvedor decente pode buscá-los durante o treinamento?

A experiência da IMO conta muito. Em teoria, um desenvolvedor decente pode ler os Design Patterns em um livro, ou mesmo na Wikipedia, e entender o conceito básico em 15 minutos. No entanto, a aplicação adequada dos conceitos requer experiência adquirida com muito esforço. É fácil se apaixonar por padrões, tentando amontoá-los em todo pedaço de código possível, l'art pour l'art. Também é fácil descartá-los dizendo que "os padrões não são uma bala de prata, basta usar a coisa mais simples que poderia funcionar". Encontrar o meio termo entre os dois extremos, aprendendo quando e como usar padrões para resolver problemas reais, e quando não usá-los, leva anos de experiência .

que perguntas você faria para avaliar suas habilidades de design?

Em concordância com o acima exposto, gostaria apenas de adicionar estas perguntas à sua lista:

• Quais são as desvantagens dos padrões de design (em geral, e os que eles mencionam explicitamente)?
• Quando não usá-los e por quê?

Atualizar

O @GrandmasterB tem um bom argumento de que alguns desenvolvedores podem estar usando padrões de design específicos sem saber seu nome. De certa forma, ele está certo, pois é uma questão de terminologia / comunicação. No entanto, o outro lado da moeda é que é realmente uma questão de terminologia / comunicação :-) Ou seja, um dos principais benefícios do Design Patterns é fornecer um vocabulário comum aos desenvolvedores, melhorando enormemente a comunicação . (Tente explicar a idéia básica do Adapter sem usar a palavra em si, ou seus sinônimos "wrapper" et al!). Por mais talentoso e conhecedor que seja um candidato, sem conhecer as terminologias amplamente aceitas, ele apresentará um problema de comunicação na sua equipe.

Um desenvolvedor sênior ? Definitivamente. Um júnior deveria. Tenho 15 anos, não tenho educação formal sobre o assunto e até eu os entendo. Não é apenas razoável esperar que eles os conheçam, seria inaceitável se não o conhecessem. Supondo que eles saibam algo sobre programação orientada a objetos, o que eles provavelmente sabem.

Em uma entrevista, você deve perguntar o que é crítico para o candidato saber para fazer o trabalho.

Se eles precisam saber os nomes dos padrões como são do Gangue dos Quatro, esse é um requisito válido.

Se, por outro lado, você deseja que eles exibam o conhecimento de trabalho adequado da arquitetura do programa, acho melhor dar a eles um problema e perguntar como a estrutura do código. Se eles fornecerem a solução padrão apropriada, você terá a prova de que eles sabem disso, independentemente do nome usado.

Sempre que entrevisto para cargos de nível sênior, eles tendem a ser mais "práticos" do que as perguntas e respostas. Quero uma demonstração clara de habilidade e conforto na programação. Eu também quero uma base sólida nos conceitos de CS, o que significa habilidades mais gerais de como aplicar conceitos como encapsulamento, algoritmos, acoplamento / coesão, etc. Experiência e familiaridade em vários idiomas e paradigmas.

Depende da área de sua experiência. Eu não esperaria que um desenvolvedor C incorporado soubesse muito sobre padrões de design. Se estamos falando de um desenvolvedor Java ou .NET, eles devem estar familiarizados com os padrões de design e, principalmente, como não se deixar levar por eles.

Supondo que você esteja buscando antiguidade no POO, a resposta é definitivamente sim. Os padrões de design são o léxico da linguagem OOP.

Além disso, atualmente não é razoável que um programador decente de OOP com 10 anos de experiência não consiga nomear um padrão de design, sendo padrões de design amplamente adotados em APIs, bibliotecas e estruturas de desenvolvimento padrão.

Já faz anos que faço essa pergunta durante as entrevistas e é um empecilho para o fato de o candidato não fornecer respostas satisfatórias sobre o assunto.

Sim, mas você provavelmente deve obter o entendimento deles fazendo perguntas de design, em vez de pedir às pessoas que enumerem os padrões de design de que ouviram falar. Estou bastante confortável com os padrões descritos em PoEAA, GoF e até com alguns padrões de programação funcional, e ainda acho que você não aprenderia muito mais sobre minha abordagem para resolver problemas, pedindo-me para nomear alguns padrões.

Dada uma pergunta como "projete-me um editor de texto" com acompanhamentos como "Como você suporta objetos incorporados, como imagens? Negrito e itálico? Desfazer?" Você provavelmente ouviria o suficiente para reconhecer o padrão de comando, o padrão composto, o padrão de lembranças e alguns outros com até uma breve conversa.

Os padrões de design foram descobertos e descritos para que tivéssemos uma linguagem comum com a qual comunicar decisões de design.

Infelizmente, trabalhei para alguém para quem todo uso de um padrão de design precisava ser explicado e justificado, não por causa da devida diligência, mas porque ele simplesmente não os conhecia. Isso não é divertido. Mas os desenvolvedores mais sérios, por acidente ou design, aprenderam os nomes dos padrões de OO mais usados, se nada mais, e a maioria dos desenvolvedores de aplicativos corporativos vale a pena pelo menos saber algo sobre os padrões PoEAA mais comuns.

Razoável. Definitivamente. Necessário. Não

Pergunto aos possíveis candidatos se eles conhecem padrões de design. É apenas um dos vários critérios a serem pesados ​​como um todo. Não negligencie a imagem total.

Sim, muitos desenvolvedores, sem saber, usam alguns padrões de design, sem dúvida.

Não é por isso que faço a pergunta.

É importante saber que posso me comunicar de maneira rápida e eficaz com outro desenvolvedor. Não quero passar 20 minutos em um quadro branco explicando uma máquina de estado apenas para descobrir que eles "a usaram antes, mas nunca sabiam como chamá-la". Isso não é produtivo.

Eles também ajudam no processo de refatoração. Olhar através do código 1 pode, ocasionalmente, implementar alguma forma de padrão de fábrica, mas o padrão de fábrica do GoF resistiu ao teste do tempo. É por isso que é o padrão de fábrica, e NÃO AINDA Outro ponto de fp (não é preferível reinventar a roda, Joel no software tem muitas desvantagens).

Uma equipe que usa e reconhece a importância dos padrões de design aumenta a comunicação e a produtividade. Se sua equipe, como uma unidade, não usa dp, eles perdem sua relevância.

Falando por experiência própria, ignorei os padrões de design por um bom tempo. Eu sabia que eles existiam, apenas nunca li sobre eles. Depois que finalmente cheguei à conclusão, percebi que estava usando o padrão de design o tempo todo e simplesmente não percebi ou não sabia que minhas soluções de design realmente tinham um nome comum.

Eu estaria mais inclinado a apresentar um conjunto de problemas em que um padrão de design específico se encaixa bem na solução e ver o desenvolvedor criar algo semelhante ao padrão. Se o fizerem, ótimo. Talvez eu esteja ainda mais inclinado a contratar um desenvolvedor que use padrões de design desconhecidos, pois vejo muitos desenvolvedores que têm conhecimento de padrões de projeto tentando ajustar uma solução a um padrão quando não é apropriado, em vez de perceber que um padrão específico acontece para resolver o problema. problema bem.

Penso que uma pergunta melhor seria: Dado o nome de um padrão e uma descrição do padrão, por exemplo, um Padrão de Fábrica do livro Gang of Four, o candidato deve ser capaz de apresentar um cenário em que o padrão seria uma abordagem razoável.

Existem desenvolvedores com 5 a 10 anos de experiência e desenvolvedores seniores. Eles não são a mesma coisa. Sim, se você está contratando no nível sênior e espera que as pessoas conheçam e usem padrões de design, eu não contrataria uma pessoa sênior que não estivesse familiarizada com eles. Seria como contratar um especialista em banco de dados que não entendeu as associações à esquerda. Isso é bastante básico para um verdadeiro desenvolvedor sênior. Eu provavelmente contrataria uma pessoa júnior.

Sim, de fato, eles devem estar familiarizados com o termo e devem ser capazes de nomear alguns dos padrões - mas não cometa o erro de confundir conhecimento teórico com experiência.

Há muitas pessoas que, antes de uma entrevista, revisam os padrões de design e podem descrevê-los com uma breve descrição - mas essa é apenas a teoria. É um desenvolvedor sênior realmente capaz de identificar quando usar um ou, sem o conhecimento de um padrão formal, resolveria o problema de uma maneira clássica de design.

A melhor maneira de verificar é deixá-los projetar algo à sua frente e fazer perguntas aprofundadas. Um desenvolvedor sênior é alguém que pode pensar naturalmente no nível de abstração. Essas são as pessoas que "criam" os padrões de design.

Como a classe Peopleware, que fala sobre contratar um malabarista sem pedir que ele faça malabarismos - só porque eles dizem que podem não significa muito .. experimente-os.

Como já foi dito, também acredito que não há problema se eles não se lembram de palavras-chave de cor. Mas como essa é uma posição sênior, eles devem saber quando aplicar um padrão para resolver um problema da melhor maneira possível, em vez de usar as piores soluções. Assim, dê a eles um problema que deve ser resolvido usando um padrão (por exemplo, como criar um objeto sem codificar sua classe, como acessar os elementos de um objeto sem ter detalhes sobre sua implementação etc.) e veja como eles vão atacar.

Definitivamente, eles deveriam conhecer os padrões, mas não necessariamente as palavras da moda.

Por exemplo, o MVC tem muitas alternativas muito semelhantes, como PAC, de três camadas. Alguns anos atrás, outro termo popular para o MVC era "Modelo 2". Na verdade, conheço desenvolvedores muito bons que conhecem perfeitamente esse padrão, mas não sabiam que o chavão atual para ele é MVC.

Muito simplesmente: se você os estiver usando, precisará perguntar aos seus candidatos. Se eles conhecem padrões, deve adicionar alguns pontos positivos; mas não saber não deve necessariamente excluí-los, especialmente se eles mostrarem boas habilidades em OOD. É improvável que os desenvolvedores que tenham participado de projetos de manutenção saibam muito sobre os padrões de design em comparação com aqueles que já os desenvolveram. também depende se eles foram ensinados a desenhar padrões na faculdade. Na minha experiência, é improvável que eles o façam. A maioria das universidades e cursos particulares ensina OOP, mas não OOD. As chances de que eles tenham estudado DP são ainda menores.

Pessoalmente, eu não tinha estudado DP até que meu projeto me exigisse também. Mesmo assim, descobri que havia usado alguns padrões, pelo menos de maneira semelhante, se não da maneira exata descrita no livro. Fiquei surpreso ao saber que eles foram codificados. Portanto, procure boas habilidades de design, se não souberem DP. Se eles conhecem DP, é provável que sejam bons no design, mas ainda os testem. Eles podem ter acabado de encabeçar algum boato sobre DP ou descoberto por algum especialista e apenas estudado alguns padrões sem aplicá-los.

É razoável que você espere que as pessoas que se candidatam a um emprego conheçam (ou aprendam) o que é necessário em seu espaço de trabalho, independentemente de serem ou não padrões do setor. Caso contrário, você se condena à mediocridade. Mas tenha cuidado em tornar um conhecimento (ou habilidade) um requisito de trabalho, se não for realmente necessário.

Digamos que você tenha dois candidatos com formação semelhante, e um é capaz de falar sobre padrões de design e o outro não. O que isso vai lhe dizer sobre o desempenho deles no trabalho?

Você diz que o software existente usa padrões de design. Isso é uma vantagem? Se sim, como? É seu objetivo que o novo software escrito esteja em conformidade com os padrões existentes ou que novos padrões sejam introduzidos? Por quê?

Posso pensar em um desenvolvedor sênior que não conhece padrões de design na seguinte situação:

1. Há apenas um livro sobre padrões de design. É o livro que os tornou populares em primeiro lugar. Se a pessoa não leu este livro, é possível que ela não conheça os padrões de design ou tenha ouvido falar deles, mas não saiba para que serve.
2. Em vez disso, eles teriam que saber algo como uml ....
3. Encontrar boas informações sobre padrões de design da Internet não é fácil. Você tem muita sorte se acessar a página da web correta que possui um bom conhecimento de padrões de design. Simplesmente vir para o software depois de 1995 pode fazer uma pessoa não conhecer o livro de padrões de design, porque o livro é antigo.

Por que qualquer desenvolvedor em um ambiente não OO deve conhecer os padrões de design do OO? Eu trabalhei em lojas fazendo apenas Cobol, apenas PL / SQL, apenas Progress 4GL, etc. Princípios de design OO são irrelevantes por lá, eu esperaria que os idosos nesses ambientes tivessem conhecimento relevante para esses ambientes, não o design OO padrões.

Ser capaz de citar sem pensar em um catálogo de padrões também não faz de você um bom desenvolvedor (na verdade, na minha experiência, ele produz alguns dos piores códigos que eu já vi). No entanto, é isso que você espera ser a marca de um "desenvolvedor sênior". Trabalho na indústria há 15 anos, mas não me peça para desenhar um diagrama de padrões. Eu nunca dei muito tempo, não preciso. Eu ganhei experiência suficiente para descobrir o que funciona sem colocar um nome específico e, se precisar da definição formal, sei onde procurar (e sim, tenho os livros de referência na minha biblioteca pessoal). Essa é a marca do desenvolvedor experiente, e não o conhecimento adquirido com os livros escolares.