Чи розумно очікувати, що старший розробник знає, що таке структури дизайну OOP? [зачинено]

Я готую запитання до співбесіди на вищу посаду з розвитку. Завдання буде включати в себе об'єктно-орієнтований дизайн, а існуюче програмне забезпечення використовує шаблони дизайну, тому я хотів би попросити кандидатів пояснити кілька моделей дизайну, які вони знають, вони використовували, як вони їх застосовували, чому вони використовував їх тощо. Однак у попередніх інтерв'ю, коли я запитував старших розробників, які мають принаймні 5-10 років досвіду роботи з моделями дизайну, майже ніхто ніколи не чув про них. Я думаю, що два з двадцяти розробників могли назвати єдиний шаблон дизайну (Singleton та MVC відповідно).

Отже, моє запитання: чи є сенс задавати ці питання? Або це настільки незрозумілий предмет, що ви не можете очікувати, що нові наймачі вже їх знатимуть?

Якщо старший розробник має попередній досвід роботи з моделями дизайну, чи ви сказали б, що дизайнерські зразки - це така проста тема, що кожен гідний розробник може підібрати їх під час навчання? Якщо так, то які питання ви б замість цього не задали, щоб оцінити їхні дизайнерські здібності?

Додати Після прочитання відповідей, я повинен дати кілька роз'яснень:

• Робота призначена для розробника .NET з досвідом роботи в OOP / OOD
• Існуючий код використовує назви класів, як IParameterGraphVisitorі IStorageFactoryу багатьох місцях
• Як ви запитуєте людей про їхній минулий досвід роботи з створеними ними проектами OO, якщо у них немає словникового запасу, щоб пояснити свої проекти? Це те, що я хочу зробити, і все, що я можу придумати, - це "будь ласка, намалюйте ієрархію дизайну / об'єкта вашого останнього проекту на дошці".

Можливо, вони їх знають. Вони просто можуть не знати їх як «дизайнерські зразки»; тобто вони не можуть бути знайомі з академічною термінологією для таких речей. Те, що ви розглядаєте як "державну машину", може бути просто здоровим підходом до проблеми старшого, більш досвідченого програміста. Наприклад, я ніколи не приділяв великої уваги «моделям дизайну», але коли я дізнався, що таке Державна машина, мені довелося сміятися, тому що роблю це роками. Хто знав, що я такий академік? Я завжди просто вважав це основним навиком кодування, а не «дизайнерським зразком».

Справа не в тому, щоб ваші досвідчені розробники знали умови підручника для речей; натомість запитайте їх, як вони структурувати класи чи як вони підійдуть до завдання.

Ваші очікування цілком розумні для старшого розробника ОО. Той, хто називає себе, що, не знаючи шаблонів дизайну, просто демонструє, що досвід не приносять автоматично минулі роки :-( Звичайно, там багато розробників, які провели роки чи навіть десятиліття на полі, не чуючи ніколи про дизайн шаблони - це лише показує, що вони не були зацікавлені у вивченні нових ідей, вдосконаленні себе та прийнятті кращих практик.

Якщо старший розробник має попередній досвід роботи з моделями дизайну, чи ви сказали б, що дизайнерські зразки - це така проста тема, що кожен гідний розробник може підібрати їх під час навчання?

Досвід ІМО налічує чимало. Теоретично, гідний розробник може прочитати «Шаблони дизайну» у книзі чи навіть у Вікіпедії та зрозуміти основну концепцію за 15 хвилин. Однак правильне застосування концепцій забирає важкий досвід. Легко захоплюватися візерунками, намагаючись втиснути їх у кожен можливий фрагмент коду, l'art pour l'art. Їх також легко відмовити, сказавши, що "візерунки - це не срібна куля, просто використовуйте найпростішу річ, яка могла б спрацювати". Пошук середини між двома крайнощами, дізнавшись, коли і як використовувати шаблони для вирішення реальних проблем, а коли не використовувати їх, потребує багаторічного досвіду .

які питання ви б замість цього не задали, щоб оцінити їх дизайнерські здібності?

На згоду з вищезазначеним, я лише додав би ці питання до вашого списку:

• Які недоліки дизайнерських моделей (загалом і тих, про які вони прямо говорять)?
• Коли їх не використовувати, і чому?

Оновлення

@GrandmasterB має гарний момент у тому, що деякі розробники можуть використовувати конкретні шаблони дизайну, не знаючи їх назви. Певним чином він правий у тому, що це питання термінології / спілкування. Однак, інша сторона монети полягає в тому, що це справді питання щодо термінології / комунікації :-) Тобто, одна з головних переваг дизайну шаблонів - надання загальної лексики розробникам, значно покращуючи спілкування . (Спробуйте пояснити основну ідею адаптера, не використовуючи власне слово або його синоніми "обгортка" та ін!) Так яким би не був талановитий і знаючий кандидат, не знаючи широко прийнятої термінології, він введе проблему спілкування. у вашій команді.

Старший розробник? Безумовно. Молодший повинен. Мені 15 років, не маю формальної освіти з цього питання і навіть я їх розумію. Не тільки розумно розраховувати, що вони їх знають, було б неприйнятно, якби вони цього не зробили. Якщо припустити, що вони знають щось про об'єктно-орієнтоване програмування, що, найімовірніше, роблять.

В інтерв'ю вам слід запитати, що критично важливо знати кандидату, щоб виконати роботу.

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

Якщо, з іншого боку, ви хочете, щоб вони відображали відповідні робочі знання з архітектури програми, я думаю, що вам краще поставити перед ними проблеми і запитати їх, як би структурувати код. Якщо вони дадуть вам відповідне рішення, тоді ви маєте доказ, що вони це знають, незалежно від використовуваної назви.

Щоразу, коли я беру інтерв'ю для вищих посад, вони, як правило, є більш "практичними", ніж питання Q&A. Я хочу чітко продемонструвати майстерність та комфорт у програмуванні. Я також хочу міцного підґрунтя в концепціях CS, що означає більш загальні навички застосування таких понять, як інкапсуляція, алгоритми, з'єднання / згуртованість тощо. Досвід та знайомство з багатьма мовами та парадигмами.

Залежить від сфери їхньої експертизи. Я не очікував, що вбудований розробник C знає багато про шаблони дизайну. Якщо ми говоримо про розробник Java або .NET, вони повинні бути знайомі з моделями дизайну, і особливо, як не надто захоплюватися ними.

Якщо припустити, що ви прагнете стажу в OOP, відповідь, безумовно, так. Шаблони дизайну є лексиконом мови OOP.

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

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

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

Поставивши запитання на кшталт "спроектуйте мені текстовий редактор" із подальшими поданнями на кшталт: "Як ви збираєтесь підтримувати вбудовані об'єкти, такі як зображення? Жирний і курсивний? Скасувати?" Напевно, ви, зрештою, почуєте достатньо, щоб розпізнати шаблон команд, складений візерунок, шаблон пам’яті та кілька інших людей навіть з короткою розмовою.

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

Я, на жаль, працював на когось, для кого кожне використання схеми дизайну потрібно було пояснювати та обґрунтовувати не через належну ретельність, а тому, що він їх просто не знав. Це не весело. Але більшість серйозних розробників випадково чи проектують, дізнавшись найменування найбільш часто використовуваних моделей OO, якщо нічого іншого, а більшість розробників програмних програм, які варті своєї солі, принаймні знають щось про найпоширеніші моделі PoEAA.

Розумні. Однозначно. Необхідні. Ні

Я запитую потенційних кандидатів, чи знають вони шаблони дизайну. Це лише один із декількох критеріїв, який слід зважити в цілому. Не забувайте про загальну картину.

Так, багато розробників несвідомо використовують деякі шаблони дизайну, без сумніву.

Тому я не задаю це питання.

Важливо знати, що я можу швидко та ефективно спілкуватися з іншим розробником. Я не хочу витрачати 20 хвилин на дошці, пояснюючи державну машину, лише щоб виявити, що вони "раніше її використовували, але ніколи не знали, як її назвати". Це не продуктивно.

Вони також допомагають у процесі рефакторингу. Переглянувши код, можна випадково реалізувати деяку форму заводського зразка, але фабричний шаблон GoF витримав випробування часом. Ось чому його модель заводу, які не ЧЕРГОВИЙ р (винаходити колесо не є кращим, Joel на програмне забезпечення має багато на недоліки цього).

Команда, яка використовує та визнає важливість моделей дизайну, підвищує комунікацію та продуктивність. Якщо ваша команда як підрозділ не використовує dp, вони втрачають свою актуальність.

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

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

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

Є розробники з досвідом 5-10 років і є старші розробники. Вони зовсім не одне і те ж. Так, якщо ви наймаєте на старший рівень, і ви очікуєте, що люди знатимуть та використовувати схеми дизайну, то я б не наймав старшого, який не був їм знайомий. Це було б як найняти фахівця з бази даних, який не розумів лівих приєднань. Це досить основні речі для справжнього старшого розробника. Я, мабуть, найняв би молодшого чоловіка.

Так, вони повинні бути добре знайомі з цим терміном і навіть повинні мати можливість назвати декілька моделей, але не допускайте помилок плутаючи теоретичні знання з досвідом.

Є багато людей, які перед інтерв'ю придумуватимуть дизайнерські шаблони, і можуть їх згорнути з коротким описом - але це лише теорія. Це справжній старший розробник, який може визначити, коли використовувати його або без знання формальної схеми вирішить проблему класичним дизайнерським малюнком.

Найкращий спосіб перевірити - нехай вони спроектують щось перед вами і задають питання зондування. Старший розробник - це той, хто може думати природно на рівні абстракції. Це люди, які "створюють" дизайнерські зразки.

Як і клас Peopleware, який говорить про те, щоб найняти жонглера, не просячи жонглювати - просто тому, що вони кажуть, що не можуть, це не означає багато .. спробуйте їх.

Як уже було сказано, я також вважаю, що це нормально, якщо вони не пам’ятають напам'ять модниць. Але оскільки це вища посада, вони повинні знати, коли застосовувати схему для вирішення проблеми оптимально, а не використовувати найгірші рішення. Таким чином, задайте їм проблему, яку слід вирішити за допомогою шаблону (наприклад, як створити об’єкт без жорсткого кодування його класу, як отримати доступ до елементів об'єкта, не маючи деталей про його реалізацію тощо) і подивіться, як вони нападуть на нього.

Безумовно, вони повинні знати закономірності, але не обов'язково мовлення.

Наприклад, MVC має багато дуже подібних альтернатив, таких як PAC, 3-рівень. Кілька років тому ще одним популярним словом для MVC була "Модель 2". Я насправді знаю дуже хороших розробників, які прекрасно знають цю модель, але не знали, що поточна модна мова для неї - MVC.

Дуже просто: якщо ви їх використовуєте, то вам потрібно запитати своїх кандидатів. Якщо вони дійсно знають зразки, то їм слід додати кілька плюсів; але не знаючи, не варто обов'язково їх відкидати, особливо якщо вони виявляють хороші навички OOD. Розробники, які займалися проектами технічного обслуговування, навряд чи знають багато про шаблони дизайну порівняно з тими, хто займався їх розробкою. Це також залежить від того, чи їх навчали моделей дизайну в коледжі. На мій досвід, навряд чи вони будуть. Більшість університетів та приватних курсів навчають вас OOP, але не OOD. Шанси на те, що вони будуть вивчати ДП, ще менші.

Особисто я не вивчав ДП, поки мій проект також не вимагав від мене. Вже тоді я виявив, що я використав декілька зразків, принаймні аналогічним чином, якщо не в точній формі, описаній у книзі. Я був здивований, дізнавшись, що вони були кодифіковані. Тому шукайте хороших дизайнерських навичок, якщо вони не знають DP. Якщо вони знають DP, то ймовірно, що вони хороші в дизайні, але все ж перевіряють їх. Вони, можливо, просто озвучили якесь слово про ДП або дізналися від якогось інсайдера і просто вивчили кілька моделей, не застосовуючи їх.

Для вас розумно розраховувати, що люди, які подають заявку на роботу з вами, будуть знати (або вчитися) речі, необхідні у вашому робочому місці, незалежно від того, є вони галузевим стандартом чи ні. Інакше ви прирікаєте себе на посередність. Але будьте обережні, щоб певні знання (або вміння) були вимогою до роботи, якщо це насправді не потрібно.

Скажімо, у вас є два кандидати з приблизно однаковим походженням, і один вміє розповісти вам про дизайнерські зразки, а інший - ні. Що це скаже вам про те, як вони збираються виконувати цю роботу?

Ви кажете, що існуюче програмне забезпечення використовує шаблони дизайну. Це перевага? Якщо так, то як? Чи є вашою метою, щоб нове програмне забезпечення, написане відповідно до існуючих моделей, чи було введено нові зразки? Чому?

Я можу подумати про старшого розробника, який не знає про шаблони дизайну в такій ситуації:

1. Існує лише одна книга про схеми дизайну. Саме книга зробила їх популярними в першу чергу. Якщо людина не прочитала цієї однієї книги, можливо, вона не знає про шаблони дизайну, або, можливо, чула про них, але не знала належним чином для чого вони
2. Натомість вони мали б знати щось на кшталт uml ....
3. Знайти хорошу інформацію про моделі дизайну в Інтернеті непросто. Вам дуже пощастило, якщо ви потрапили на правильну веб-сторінку, яка має хороші знання про шаблони дизайну. Просто перехід на програмне забезпечення після 1995 року може змусити людину не знати про дизайнерську схему книги, оскільки книга стара.

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

Можливість бездумно цитувати з каталогу шаблонів також не робить вас хорошим розробником (адже, на мій досвід, це дає найгірші фрагменти коду, які я коли-небудь бачив). І все-таки саме те, що ви очікуєте, буде знаком "старшого розробника". Я працюю в цій галузі вже 15 років, але не вимагайте від мене малювати схему. Я ніколи не приділяв їй багато часу, мені не потрібно. Я набув достатнього досвіду, щоб знайти те, що працює, не вказуючи конкретного імені, і якщо мені потрібно формальне визначення, я знаю, де його шукати (і так, у мене є довідники в моїй особистої бібліотеці). Це позначка досвідченого розробника, а не глибокі знання, отримані від набивання деяких шкільних книг.