Тестовое задание по объектно-ориентированному проектированиюЕсли вы находитесь на этой страничке, то вероятно вы получили тестовое задание по объектно-ориентированному проектированию (или OOP/OOD, как это часто указывается в резюме кандидатов). Если это так, то прочитайте эту статью до конца. Мы вам предложили пройти этот несложный тест по объектно-ориентированному проектированию, потому что способность разработчика к такому проектированию становится критически важной, как только сложность проекта начинает превышать несколько десятков тысяч строчек. Это утверждение легко пояснить на следующем примере: Собачью будку вполне возможно построить безо всякого предварительного проектирования и с минимумом инструментов. Или как любят говорить программисты: "Я держу дизайн всей системы в голове и уточняю его процессе реализации". Даже если заказчик будки обнаружит дефекты, то их можно будет легко устранить на месте. Очевидно, риск провала проекта "Будка для Тузика" минимальный. Все довольны, включая Тузика. Но если речь идёт о небоскрёбе, то приведенная выше технология строительства не сработает, поскольку здесь на многие порядки возрастает цена ошибки проектирования. Концептуально небоскрёб не отличается от собачьей будки. Это тоже стационарное укрытие для биологических объектов от непогоды. То, что отличает небоскрёб от собачьей будки – это его качество и сложность. Поэтому, перед постройкой небоскрёба проводится большое количество исследовательских и проектно-конструкторских работ с привлечение лучших специалистов, с использованием последних достижений строительной науки и самых современных средств автоматизированного проектирования. И если в процессе строительства небоскрёба обнаружатся ошибки проектирования, то исправление ситуации обойдётся очень и очень дорого. Поэтому никто не приступает к строительству небоскрёба "держа его дизайн в голове и уточняя в процессе реализации". В программировании, в качестве "собачьих будок" можно рассматривать небольшие фрилансерские проекты сложностью до 50-тысяч строчек кода и с одним программистом. Действительно, часто дизайн такой системы несложно удерживать в голове, а исправление дефектов, найденных заказчиком, всё еще не отнимает много времени. Проблемы начинаются, когда проект продолжает развитие и в него добавляются новые разработчики. Для стороннего взгляда новых разработчиков, в большинстве случаев, ваш проект будет казаться бесструктурным месивом кода и концепций, представляющим монолитную конструкцию, которую невозможно разбить по частям и распределить среди участников проекта. Новые разработчики будут настаивать на том, чтобы всё переделать, а вы будете до последнего продолжать защищать свою архитектуру. Расстроенный заказчик, вообще не будет знать, что ему теперь делать. Скорее всего, получив горький урок, он возьмёт управление на себя, насколько у него это получится, и начнет настаивать том, чтобы впредь документировался весь код, начнёт внедрять громоздкие техпроцессы, которые ему покажутся подходящими, всяческие драконовские методы управления и т.п. Обычно, в таких ситуациях сложно сказать, чья здесь вина. То ли ваша, то ли слишком предвзятых новых разработчиков (их тоже можно понять, ведь никому не хочется разбирать чужой код), то ли заказчика, который слишком сильно вам доверился. Скорее всего, виноваты все поровну. Приведенных выше проблем, с хорошей вероятностью можно было бы избежать, если архитектура системы была бы спроектирована заранее по всем правилам: с подсистемами, c интерфейсами, с уровнями абстракции, событиями и подписчиками на события, с уместным применением шаблонов проектирования и архитектурных шаблонов, с учетом расширяемости, дрейфа требований, причуд заказчика, разработчиков, других заинтересованных сторон и т.п. Я сильно сомневаюсь, что удачную архитектуру можно спроектировать на ходу в голове и уточнять по мере реализации всё еще продолжая держать её в голове. Как минимум таких гениев я пока не встречал. Теперь сами подумайте, кого вы привлечете к работам, связанным с проектированием небоскрёба? Специалистов с 5-летним опытом работы в области строительства небоскрёбов? Или специалистов с 25-летним опытом в области строительства собачьих будок? Experience vs qualification. Поэтому, возьмите UML редактор и докажите, что в программировании вы строитель небоскрёбов! Как выполнять тестовое задание по объектно-ориентированному проектированиюПоскольку объектно-ориентированное проектирование это в основном проектирование сверху вниз, то его можно выполнять с любой степенью детализации. Степень детализации зависит от того, сколько времени вы решили потратить на тестовое задание и как быстро вы соображаете. Тестовое задание составлено таким образом, чтобы его выполнение до той степени детализации, при которой объектный дизайн можно отдавать кодерам на реализацию, заняло бы у квалифицированного программиста около 2-х часов. Чем более удачные и детальные UML-диаграммы вы нам предоставите, тем будет выше оценка тестового задания и выше вероятность того, что вопрос о сотрудничестве с вами решится в положительную сторону. От Вас мы ожидаем следующие артефакты:
Советы:
См. еще Часто задаваемые вопросы. |