Привет
Достаточно долгое время работаю программистом-системщиком удаленно.
На собеседованиях на оффлайн работу спрашивают различные навыки в том числе и проектирование . И вот тут проблемы нередко возникают. На работе обычно долго думаю размышляю как что то задизайнить, ищу ответы в интернете как другие делают, бывает проектирование и обдумывание занимает у меня неделю. И в итоге делаю и все работает, приложения "на одного человека". А вот так чтоб сходу решить задачу как того требует на собеседованиях — не могу.
Например недавно вот попросили игру морской бой спроектировать. Нарисовал на доске два поля с кораблями и не знаю с какой стороны подойти, описал классы для некоторых сущностей (корабль, игровая доска, элемент корабля ) и затык.
Или спроектировать приложение-электронную таблицу. Бросился было делать. Например сказал "Нам нужен двумерный массив". Сразу последовал вопрос "а если много ячеек? Сотни тысяч например? А как быть с тем что часто ячейки незаполнены? " Вроде детские вопросы и программист с парой лет опыта должен сходу решать, но я не нашелся что сказать. В голову лезли " ну пусть будет связанный список из ячеек, или std map где индексы ячейки будут ключами". Cпросили как разруливать конфликты когда ячейки ссылаются друг на друга. Вспомнилось что есть какие то алгоритмы поиска циклов на графах, но какие так и не сказал, интервьювер все ждал ответа хмыкнул и на этом все закончилось. Ну не сталкивался я с такими задачами на практике.
Был вопрос про проектирование систему вроде гит-а. Но я понятия не имею как он работает и какие вопросы задавать тому кто предложил это спроектировать и с какой стороны подойти к решению.
Такое чувство что мои семь лет опыта мне дали столько же сколько сколько получают за два года работы другие. Различные проблемы умею хорошо решать, постепенно находя ответы в процессе настоящей разработки. Но как проходить такие собеседования с проектированием? Что почитать, по какой литературе учиться?
Здравствуйте, Michaels1, Вы писали:
M>Например недавно вот попросили игру морской бой спроектировать. Нарисовал на доске два поля с кораблями и не знаю с какой стороны подойти, описал классы для некоторых сущностей (корабль, игровая доска, элемент корабля ) и затык.
а чего так? дальше просто смотришь на то, какие действия надо совершать и подправляешь шероховатости.
в итоге получится: корабль(список точек), доска, фабрика/валидатор для выставления на поле, игрок, интерфейс.
M>интервьювер все ждал ответа хмыкнул и на этом все закончилось. Ну не сталкивался я с такими задачами на практике. M>Был вопрос про проектирование систему вроде гит-а. Но я понятия не имею как он работает и какие вопросы задавать тому кто предложил это спроектировать и с какой стороны подойти к решению. M>Такое чувство что мои семь лет опыта мне дали столько же сколько сколько получают за два года работы другие.
это собеседование. никогда не знаешь, что за шаблон у человека в голове, с которым он сверяется.
M>Но как проходить такие собеседования с проектированием? Что почитать, по какой литературе учиться?
простой путь — это посмотреть, как оно сделано в существующих продуктах. там станет понятно, какие операции требуется совершать и какие есть требования по данным.
для этого годятся как книжки по архитектуре/проектированию, так и обычные статьи в интернете. последние, возможно, даже полезней.
вообще, за пару-тройку собеседований в одном направлении ты можешь узнать 95% вопросов, а потом это просто изучить дома
Здравствуйте, Michaels1, Вы писали:
M>Такое чувство что мои семь лет опыта мне дали столько же сколько сколько получают за два года работы другие. Различные проблемы умею хорошо решать, постепенно находя ответы в процессе настоящей разработки. Но как проходить такие собеседования с проектированием? Что почитать, по какой литературе учиться?
Это вопросы не по проектированию и архитектуре, а на знание классических алгоритмов и структур данных. Далеко не факт, что упомянутые на собеседовании приёмы реально используются или понадобятся в проектах — просто неопытному собеседователю легче устроить тупое тестирование вместо реального собеседования. Хорошее собеседование начинается с вопросов про предыдущие проекты и принятые в них технические решения.
Перечислю несколько книг, которые надо иметь в своей библиотеке в любом случае.
Книги по алгоритмам и структурам данных:
Томас Кормен и др. Алгоритмы: построение и анализ
Дэвид Соломон. Сжатие данных, изображений и звука
Альфред В. Ахо и др. Компиляторы. Принципы, технологии и инструментарий
Эндрю Таненбаум. Современные операционные системы
Книги по ООП:
Гради Буч и др. Объектно-ориентированный анализ и проектирование с примерами приложений
Э. Гамма и др. Приемы объектно-ориентированного проектирования. Паттерны проектирования
Мартин Фаулер. Архитектура корпоративных программных приложений
Эрик Эванс. Предметно-ориентированное проектирование
Мартин Фаулер. Рефакторинг. Улучшение существующего кода
Джошуа Кериевски. Рефакторинг с использованием шаблонов
Роберт Мартин. Чистый код
Здравствуйте, Michaels1, Вы писали:
M>Привет M>Достаточно долгое время работаю программистом-системщиком удаленно. M>На собеседованиях на оффлайн работу спрашивают различные навыки в том числе и проектирование . И вот тут проблемы нередко возникают. На работе обычно долго думаю размышляю как что то задизайнить, ищу ответы в интернете как другие делают, бывает проектирование и обдумывание занимает у меня неделю. И в итоге делаю и все работает, приложения "на одного человека". А вот так чтоб сходу решить задачу как того требует на собеседованиях — не могу.
Соглашусь с ответом, что тебе задавались вопросы по ООП, а не по проектированию. Тут главное подтянуть структуры данных(списки, хеши и т.п.), если с ними вдруг не дружишь, и не теряться в условиях стресса на собеседовании.
Чтобы научиться именно проектированию нужен опыт:
— участия в разработке крупного проекта, спроектированного опытными архитекторами.
— либо проектирования среднего-крупного проекта с нуля.
В конце концов приемы проектирования сходны, и поняв устройство нескольких проектов, сможешь проектировать сам. Как получить такой опыт работая именно системным программистом не знаю, так как все же у системного программирования своя специфика — устройство ОС отличается от устройства корпоративных приложений.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Michaels1, Вы писали:
M>Привет M>Достаточно долгое время работаю программистом-системщиком удаленно. M>На собеседованиях на оффлайн работу спрашивают различные навыки в том числе и проектирование . И вот тут проблемы нередко возникают. На работе обычно долго думаю размышляю как что то задизайнить, ищу ответы в интернете как другие делают, бывает проектирование и обдумывание занимает у меня неделю. И в итоге делаю и все работает, приложения "на одного человека". А вот так чтоб сходу решить задачу как того требует на собеседованиях — не могу. M>Например недавно вот попросили игру морской бой спроектировать. Нарисовал на доске два поля с кораблями и не знаю с какой стороны подойти, описал классы для некоторых сущностей (корабль, игровая доска, элемент корабля ) и затык.
Ну тут совсем несложно. Опишу в терминах С#. Заводим абстрактный класс корабль. У карабля должны быть координаты (x1,y1) и (x2,y2), либо нач. координаты, тип корабля (верт. или гор.) и длина. Короче -- либо декартова, либо полярная система координат. Все корабли унаследуются от этого класса, переопределяя соотв. координаты в зависимости от своего типа. Далее, вводим абстракцию доска или игровое поле. Сразу видятся два метода -- сгенерировать расположение фигур, и обработать выстрел соперника (bool GetUserShot(x,y) или bool ApplyUserShot(x,y)). В каждом из методов необходимо задействовать соотв. алгоритмы -- размещение фигур на доске (какое-нибудь динамическое программирование или что-нибудь вроде этого), и определять попал-непопал. Как выше уже сказано все это зависит от выбора структур данных для представления кораблей -- матрица, списки или еще что-то. Вероятно интервьюер хотел поговорить про детали реализации алгоритмов и как ключевые абстракции будут взаимодействовать.
M>Или спроектировать приложение-электронную таблицу. Бросился было делать. Например сказал "Нам нужен двумерный массив". Сразу последовал вопрос "а если много ячеек? Сотни тысяч например? А как быть с тем что часто ячейки незаполнены? " Вроде детские вопросы и программист с парой лет опыта должен сходу решать, но я не нашелся что сказать. В голову лезли " ну пусть будет связанный список из ячеек, или std map где индексы ячейки будут ключами". Cпросили как разруливать конфликты когда ячейки ссылаются друг на друга. Вспомнилось что есть какие то алгоритмы поиска циклов на графах, но какие так и не сказал, интервьювер все ждал ответа хмыкнул и на этом все закончилось. Ну не сталкивался я с такими задачами на практике.
Я бы и сам на такой вопрос растерялся, что ответить. В ms excel куча народа пилила кучу времени. Вероятно, это ни сколько разговор на тему ООП, сколько про алгоритмы.
M>Был вопрос про проектирование систему вроде гит-а. Но я понятия не имею как он работает и какие вопросы задавать тому кто предложил это спроектировать и с какой стороны подойти к решению.
Работает по принципу клиент-сервер с бд с поправкой на локальное хранилище у пользователя с его дальнейшей синхронизацией на сервере. Плюс куча утилит для эффективной работы с файлами и отслеживания изменений.
M>Такое чувство что мои семь лет опыта мне дали столько же сколько сколько получают за два года работы другие. Различные проблемы умею хорошо решать, постепенно находя ответы в процессе настоящей разработки. Но как проходить такие собеседования с проектированием? Что почитать, по какой литературе учиться?
Попробую дать совет от себя: видите программу, попытайтесь понять как она устроена, какие ключевые абстракции Вы бы использовали, в какие структуры данных эти абстракции организовали, какие бы Вы алгоритмы использовали и т.д. Уверяю Вас, что попадание было 95 из 100, ибо все инженеры мыслят подобно. За редким исключением. Т.е. просто представьте себя на месте разработчика программы и прикиньте, чтобы делали Вы.
Здравствуйте, Sharov, Вы писали:
S>Заводим абстрактный класс корабль. У карабля должны быть координаты (x1,y1) и (x2,y2), либо нач. координаты, тип корабля (верт. или гор.) и длина. Короче -- либо декартова, либо полярная система координат. Все корабли унаследуются от этого класса, переопределяя соотв. координаты в зависимости от своего типа. Далее, вводим абстракцию доска или игровое поле. Сразу видятся два метода -- сгенерировать расположение фигур, и обработать выстрел соперника (bool GetUserShot(x,y) или bool ApplyUserShot(x,y)). В каждом из методов необходимо задействовать соотв. алгоритмы -- размещение фигур на доске (какое-нибудь динамическое программирование или что-нибудь вроде этого), и определять попал-непопал. Как выше уже сказано все это зависит от выбора структур данных для представления кораблей -- матрица, списки или еще что-то. Вероятно интервьюер хотел поговорить про детали реализации алгоритмов и как ключевые абстракции будут взаимодействовать.
Выглядит как попытка натянуть ООП на глобус стрелять из пушки по воробьям. Для корабля достаточно его типа (который и определяет размер). Остальные параметры — это привязка корабля к доске, которую лучше в ней и хранить (например, как id корабля в клетках, которые он занимает).
По сути, для хранения позиции тут достаточно простой двумерной матрицы из интов (шотов/чаров) (а если навесить ограничение на отсутствие касаний бортами, то и булов) и счетчика живых клеток кораблей (чтобы не сканить всю доску для определения конца игры). Типы кораблей нужны только для генерации позиции (ну и для красивой отрисовки могут пригодиться).
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Sharov, Вы писали:
S>>Заводим абстрактный класс корабль. У карабля должны быть координаты (x1,y1) и (x2,y2), либо нач. координаты, тип корабля (верт. или гор.) и длина. Короче -- либо декартова, либо полярная система координат. Все корабли унаследуются от этого класса, переопределяя соотв. координаты в зависимости от своего типа. Далее, вводим абстракцию доска или игровое поле. Сразу видятся два метода -- сгенерировать расположение фигур, и обработать выстрел соперника (bool GetUserShot(x,y) или bool ApplyUserShot(x,y)). В каждом из методов необходимо задействовать соотв. алгоритмы -- размещение фигур на доске (какое-нибудь динамическое программирование или что-нибудь вроде этого), и определять попал-непопал. Как выше уже сказано все это зависит от выбора структур данных для представления кораблей -- матрица, списки или еще что-то. Вероятно интервьюер хотел поговорить про детали реализации алгоритмов и как ключевые абстракции будут взаимодействовать.
L>Выглядит как попытка натянуть ООП на глобус стрелять из пушки по воробьям. Для корабля достаточно его типа (который и определяет размер). Остальные параметры — это привязка корабля к доске, которую лучше в ней и хранить (например, как id корабля в клетках, которые он занимает).
Иметь базовый класс для корабля на будущее -- штука полезная, особенно для обхода всех кораблей. Чтобы это не было простой болванкой можно хранить координаты в базовом классе, ровно как кол-во подбитых клеток. С другой стороны, дублировать координаты на корабле и на доске смысла нет, поэтому, пожалуй,тут соглашусь с Вашими замечаниями.
L>По сути, для хранения позиции тут достаточно простой двумерной матрицы из интов (шотов/чаров) (а если навесить ограничение на отсутствие касаний бортами, то и булов) и счетчика живых клеток кораблей (чтобы не сканить всю доску для определения конца игры). Типы кораблей нужны только для генерации позиции (ну и для красивой отрисовки могут пригодиться).
Согласен, значения матрицы будут id корабля, либо 0. Если попали, то по id находим корабль и вычитаем счетчик клеток, после чего проверяем окончена игра или нет.
Здравствуйте, Sharov, Вы писали:
S>Иметь базовый класс для корабля на будущее -- штука полезная, особенно для обхода всех кораблей.
ИМХО, заделы "на будущее" без привязки к реальным сценариям использования, ведут лишь к бесполезному усложнению модели.
В простой реализации морского боя обход кораблей не нужен.
Здравствуйте, Sharov, Вы писали:
S>Иметь базовый класс для корабля на будущее -- штука полезная
иметь что-то на будущее без 100% уверенности в этом самом будущем — прямой путь к overengineering'у и деградации кодовой базы.
Топикстартеру:
самое важное в ООП — научиться его не использовать
Здравствуйте, antropolog, Вы писали:
A>Здравствуйте, Sharov, Вы писали:
S>>Иметь базовый класс для корабля на будущее -- штука полезная A>иметь что-то на будущее без 100% уверенности в этом самом будущем — прямой путь к overengineering'у и деградации кодовой базы.
Прям общий абстрактный класс у подобных сущностей -- это ужас-ужас-ужас, ага.
A>Топикстартеру: A>самое важное в ООП — научиться его не использовать
Ога, и получить процедурный стиль с методами в 10к LOC.
Кроме прочего там про GRASP.
Всю читать не надо, наверное. Только то, что покажется интересным или полезным.
Если для собеседований, то, видимо, желательно почитать про SOLID и паттерны.
Про паттерны, впрочем, полезно почитать и не для собеседований. Только смотреть на них не как на типовые решения для применения в своем коде,
а как на иллюстрации общих принципов и приемов на слегка обобщенных примерах.
Здравствуйте, Sharov, Вы писали:
A>>иметь что-то на будущее без 100% уверенности в этом самом будущем — прямой путь к overengineering'у и деградации кодовой базы. S>Прям общий абстрактный класс у подобных сущностей -- это ужас-ужас-ужас, ага.
Приписывать собеседнику слова, которые он не говорил, а затем их с жаром оспаривать, это конечно интересная манера вести беседу, но контрпродуктивная. Где я говорил что-то об абстрактных классах, или о том что это ужас? Перечитайте пожалуйста моё сообщение без эмоций и попробуйте понять его смысл.
S>Ога, и получить процедурный стиль с методами в 10к LOC.
Опять же, в моём сообщении не было и слова о стилях. Не говоря уже о том что связи между стилем(любым) и методами (кстати, методы, это же вроде из ООП понятие?) в 10KLOC нет никакой.
S>Cамое важное в ООП -- использовать его с умом.
Не использовать ООП там, где он не нужен, это подмножество "использовать с умом". Здесь я с вами солидарен.
Здравствуйте, Michaels1, Вы писали:
M>Такое чувство что мои семь лет опыта мне дали столько же сколько сколько получают за два года работы другие. Различные проблемы умею хорошо решать, постепенно находя ответы в процессе настоящей разработки. Но как проходить такие собеседования с проектированием? Что почитать, по какой литературе учиться?
По моему мнению, проблема не столько в навыке прохождения собеседования, сколько в реальном пробеле в знаниях. Вопросы тебе довольно простые задали, как мне кажется. Vladek выше посоветовал хорошие, правильные источники информации и от себя я бы добавил разве что The Architecture of Open Source Applications.
Здравствуйте, antropolog, Вы писали:
A>Здравствуйте, Sharov, Вы писали:
A>>>иметь что-то на будущее без 100% уверенности в этом самом будущем — прямой путь к overengineering'у и деградации кодовой базы. S>>Прям общий абстрактный класс у подобных сущностей -- это ужас-ужас-ужас, ага. A>Приписывать собеседнику слова, которые он не говорил, а затем их с жаром оспаривать, это конечно интересная манера вести беседу, но контрпродуктивная. Где я говорил что-то об абстрактных классах, или о том что это ужас? Перечитайте пожалуйста моё сообщение без эмоций и попробуйте понять его смысл.
Неправ, согласен. Но я связал overengineering с наличием общего абстрактного класс у подобных сущностный. Мне это показалось неверным.
S>>Ога, и получить процедурный стиль с методами в 10к LOC. A>Опять же, в моём сообщении не было и слова о стилях. Не говоря уже о том что связи между стилем(любым) и методами (кстати, методы, это же вроде из ООП понятие?) в 10KLOC нет никакой.
Если не применять ООП, то очень запросто скатиться к процедурному стилю, со всеми вытекающими. Метод есть процедура без возможностей ООП (сиречь полиморфизма).
S>>Cамое важное в ООП -- использовать его с умом. A>Не использовать ООП там, где он не нужен, это подмножество "использовать с умом". Здесь я с вами солидарен.
Здравствуйте, antropolog, Вы писали:
A>Топикстартеру: A>самое важное в ООП — научиться его не использовать
ООП оно про перевод решения задачи в код. То есть, сначала надо решить, фактически, спроектировать, а уже потом решение переводить в код согласно ООП или другой парадигме.
Вообще, Бертран Мейер утверждает, что ООП включает в себя ФП и некоторые другие парадигмы. С это точки зрения 'не использовать ООП' смешно выглядит
Здравствуйте, Michaels1, Вы писали:
M>Такое чувство что мои семь лет опыта мне дали столько же сколько сколько получают за два года работы другие. Различные проблемы умею хорошо решать, постепенно находя ответы в процессе настоящей разработки. Но как проходить такие собеседования с проектированием? Что почитать, по какой литературе учиться?
Есть книга, переведенная на русский язык, Cracking code interview. Это считай сборник задач на собеседованиях. Имеет смысл посмотреть.
M>Например недавно вот попросили игру морской бой спроектировать. Нарисовал на доске два поля с кораблями и не знаю с какой стороны подойти, описал классы для некоторых сущностей (корабль, игровая доска, элемент корабля ) и затык.
Для морского боя и вообще задач на проектирование надо начинать с вопросов, в зависимости от ответов будет меняться реализация. Например игра локально против компьютера, консольный вариант, сетевой будут работать совершенно по разному.
Цель — построить модель решения задачи. И далее её перевести в код.
Для морского боя смотришь действия каждого из игроков, что нужно для каждого действия и какой результат. Потом именно эти действия переводишь в код. Это будет решение задачи.
Например, сделать ход означает что
1 есть доска с кораблями
2 выбираем координаты
3 результат — попадание или промах.
Эта последовательность никогда не меняется. Нужно выбрать самую минималистичную модель корабля и доски. Из п.1..3 следует, что кораблю не нужны ни пушки, ни торпеды, ни снаряд, а только счетчик жизни. От доски требуется исключительно координаты и возможность определить, было ли попадание или нет.
Правило окончания игры — все корабли игрока потоплены. Это значит, что нужна возможность перебрать корабли игрока и если суммарная жизнь = 0, то игрок выбыл из игры. Минималистичная модель игрока — список кораблей.
Вот эти черновик решения. Теперь надо первести это в код. В ООП нужно оперировать классами и сообщениями. И здесь нужно определиться с подходом, кто кому чего будет слать.
Например — игрока корабль по координатам x-y убейся
А может так — доска пробуй пальнуть по координатам этого игрока
Или так — игрок стрельни по координатам доски другого игрока
Это уже дизайн решения, то есть, определяешься с принципом, по которому обязанности будут распределяться между сущностями.
Здесь ты решаешь, как будут связаны сущности. Это важный момент, т.к. с т.з. ООП совершенно без разницы, будет ли один класс Game с кучей простых филдов и методов, или же будет дробление на более мелкие классы. И то и другое — ООП.
Вопрос только в том, как ты структурируешь решение. Вот на собеседовании и нужно показать твои скилы в анализе проблемы и структурировании решения.
Собственно вся сложность — найти правильные вопросы
Автор(ы): Крэг Ларман
