Как бы вы оценили навыки объектно-ориентированного дизайна? [закрыто]

какие идеи или вопросы помогут вам определить навыки OOAD у человека.

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

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

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

Обсудите проблему открытого дизайна с человеком. Посмотрите, как он / она приступает к построению модели системы, какие вопросы задаются, как меняется дизайн в ответ на новую информацию.

Отличный пример, о котором Стив Йегге упомянул в одном из своих постов в блоге, - попросить человека придумать объектную модель для XML.

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

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

Спросите его, например, об использовании в его прошлом опыте, также может помочь.

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

Попросит его записать бизнес-объекты, классы и интерфейсы / методы для комнаты или любого другого виртуального объекта.

Если возможно, попросите образец кода.

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

В конечном итоге то, что вы тестируете - дизайн - субъективно. Таким образом, ваша оценка должна быть открытой, чтобы учесть несколько возможных хороших решений, а не только одно. Затем подумайте о возможных изменениях требований, которые могут вызвать изменение интерфейса: как они справляются с этим?

Прочитайте книгу Head First Design Patterns. Все примеры в книге начинаются с объектно-ориентированной задачи и затем заканчиваются в шаблоне проектирования. Они также рассказывают, почему некоторые концепции ООП достигают ограниченных результатов и почему одни лучше, чем другие.

Несмотря на то, что книга Design Pattern, эта книга полна проблем ООП :-)

Начните с простого: что такое ООП?

Вы можете начать с вопроса об основных предпосылках ООП: абстракция, полиморфизм, наследование и инкапсуляция. Хорошая пища для размышлений, чтобы согреть их.

Дай им проблему

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

Возможно динамическое подтверждение ввода текста. Вы хотели бы иметь возможность проверять вводимый символ за символом, чтобы увидеть, является ли это действительной датой, временем или датой и временем в формате ISO8601. Вы получаете копию входной строки каждый раз, когда нажимается клавиша, и вы можете вернуть логическое значение, чтобы указать, остается ли текст хорошим хотя бы в одном из форматов. Попросите их обсудить и наметить проект, используя принципы ОО.

К тому времени, как вы закончили болтать о

1. Контроллер (то, что запускает события изменения и оценивает ответы),
2. Наблюдатель (валидаторы отвечают на события изменения),
3. Стратегия (каждый валидатор представляет свой способ определения правильности ввода),

тогда у вас будет довольно хорошая идея, если они поймут OOD.

Дайте им ту же проблему снова, но на этот раз попросите другой дизайн

Теперь попросите их перепроектировать систему без использования шаблона Observer (если они упомянули об этом) - они могут выбрать подход с цепочкой ответственности или, возможно, шаблон Command. Тебя это не волнует, ты знаешь, что у них есть разумное понимание вовлеченных принципов.

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

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

Да, вы могли бы попросить их сесть и нарисовать UML, да, вы могли бы задать им вопросы для поиска по некоторым особенностям реализации ООП, чтобы посмотреть, смогут ли они «взяться за дело».

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

† Глубокое знакомство и отсутствие связи с кодом помогают: семья использует ванную комнату по утрам; готовить обед; автобусный маршрут на работу; сборка авто.

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

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