які розуміння чи запитання приведуть вас до визначення навичок OOAD людини.
Запитайте їх, якщо вони краплять свої.
—
Робота
які розуміння чи запитання приведуть вас до визначення навичок OOAD людини.
Відповіді:
Ви можете показати дещо напіввизначений проект простого завдання та обговорити, що він робить, що добре і що погано в ньому, чи достатньо він гнучкий, що можна вдосконалити та як.
Якщо вам потрібно розпочати дискусію, запитайте, що людина думає про якийсь аспект коду, але не з головним питанням.
Важливо пам’ятати, що дискусія важлива, а не те, що ви знали відповіді заздалегідь. Будь-який гідний розробник повинен мати можливість вказати на щось про код, про який ви навіть не думали раніше.
Обговоріть із людиною відкриту проблему дизайну. Подивіться, як він / він переходить до побудови моделі системи, які питання задаються, як змінюється дизайн у відповідь на нову інформацію.
Чудовий приклад - згадуваний Стівом Йегге в одному зі своїх публікацій в блозі - це попросити людину придумати об'єктну модель для XML.
Маючи хороші знання всіх найпопулярніших моделей дизайну, можна довести, що кандидат фактично шукав рішення своїх дизайнерських проблем.
Вміти їх обговорювати і знати, коли їх застосовувати чи ні - це хороший показник того, що він їх розуміє.
Попросити його, наприклад, звичаїв у його минулому досвіді також може допомогти.
Не дайте вікторини словника. "Визначити спадщину" або "назвіть 3 особливості дизайну ОО" - це питання, які нічого не скажуть про навички особистості, лише про те, як довго він / вона останній раз читав підручник. Я зустрічав декількох чудових програмістів, які використовують ці навички щодня, але задушиться, якби попросили дати формальне визначення.
Якщо можливо, попросіть зразок коду.
В іншому випадку знайдіть який-небудь процедурний код, який можна використати як приклад (або погано розроблений код OO), а потім запитайте їх, як вони переробляти, узагальнювати та вдосконалювати. Переконайтеся, що програма має додатковий контекст, щоб перероблення могло бути значущим.
Зрештою, те, що ви тестуєте-- дизайн - є суб'єктивним. Таким чином, ваше оцінювання повинно бути відкритим, щоб передбачити кілька можливих хороших рішень, а не лише одне. Потім подумайте про можливі зміни до вимог, які б змусили змінити інтерфейс: як вони з цим поводяться?
Прочитайте книгу «Голова перших моделей дизайну». Усі приклади в книзі починаються з об'єктно-орієнтованої проблеми і потім закінчуються в дизайні. Вони також розповідають, чому деякі концепції ООП досягають обмежених результатів і чому деякі кращі за інші.
Незважаючи на те, що книга «Шаблон дизайну», ця книга сповнена проблем OOP :-)
Почнемо з просто: що це за OOP?
Ви можете почати, запитавши про основні умови OOP: абстракція, поліморфізм, успадкування та інкапсуляція. Гарна їжа для роздумів, щоб зігріти їх.
Дайте їм проблему
Далі, представіть їм проблему, яка, ймовірно, включає закономірності. Не обов'язково називати або використовувати шаблони, але їх підхід, швидше за все, дасть певні результати, якщо вони мають досвід роботи в цій галузі.
Можливо, динамічна перевірка введення тексту. Ви хочете мати змогу перевірити символ введення за символом, щоб побачити, чи це дійсна дата, час або дата та час у форматі ISO8601. Ви отримуєте копію вхідного рядка кожного разу, коли натискається клавіша, і ви можете повернути булеве значення, щоб вказати, чи залишається текст хорошим хоча б в одному з форматів. Попросіть їх поговорити та накреслити дизайн, використовуючи принципи дизайну ОО.
На той час, коли ви закінчили спілкуватися
то у вас буде досить гарна ідея, якщо вони зрозуміють, що OOD.
Поставте їм знову ту ж проблему, але цього разу попросіть інший дизайн
Тепер попросіть їх переробити систему без використання шаблону спостерігача (якщо вони про це згадували) - вони можуть обрати підхід до ланцюжка відповідальності або, можливо, шаблону команд. Вас не цікавить, які ви знаєте, що вони розуміють принципи, які вони стосуються.
Навіть якщо вони не застосовують підхід, заснований на шаблоні, просто прослуховування того, як вони намагаються розбити проблему на відповідну функціональність , дасть результати, які ви шукаєте.
Я схильний вибирати сценарій реального світу, щось добре відоме кому-небудь †, і прошу їх визначити сутності; залучені актори; які взаємодії існують між ними; там, де загальні риси можуть бути абстраговані; які властивості потрібно враховувати.
Так, ви можете попросити їх сісти і намалювати UML, так, ви можете задати їм запитання щодо певних специфік впровадження OOP, щоб побачити, чи можуть вони "вдарити на землю".
Але те, що роботодавцю дійсно потрібно в їх команді, є розум, який розуміє пов'язані з цим поняття і може застосувати їх до будь-яких результатів. Особливості можна дізнатися швидко, коли вбудовуються поняття.
† Глибоке знайомство та відсутність зв’язку з допомогою коду: використання сім’єю ванної кімнати вранці; готую вечерю; автобусний маршрут до роботи; складання автомобіля.
Щось, здається, працює досить добре, а насправді займає лише кілька секунд: попросіть їх розробити модель об'єкта. Не важливо для чого. Це може бути абсолютно тривіально. Насправді це, мабуть, має бути тривіально, щоб не перетягувати тест без потреби.
Якщо перше, що вони пишуть, - це об'єкт, вони вже випереджають 99% своїх ровесників у розумінні ОО. Якщо перше, що вони пишуть, - це клас, будь ласка, попросіть їх вийти та відправити наступного кандидата та поміркуйте, чому це називається OOP, а не COP.