Разумно ли ожидать, что старший разработчик знает, что такое шаблоны проектирования ООП? [закрыто]

Я готовлю вопросы для собеседования на должность старшего специалиста. Работа включала бы объектно-ориентированное проектирование, а существующее программное обеспечение использует шаблоны проектирования, поэтому я хотел бы попросить кандидатов объяснить несколько шаблонов проектирования, которые они знают, они использовали, как они их использовали, почему они использовал их и так далее. Тем не менее, в предыдущих интервью, когда я спрашивал старших разработчиков со стажем не менее 5-10 лет о шаблонах проектирования, о них почти никто не слышал. Я думаю, что два из двадцати разработчиков могли бы назвать один шаблон проектирования (Singleton и MVC, соответственно).

Итак, мой вопрос: имеет ли смысл задавать эти вопросы? Или это такой неясный предмет, что вы не можете ожидать, что новые сотрудники уже узнают их?

Должен ли старший разработчик иметь предыдущий опыт работы с шаблонами проектирования, или вы бы сказали, что шаблоны проектирования - это такая простая тема, что каждый достойный разработчик может подобрать их во время обучения? Если да, то какие вопросы вы бы задали вместо этого, чтобы оценить их дизайнерские способности?

Добавить После прочтения ответов я должен дать несколько разъяснений:

• Работа для разработчика .NET с опытом работы в OOP / OOD
• Существующий код использует имена классов, как IParameterGraphVisitorи IStorageFactoryво многих местах
• Как вы спрашиваете людей об их прошлом опыте с созданными ими ОО-проектами, если у них нет словарного запаса для объяснения своих проектов? Это то, что я хочу сделать, и все, что я могу придумать, это «пожалуйста, нарисуйте иерархию дизайна / объекта вашего последнего проекта на доске».

Скорее всего, они их знают. Они просто могут не знать их как «шаблоны проектирования»; то есть они могут быть не знакомы с академической терминологией для таких вещей. То, что вы рассматриваете как «конечный автомат», может быть просто здравым смыслом подхода к проблеме для более старого, более опытного программиста. Например, я никогда не обращал особого внимания на «шаблоны проектирования», но когда я узнал, что такое State Machine, мне пришлось смеяться, потому что я делал это годами. Кто знал, что я такой академик? Я всегда считал это базовым навыком кодирования, а не «шаблоном дизайна».

Дело не в том, что ваши опытные разработчики знают термины из учебника; вместо этого спросите их, как они будут структурировать классы или как они будут подходить к задаче.

Ваши ожидания вполне разумны для старшего разработчика OO. Любой, кто говорит, что, не зная Design Patterns, просто демонстрирует, что опыт не приносится автоматически с годами :-( Конечно, многие разработчики провели годы или даже десятилетия в этой области, даже не слышав о дизайне. шаблоны - это просто показывает, что они не были заинтересованы в изучении новых идей, совершенствовании себя и внедрении лучших практик.

Должен ли старший разработчик иметь предыдущий опыт работы с шаблонами проектирования, или вы бы сказали, что шаблоны проектирования - это такая простая тема, что каждый достойный разработчик может подобрать их во время обучения?

ИМО опыт имеет большое значение. Теоретически, достойный разработчик может прочитать шаблоны проектирования в книге или даже в Википедии и понять основную концепцию за 15 минут. Тем не менее, правильное применение понятий требует с трудом заработанного опыта. Легко увлечься шаблонами, пытаясь втиснуть их в каждый возможный кусок кода, l'art pour l'art. Их также легко отклонить, сказав, что «узоры - это не серебряная пуля, просто используйте самую простую вещь, которая могла бы сработать». Чтобы найти золотую середину между двумя крайностями, узнав, когда и как использовать шаблоны для решения реальных проблем, а когда не использовать их, требуются годы опыта .

какие вопросы вы бы задали, чтобы оценить их дизайнерские способности?

В соответствии с вышеизложенным, я бы только добавил эти вопросы в ваш список:

• Каковы недостатки шаблонов проектирования (в целом и тех, которые они явно упоминают)?
• Когда их не использовать и почему?

Обновить

@GrandmasterB имеет хорошее преимущество в том, что некоторые разработчики могут использовать определенные шаблоны проектирования, не зная их имени. В некотором смысле он прав в том, что это вопрос терминологии / коммуникации. Однако другая сторона медали в том, что это действительно вопрос терминологии / коммуникации :-) То есть, одно из главных преимуществ шаблонов проектирования - это предоставление общего словаря разработчикам, что значительно улучшает коммуникацию . (Попытайтесь объяснить основную идею Адаптера, не используя само слово или его синонимы «обертка» и др.) Таким образом, каким бы талантливым и знающим ни был кандидат, без знания общепринятой терминологии он может ввести проблему общения. в твоей команде.

Старший разработчик? Определенно. Младший должен. Мне 15 лет, у меня нет формального образования по этому предмету, и даже я их понимаю. Не только разумно ожидать, что они знают их, это было бы неприемлемо, если бы они не знали. Предполагая, что они знают что-то об объектно-ориентированном программировании, что они, скорее всего, делают.

На собеседовании вы должны спросить, что важно знать кандидату для выполнения работы.

Если они должны знать имена шаблонов, как они взяты из «Банды четырех», это является действительным требованием.

Если, с другой стороны, вы хотите, чтобы они отображали соответствующие практические знания об архитектуре программы, я думаю, вам лучше дать им проблему и спросить их, как будет структурироваться код. Если они дадут вам подходящее шаблонное решение, у вас будет доказательство того, что они знают его, независимо от используемого имени.

Всякий раз, когда я беру интервью на руководящие должности, они, как правило, более «практичны», чем вопросы и ответы. Я хочу четкую демонстрацию мастерства и комфорта в программировании. Я также хочу прочно обосновать концепции CS, что означает более общие навыки применения таких понятий, как инкапсуляция, алгоритмы, связывание / сплоченность и т. Д. Опыт и знакомство с несколькими языками и парадигмами.

Зависит от области их экспертизы. Я не ожидал бы, что разработчик встроенного C будет знать много о шаблонах проектирования. Если мы говорим о Java или .NET-разработчике, они должны быть знакомы с шаблонами проектирования, и особенно с тем, как не слишком увлекаться ими.

Предполагая, что вы ищете стаж в ООП, ответ однозначно да. Шаблоны проектирования являются лексиконом языка ООП.

Кроме того, в настоящее время неразумно, что достойный программист ООП с 10-летним опытом не может назвать шаблон проектирования, будучи шаблонами проектирования, широко принятыми в стандартных API, библиотеках и средах разработки.

Уже много лет я задавал этот вопрос во время собеседований, и это показательный шаг, когда кандидат не дает удовлетворительных ответов по этой теме.

Да, но вам, вероятно, следует выявить их понимание, задавая вопросы дизайна, а не просить людей перечислять шаблоны проектирования, о которых они слышали. Мне довольно комфортно с шаблонами, описанными в PoEAA, GoF и даже с некоторыми шаблонами функционального программирования, и я до сих пор не думаю, что вы узнаете намного больше о моем подходе к решению проблем, попросив назвать некоторые шаблоны.

На вопрос типа «Создай мне текстовый редактор» с последующими ответами: «Как вы собираетесь поддерживать встроенные объекты, такие как изображения? Жирный и курсив? Отменить?» Вы, вероятно, в конце концов услышите достаточно, чтобы распознать шаблон команд, составной шаблон, шаблон памятного подарка и несколько других даже при коротком разговоре.

Шаблоны проектирования были обнаружены, а затем описаны, чтобы у нас был общий язык для общения с проектными решениями.

К сожалению, я работал на кого-то, для кого каждое использование шаблона проектирования должно было быть объяснено и обосновано не из-за должной осмотрительности, а потому, что он просто не знал их. Это не весело. Но самые серьезные разработчики, случайно или по замыслу, узнали имена наиболее часто используемых шаблонов ОО, если не сказать больше, и большинство разработчиков корпоративных приложений стоит того, чтобы по крайней мере кое-что знать о наиболее распространенных шаблонах PoEAA.

Умеренная. Определенно. Необходимо. нет

Я спрашиваю потенциальных кандидатов, знают ли они шаблоны проектирования. Это всего лишь один из нескольких критериев для взвешивания в целом. Не упускайте из виду общую картину.

Да, многие разработчики неосознанно используют некоторые шаблоны проектирования, без сомнения.

Я не поэтому задаю вопрос.

Важно знать, что я могу быстро и эффективно общаться с другим разработчиком. Я не хочу тратить 20 минут на доске, объясняющей конечный автомат, только чтобы обнаружить, что они «использовали его раньше, но никогда не знали, как его назвать». Это не продуктивно.

Они также помогают в процессе рефакторинга. Просматривая код, можно случайно реализовать некоторую форму фабричного шаблона, но фабричный шаблон GoF выдержал испытание временем. Вот почему это заводской шаблон, а не ДАЖЕ fp (изобретать колесо не желательно, у Джоэла в программном обеспечении есть много недостатков, которые можно сделать при этом).

Команда, которая использует и осознает важность шаблонов проектирования, повышает коммуникацию и производительность. Если ваша команда как подразделение не использует дп, то они теряют свою актуальность.

Исходя из собственного опыта, я довольно долго игнорировал дизайн. Я знал, что они существуют, я просто никогда не читал о них. Когда я, наконец, укусила пулю, я поняла, что все время использовала шаблон проектирования, и я просто не осознавала этого или не знала, что мои дизайнерские решения на самом деле имеют общее имя.

Я был бы более склонен придумать ряд проблем, когда конкретный шаблон проектирования хорошо подходит для решения, и увидел, что разработчик придумал что-то похожее на шаблон. Если они это сделают, отлично. Я мог бы быть даже более склонным нанять разработчика, который использовал шаблоны проектирования по незнанию, поскольку я вижу, что многие разработчики, обладающие знаниями в области шаблонов проектирования, пытаются приспособить решение к шаблону, когда он не подходит, вместо того, чтобы понять, что конкретный шаблон решает проблему. проблема хорошо.

Я думаю, что лучший вопрос был бы: учитывая имя шаблона и описание шаблона, например, Фабричный шаблон из книги «Банды четырех», кандидат должен иметь возможность придумать сценарий, в котором шаблон будет разумный подход.

Есть разработчики с опытом работы 5-10 лет, и есть старшие разработчики. Они совсем не одно и то же. Да, если вы нанимаете сотрудников старшего уровня и ожидаете, что люди будут знать и использовать шаблоны проектирования, тогда я не найму старшего сотрудника, который не был знаком с ними. Это все равно что нанять специалиста по базам данных, который не понимает левых соединений. Это довольно простой материал для настоящего старшего разработчика. Я, вероятно, нанял бы младшего человека все же.

Да, действительно, они должны быть знакомы с этим термином и даже должны быть в состоянии назвать несколько моделей - но не делайте ошибку, путая теоретические знания с опытом.

Есть много людей, которые перед собеседованием освежат в памяти шаблоны проектирования и могут объяснить их кратким описанием, но это только теория. Это настоящий старший разработчик, который может определить, когда его использовать, или без знания формального шаблона, решит проблему классическим способом разработки.

Лучший способ проверить это - позволить им спроектировать что-то перед вами и задать интересующие вопросы. Старший разработчик - это тот, кто может мыслить естественно на уровне абстракции. Это люди, которые «создают» шаблоны дизайна.

Как класс Peopleware, который говорит о найме жонглера, не прося его жонглировать - только потому, что они говорят, что могут, не значит много .. опробуйте их.

Как уже говорилось, я также считаю, что это нормально, если они не помнят модные слова наизусть. Но поскольку это руководящая должность, они должны знать, когда применять шаблон для оптимального решения проблемы, вместо того чтобы использовать худшие решения. Таким образом, предоставьте им задачу, которую нужно решить с помощью шаблона (например, как создать объект без жесткого кодирования его класса, как получить доступ к элементам объекта без подробных сведений о его реализации и т. Д.) И посмотреть, как они будут атаковать его.

Определенно они должны знать шаблоны, но не обязательно умные слова.

Например, MVC имеет много очень похожих альтернатив, таких как PAC, 3-уровневый. Несколько лет назад другим популярным модным словом для MVC была «Модель 2». Я на самом деле знаю очень хороших разработчиков, которые прекрасно знают этот паттерн, но не знали, что сейчас это модное слово MVC.

Очень просто: если вы используете их, вам нужно спросить своих кандидатов. Если они знают шаблоны, то это должно добавить несколько плюсов; но не зная, не обязательно лишать их, особенно если они показывают хорошие навыки OOD. Разработчики, которые участвовали в проектах сопровождения, вряд ли много знают о шаблонах проектирования по сравнению с теми, кто их проектировал. это также зависит от того, были ли они обучены в колледже. По моему опыту, вряд ли они будут. Большинство университетов и частных курсов обучают вас ООП, но не ООД. Вероятность того, что они изучат DP, еще меньше.

Лично я не изучал DP, пока мой проект не потребовал меня тоже. Уже тогда я обнаружил, что использовал несколько шаблонов, по крайней мере, таким же образом, если не точно так, как описано в книге. Я был удивлен, узнав, что они были записаны. Так что ищите хорошие дизайнерские навыки, если они не знают DP. Если они знают DP, вероятно, они хороши в дизайне, но все же проверяют их. Они, возможно, имели какое-то умное слово о DP или узнали от какого-то инсайдера и просто изучили несколько паттернов, не применяя их.

Разумно ожидать, что люди, претендующие на работу с вами, будут знать (или изучать) вещи, которые необходимы в вашем рабочем месте, независимо от того, являются ли они отраслевым стандартом или нет. В противном случае вы обрекаете себя на посредственность. Но остерегайтесь делать некоторые знания (или навыки) рабочим требованием, если это действительно не нужно.

Допустим, у вас есть два кандидата с примерно одинаковым фоном, один из которых может рассказать вам о шаблонах проектирования, а другой нет. Что это скажет вам о том, как они собираются выполнять на работе?

Вы говорите, что существующее программное обеспечение использует шаблоны проектирования. Это преимущество? Если да, то как? Ваша цель состоит в том, чтобы написанное новое программное обеспечение соответствовало существующим шаблонам, или чтобы новые шаблоны были введены? Зачем?

Я могу вспомнить старшего разработчика, который не знает о шаблонах проектирования в следующей ситуации:

1. Есть только одна книга о шаблонах дизайна. Это книга, которая сделала их популярными в первую очередь. Если человек не читал эту книгу, возможно, он не знает о шаблонах проектирования или, возможно, слышал о них, но не знает, для чего он предназначен.
2. Вместо этого они должны знать что-то вроде uml ....
3. Найти хорошую информацию о шаблонах дизайна из Интернета нелегко. Вам очень повезло, если вы попали на правильную веб-страницу с хорошим знанием шаблонов дизайна. Простой переход на программное обеспечение после 1995 года может заставить человека не знать о книге шаблонов проектирования, потому что книга старая.

Почему любой разработчик в среде без OO должен знать о шаблонах проектирования OO? Я работал в магазинах, занимаясь только Cobol, только PL / SQL, только Progress 4GL и т. Д. Принципы проектирования ОО там не имеют значения, я бы ожидал, что старшие в этих средах будут иметь соответствующие знания для этих сред, а не для проектирования ОО узоры.

Возможность бессмысленного цитирования из каталога шаблонов также не делает вас хорошим разработчиком (фактически, по моему опыту, он создает некоторые из худших фрагментов кода, которые я когда-либо видел). Тем не менее, это то, что вы ожидаете быть знаком «старшего разработчика». Я работаю в отрасли уже 15 лет, но не просите меня нарисовать диаграмму модели. Я никогда не уделял этому много времени, мне не нужно. Я приобрел достаточно опыта, чтобы найти то, что работает, без указания конкретного имени, и если мне нужно формальное определение, я знаю, где его искать (и да, у меня есть справочники в моей личной библиотеке). Это отличительная черта опытного разработчика, а не заурядного знания, полученного в результате написания некоторых школьных учебников.