Человек рисует два кружочка — "это клиент, а это — сервер. Давайте реализуем их взаимодействие. Пускай клиент отправляет файл, а сервер его проверяет и возвращает результат — валидный или битый".
— окей, клиент и сервер — это разные приложения или что?
— да, разные приложения
— а взаимодействовать каким способом?
— да как хотите, хоть через файл на диске
— окей, пускай файл на диске
... обсудили протокол через временный каталог на диске ...
(удивляюсь — зачем такую простую задачу задавать?)
Открываю редактор, пишу функцию main, которая берёт имя файла в качестве аргумента, пишет его имя в текстовый файл во временном каталоге...
Интервьюер: стоп, стоп, а чего это вы сразу функцию main решили написать?
Я: так у нас примитивный алгоритм, зачем тут что-то ещё?
И: а может стоит интерфейсы определить?
Я думаю: странное извращение: плодить сущности для такого говна, ну ладно...
В общем, пришли к обсуждению классов, интерфейсов, наследования, виртуальных функций, особенностей конструкторов и т.п. На все вопросы был дан правильный ответ. От них пришёл ответ о том, что у меня мало опыта.
Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
проблема то пустяковая но вы ведъ её и не в реале решитъ должны были.
это ведъ именно СОБЕСЕДОВАНИЕ и нужно показатъ свои знания на простом примере
без шаблонов но с классами и интерфейсами, думаю даже требовалосъ как раз схематическое решение а не рабочий код в мейне. опытный программист начинает с объектов и интерфейсов а не сразу мысли в коде одной функции излагатъ.
вам нужно на простом примере показатъ как вы подходите к выполнению задач в принципе
On 13.03.2013 16:59, pik wrote:
> без шаблонов но с классами и интерфейсами, думаю даже требовалосъ как > раз схематическое решение а не рабочий код в мейне. опытный программист > начинает с объектов и интерфейсов а не сразу мысли в коде одной функции > излагатъ.
Ждемс изложения правильного решения оного. Ждемс, ждемс.
On 13.03.2013 16:45, pkl wrote:
> Где тут прокол — мне надо было сразу догадаться, что для пустяковой > проблемы следует нагородить умных универсальных интерфейсов с шаблонами > или им следовало точнее задавать вопрос? ))
Ну и по сути. Этот собеседователь просто хотел увидеть от тебя точно
такое же решение, как сделал бы он. Все.
Очень многие начальники, тем более собеседователи, не знают и не
понимают кого они ищут и ищут-ли вообще, поэтому очень часто они ищут
копию себя. И если ты не показываешь им такие же подходы, как бы сделали
они — ты не подходишь.
pkl>В общем, пришли к обсуждению классов, интерфейсов, наследования, виртуальных функций, особенностей конструкторов и т.п. На все вопросы был дан правильный ответ. От них пришёл ответ о том, что у меня мало опыта. pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
Очевидно же что мало )))
Ну сам посуди, вот сидит команда, в вконтактике чатится, кывт троллит, на хабре карму сливает... тут ты такой быстрый всё сразу раз и сделал, без одобренной многослойной архитектуры и необходимых согласований. Команда что получается, идиоты? Или вот допустим компания зарабатывает на бараночасах, то есть чем больше баранов числится в проекте и чем дольше он тянется, тем больше инкам. Вдруг ты тут такой красивый раз и сразу всё сделал. Клиент конечно будет в восторге, но ты то зачем в такой компании нужен? Хотя компании то ты может и нужен, кто то же должен делать то на чём бараны числятся, но вот интервьювер, который вероятно сам кто-то типа лида, скорее всего в таком раскладе не заинтересован.
[disclaimer]
Всё написанное выше очевидно не имеет никакого отношения к реальности, возможные совпадения стопроцентно случайны.
[/disclaimer]
On 13.03.2013 17:08, pik wrote:
> решения чего? он ведъ сам понял что подход был неверным вот и правилъно > понял на будущее
Так верный то какой он не понял. Вот и пришел сюда спросить.
Здравствуйте, Vzhyk, Вы писали:
V>Так верный то какой он не понял. Вот и пришел сюда спросить.
сюда пришол за подтверждением своей догадки
очевидно ведъ что на собесдовании надо себя удачно "продатъ" а это включает и "следует нагородить умных универсальных интерфейсов"
Здравствуйте, pkl, Вы писали:
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
Имхо прокол в том что были показаны знания, а требовался опыт.
pkl>>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? )) Kvd>Имхо прокол в том что были показаны знания, а требовался опыт.
Вполне возможно, но мало вероятно, что от испытуемого требовалось послать предложения о множестве умных универсальных интерфейсов в корзину, и настоять на простом решении? ))) Хотя, для этого опыта и знаний мало будет, нужно ещё кое что.
pik>сюда пришол за подтверждением своей догадки pik>очевидно ведъ что на собесдовании надо себя удачно "продатъ" а это включает и "следует нагородить умных универсальных интерфейсов"
Кому очевидно? На собеседовании нужно быть собой. Если же перед тобой мыльный пузырь, который сам не понимает чего спрашивает, то тонко (или толсто) его троллить и больше туда не возвращаться. Такое вот у меня ИМХО )))
Здравствуйте, pkl, Вы писали:
pkl>От них пришёл ответ о том, что у меня мало опыта.
Ну правильно ответили. Будь у Вас опыт, Вы бы знали, что любой системе, которой сегодня достаточно взаимодействовать через файл, завтра обязательно потребуется работа в локальной сети, а послезавтра — в интернет. Причем буквально на днях в вэбсервисах обнаружился фатальный недостаток, а самым модным внезапно стал HTTP++. И будете Вы свою "main" 100500 раз переписывать, превращая проект в...Ну Вы знаете во что.
AS>Кому очевидно? На собеседовании нужно быть собой. Если же перед тобой мыльный пузырь, который сам не понимает чего спрашивает, то тонко (или толсто) его троллить и больше туда не возвращаться. Такое вот у меня ИМХО )))
вот это "бытъ собой" надо уметъ максималъно хорошо продатъ. пузыръ надуватъ не надо но свои знания надо уметъ даже лучше чем естъ преподнести. собеседование это игра причём с обеих сторон, надо правила этой игры знатъ и бытъ хорошо к этому готовым т.е. говоритъ то что от тебя ожидают а не так как тебе хочется. в конце концов вы желаете получитъ контракт или нет? у вас естъ конкуренция, вы должны победитъ
Здравствуйте, pkl, Вы писали:
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
Примерно. Я бы уже после первого вопроса насторожился, термины "клиент" и "сервер" вполне однозначны и общеупотребимы, хотя, возможно, у C++ программистов какое-то особое видение. Если бы у тебя был опыт, ты бы знал что не бывает простейших задач, а любое временное решение имеет все шансы стать стандартом де-факто. Файл на диске это прекрасно для студенческой курсовой но в продакшене такие решения вызывают кучу проблем на ровном месте. Что будет если клиент и сервер потребуется разнести по нескольким машинам? Что случится если во временном каталоге закончится место? Как мы будем портировать решение на мак, если нам придется? Опытный разработчик отличается от неопытного тем что задумывается над подобными вопросами автоматически, не дожидаясь пока за него их поставит начальство.
Конкретно в твоем примере, видимо, ожидалось что ты хотя бы развяжешь протокол взаимодействия, способ взаимодействия и бизнес логику чтобы в случае чего можно было перейти с файлов на сокеты, а с сокетов на очередь сообщений. Если такого разделения не сделать сейчас, с вероятностью единица на твой код налипент куча всякой дряни и когда решение с временным каталогом перестанет устраивать потребуется выкинуть половину приложения.
pkl>им следовало точнее задавать вопрос? ))
Задача таких вопросов не получить от тебя готовый код, а посмотреть можете ли вы общаться "на одной волне": говорите на одном языке, принимаете одни и те же ценности, поклоняетесь одним и тем же богам. В данном случае оказалось что нет, они надрачивают на архитектуру и расширяемость, а ты предпочитаешь ad hoc решения. Если бы они тебя взяли, велика вероятность что вы бы просто не смогли вместе работать: ты бы казался им недалеким быдлокодером, а они тебе архитектурными астронавтами. Это не значит что кто-то из вас не прав, просто разные подходы.
Здравствуйте, pik, Вы писали:
pik>Здравствуйте, Vzhyk, Вы писали:
V>>Так верный то какой он не понял. Вот и пришел сюда спросить.
pik>сюда пришол за подтверждением своей догадки pik>очевидно ведъ что на собесдовании надо себя удачно "продатъ" а это включает и "следует нагородить умных универсальных интерфейсов"
Ой не факт. Для Python программистов на собеседовании часто встречается зеркальная ситуация: дается задача написать какой-нибудь скрипт, человек начинает городить иерархии классов и паттернов после чего задание признают зафейленым по причине "использования ООП там где без него легко обойтись".
M>Ой не факт. Для Python программистов на собеседовании часто встречается зеркальная ситуация: дается задача написать какой-нибудь скрипт, человек начинает городить иерархии классов и паттернов после чего задание признают зафейленым по причине "использования ООП там где без него легко обойтись".
завалитъ при желании всегда можно, это ведъ нам известно ещё со времён институтов
как правило не приглашают на собеседовыние чтобы завалитъ.
в С++ пока ещё надо думатъ объекториентированно хотя конечно найдёстя какойнибудъ спец который вам докажет обратное
Здравствуйте, pik, Вы писали:
pik> без шаблонов но с классами и интерфейсами, думаю даже требовалосъ как раз схематическое решение а не рабочий код в мейне. опытный программист начинает с объектов и интерфейсов а не сразу мысли в коде одной функции излагатъ.
Это смотря на какой стадии опытности он находится. Действительно опытный программист приучается не плодить лишние сущности там, где они не нужны. Keep It Simple Можно, конечно сказать, что закладывается развитие программы в дальнейшем, но из исходного вопроса не очевидно.
Здравствуйте, Jolly Roger, Вы писали:
JR>Ну правильно ответили. Будь у Вас опыт, Вы бы знали, что любой системе, которой сегодня достаточно взаимодействовать через файл, завтра обязательно потребуется работа в локальной сети, а послезавтра — в интернет.
А после-послезавтра она станет частью облака и т.п. Есть и другой опыт, называется требование разумной достаточности. Если стоит задача на пару часов и с взаимодействием через файл, то и нечего городить лишнюю сложность, отлаживать ее еще потом и т.д.
В этом смысле мне нравится подход Линуса Торвальдса, он насколько знаю, никогда не увлекался разработкой чего-то заранее впрок.
Здравствуйте, Michael7, Вы писали:
M>В этом смысле мне нравится подход Линуса Торвальдса, он насколько знаю, никогда не увлекался разработкой чего-то заранее впрок.
Так всего заранее не надо, даже "на завтра" не надо. Надо возможность завтра легко встроить то, что потребуется завтра. Что с "функцией main" не очень-то увязывается
On 13.03.2013 18:33, pik wrote:
> как правило не приглашают на собеседовыние чтобы завалитъ.
Как правило, все такие предположения не имеют ничего общего с
действительностью.
> в С++ пока ещё надо думатъ объекториентированно хотя конечно найдёстя > какойнибудъ спец который вам докажет обратное
Вау. Жесть. Это с какого бодуна. Зависит от задачи, где-то ООП самое то,
а где-то ему не место. К счастью С++ ничего не навязывает, навязывают
идиоты.
On 13.03.2013 18:36, Michael7 wrote:
> Это смотря на какой стадии опытности он находится. Действительно опытный > программист приучается не плодить лишние сущности там, где они не нужны. > Keep It Simple Можно, конечно сказать, что закладывается развитие > программы в дальнейшем, но из исходного вопроса не очевидно.
Действительно опытный, сначала выясняет чего надо, а потом выкатывает
ценник или вообще посылает особо пришибленных к студентам.
On 13.03.2013 18:42, Michael7 wrote:
> В этом смысле мне нравится подход Линуса Торвальдса, он насколько знаю, > никогда не увлекался разработкой чего-то заранее впрок.
По этому он создал Линукс, а оные спрашивальщики максимум распили
миллион за всю свою жизнь.
Здравствуйте, pkl, Вы писали:
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос?
Есть два подохода к задачам на собеседовании.
При первом подходе кандидату выдается задача, возможно, решаемая несколькими способами, возможно, правильное или самое оптимальное решение которой не известно собеседующему и смотрится, как кандидат ее решает.
При втором, кандидат получает задачу, возможно, нерешаемую и должен угадать решение, возможно, неправильное, которое придумал собеседующий.
В вашем случае, очевидно, было второе. В таких случаях не стоит огорчаться, а лучше порадуйтесь, что собеседующий не станет вашим начальником.
Мне вот тоже недавно дали задачку, как мне показалось, на двойную диспетчеризацию, а потом выяснилось, что собеседующий хотел, чтоб я написал шаблонный класс, параметризуемый ПОДами, который будет даункастить эти самые ПОДы динамик-кастом.
Здравствуйте, pkl, Вы писали:
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
Напишу свое ИМХО. Навороченные интерфейсы делать было не нужно. Все можно было сделать в двух файлах. Но — интерфейсы (в виде обычных процедур) нужно было продумывать сразу.
Итак — предположу, что делаем решение ASAP и в лоб. Самое простое из возможных, которое приемлемо в будущем. Итого — клиент ничего о сервере не знает. Но определен протокол — клиент и сервер знают о существовании какого либо файла (двух файлов). Клиент в файл пишет, сервер его читает. В файле содержится путь к файлу, который нужно прочесть. В ответном файле содержится результат. Все — тривиально до невозможности.
Итак, планируем, что у нас будет на клиенте:
1) будет функция что то вроде rpc. Скрытого до умопомрачения. Я его дернул, и мне не должно быть важно что там, взаимодействие с другим сервером, валидация этого файла непосредственно на этом диске в этом процессе. Это основной интерфейс, описывает чего я хочу. Во первых вопрос — взаимодействие будет синхронным или асинхронным? Если синхронное, то интерфейс будет один, если асинхронное, то другой. То есть сначала нужно было определиться с сигнатурой функций, и только потом их вызывать. В случае синхронного режима будет функция, возвращающая булево значение, на вход которого передается информация о файле (либо путь, либо хендл). В случае асинхронного эта функция примет callback. Или примет информацию о файле, а вернет объект, в котором будет инкапсулирован этот калбек. ИТОГО — это то, что необходимо написать в любом случае, причем сразу.
2) В реализации этой функции однозначно будет вызов другой функции — извещение сервера о том, что нужно принимать и обрабатывать файл. Соответственно будет процедура, в которой будет зашита логика передаче этой информации серверу, то есть банальная запись нужной информации в файл. Информация будет — ид, имя файла.
3) А также отслеживание файла результата, возможно там будет формат — ид, результат. Тоже отдельная функция.
4) Плюс функция которая в цикле через промежуток времени проверяет файл результата.
На стороне сервера будет собственно метод валидации. Еще нужно записывать результат. Еще нужно принимать исходные данные, то есть читать файл. То есть стоп — эту логику мы же уже делали для клиента (2,3,4). Решение — эту логику в либы, например в простейшем случае в хедер файл.
Итого что у нас получается? У нас библиотечный файл, где общая логика коммуникации. У нас определены интерфейсы валидации, а также определено то, как будет выглядеть вызов метода. Вот когда это напишешь — вот тогда и нужно писать main. Который тривиален — просто вызов функции. А в случае сервера тоже тривиально все — банальный вызов опроса в цикле, извлечение аргументов и передача результата.
И все. Достаточно расширяемая вещь. Если используем не файл, а пайпы, то просто модифицируем библиотеку. Парсер входных данных неизменен, мы меняем только транспорт. Или на TCP/IP делаем взаимодействие. Или на разделяемой памяти. Потребуется в будущем сделать различные варианты транспорта — это можно будет сделать, причем быстро сделать, без полного переписывания. У тебя есть костяк, который подвержен модификациям через рефакторинг. И с течением времени плавно, эволюционно, в случае изменений требований у тебя этот проект будет развиваться, а не будет все просто браться и переписываться.
А вот если ты хреначишь как большинство (ибо как по уму в вузах не учили ни черта, да и при работе тоже главное было о порядке инициализации постоянно помнить), все в функции main, да еще копипастой, то ты и провозишься в итоге дольше, чем по уму, и при малейших изменениях придется все переписывать практически полностью. У нормального разработчика привычка декомпозировать задачу и повторно использовать любой свой код просто зашита в мозгу, это все делается неосознанно и быстро. Короче — сделал бы в лоб, но с нормальной декомпозицией и инкапсуляцией (на уровне функций), был бы круче 99% кандидатов. Если от тебя же требовалось сразу сходу сделать быстро черти какие навороты и применить как можно большее количество паттернов — ну ее нахрен, такую работу.
Здравствуйте, pik, Вы писали:
pik>завалитъ при желании всегда можно, это ведъ нам известно ещё со времён институтов pik>как правило не приглашают на собеседовыние чтобы завалитъ.
В настоящее время дело скорее обстоит с точностью до наоборот.
On 14.03.2013 1:44, landerhigh wrote:
> В настоящее время дело скорее обстоит с точностью до наоборот.
Просто pik смотрит с точки зрения 5 лет назад и не осознал еще, что
предложения на рынке програмеров превышает спрос.
Здравствуйте, pik, Вы писали:
pik>Здравствуйте, Vzhyk, Вы писали:
V>>Так верный то какой он не понял. Вот и пришел сюда спросить.
pik>сюда пришол за подтверждением своей догадки pik>очевидно ведъ что на собесдовании надо себя удачно "продатъ" а это включает и "следует нагородить умных универсальных интерфейсов"
по мне, так продаваться нужно тому, кому нужно реальное решение задачи, а не мерянье пиписьками.
Я когда собеседовал — давал одну реальную задачу по работе.
C>по мне, так продаваться нужно тому, кому нужно реальное решение задачи, а не мерянье пиписьками. C>Я когда собеседовал — давал одну реальную задачу по работе.
ну дак это надо предоставитъ ТС определятъ, собеседование это конечно обоюдостороннее мероприятие, если не понравилосъ как с тобой общалисъ а они тебе контракт предлагают — тоже можно отказатся
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
Мой вывод о тебе был бы точно таким же бы: не хватает опыта.
Ты предложил плохое решение, которое сложно расширить или модифицировать, в случае, когда протокол взаимодействия клиента и сервера изменится.
Я думаю, что даже не нужно было бы писать код, достаточно было бы на бумажке нарисовать диаграмму классов.
On 14.03.2013 16:55, white_znake wrote:
> Я думаю, что даже не нужно было бы писать код, достаточно было бы на > бумажке нарисовать диаграмму классов.
Жесть. Вы так у себя и сочиняете архитектуры проектов за 5 мин на бумажке?
Да даже, для достаточно простого проекта архитектуру продумать и
нарисовать 2 недели уйдет, и еще 2 месяца на правки ее по мере
реализации. И где-то после полугода работы можно считать архитектуру
проекта более ни менее устоявшейся и законченной на верхних уровнях.
Самое смешное, когда потом у таких спрашиваешь, как вы это все
умудрились нагородить, ответ простой: "Ну мы не думали, надо было быстро".
Здравствуйте, Vzhyk, Вы писали:
V>On 14.03.2013 17:28, UA wrote:
>> У тебя просто мало опыта V>Это точно, архитектуру даже чего-то простого за 5 мин на бумажке я не умею.
Если не умеете то вам значит в лигу переворачивателей списков.
M>Примерно. Я бы уже после первого вопроса насторожился, термины "клиент" и "сервер" вполне однозначны и общеупотребимы, хотя, возможно, у C++ программистов какое-то особое видение. Если бы у тебя был опыт, ты бы знал что не бывает простейших задач, а любое временное решение имеет все шансы стать стандартом де-факто. Файл на диске это прекрасно для студенческой курсовой но в продакшене такие решения вызывают кучу проблем на ровном месте. Что будет если клиент и сервер потребуется разнести по нескольким машинам? Что случится если во временном каталоге закончится место? Как мы будем портировать решение на мак, если нам придется? Опытный разработчик отличается от неопытного тем что задумывается над подобными вопросами автоматически, не дожидаясь пока за него их поставит начальство.
Да. И вот многослойная медленная архитектура готова. Написали и код. А место на диске не кончается, на мак оно никому не надо. А какой то балбес выложил кривую тулу, которая всё хранит на диске, настраивается в hex редакторе, но ей во всю пользуются уже давно и плотно.
M>А после-послезавтра она станет частью облака и т.п. Есть и другой опыт, называется требование разумной достаточности. Если стоит задача на пару часов и с взаимодействием через файл, то и нечего городить лишнюю сложность, отлаживать ее еще потом и т.д.
M>В этом смысле мне нравится подход Линуса Торвальдса, он насколько знаю, никогда не увлекался разработкой чего-то заранее впрок.
Впрок не надо ничего делать (все равно через полгода-год все поменяется), но и обрубать себе возможности дальнейщего развития тоже не стоит. Хотя если команда практикует итеративный рефакторинг, unit&integration testing, тогда можно писать только для текущей задачи. Более того рекомендуется так делать. Когда функционал заработает будет понятно как его нужно переделать в последствии для того чтобы был расширяем.
Здравствуйте, white_znake, Вы писали:
_>Мой вывод о тебе был бы точно таким же бы: не хватает опыта.
Мой вывод — Вы занимаесь овер-инжинирингом и как следствие увеличиваете time-to-market. В нашем современом мире это сильно не приведствуется.
_>Ты предложил плохое решение, которое сложно расширить или модифицировать, в случае, когда протокол взаимодействия клиента и сервера изменится.
Он предложил простое и работающее решение для той постановки задачи. Если бы я был на месте собеседующего, то я бы принял это решение и поговорил бы, что нужно сделать если условия поменяются или как изменить client&server для того чтобы не зависит от транспорта (aka file).
_>Я думаю, что даже не нужно было бы писать код, достаточно было бы на бумажке нарисовать диаграмму классов.
В силиконовой долине всегда просят написать код а не диаграмму классов если Вы интервьюруетсь на инжинерную позицию. Архитекторские или принципал оставим за кадром — там сильно другие требования.
Здравствуйте, pkl, Вы писали:
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
Прокол в том, что берут человека для совместной работы, и нужно представлять, как он вольется в коллектив. Какое у него мировозрение, способ решения задач и т. п.
В таком случае я становлюсь разведчиком и задаю выясняющие вопросы, с целью выяснить, что от меня хотят. Если кандидат таких вопросов не задает, а сразу начинает что-то делать, это тревожный знак. Значит и в рабочих моментах в случае возникновения неясностей велика вероятность, что будут приниматься самостоятельные решения, идущие в разрез в общей архитектурой. А потом будет все тот-же ответ: "Мне надо было сразу догадаться?"
pkl>>Открываю редактор, TSP>Вот и фейл. Тру мастера собеседований берут бумажку и ручку. Потому что, это.. не помню уже почему но важно что бы на бумажке!
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, pkl, Вы писали:
pkl>>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? )) E>Напишу свое ИМХО. Навороченные интерфейсы делать было не нужно. Все можно было сделать в двух файлах. Но — интерфейсы (в виде обычных процедур) нужно было продумывать сразу.
E>Итак — предположу, что делаем решение ASAP и в лоб. Самое простое из возможных, которое приемлемо в будущем. Итого — клиент ничего о сервере не знает. Но определен протокол — клиент и сервер знают о существовании какого либо файла (двух файлов). Клиент в файл пишет, сервер его читает. В файле содержится путь к файлу, который нужно прочесть. В ответном файле содержится результат. Все — тривиально до невозможности.
Очень не удобно читать ответы с огромными "простынями" цитирования
Спасибо, хороший ответ. Большой. Я его щас чаем запью даже.
Но после того, как я начал писать функцию main и меня одёрнули, я догадался и пошла разработка интерфейсов. В результате получился класс клиента, класс сервера с инкапсулированной реализацией конкретного протокола и определёнными интерфейсами.
Может, сыграло роль то, что я сразу не пошёл по этому пути, а подумал "не буду плодить сущностей с самого начала"... Я вообще последние 2 месяца на Python пишу, захотелось отвлечься от плюсов, чёрт побери )
V>Просто pik смотрит с точки зрения 5 лет назад и не осознал еще, что V>предложения на рынке програмеров превышает спрос.
Ты бы уж уточнял где именно предложение превышает спрос. Скорей всего ТС говорит о Default city, а там ситуация противоположная — предложения значительно превышают спрос.
Здравствуйте, pkl, Вы писали: pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
да кто его знает че им надо
как-то в тестовом задании простом тоже голову думал — толи все в main или может в ф-ию одну вывести, толи классик написать, как я обычно делаю. написал классиком. сказали, нет, зачем тут в С++ классы, надо было делать проще
On 15.03.2013 2:10, kaa.python wrote:
> Ты бы уж уточнял где именно предложение превышает спрос. Скорей всего ТС > говорит о Default city, а там ситуация противоположная — предложения > значительно превышают спрос.
Читая про собеседования с переворачиваниями гномиков, я бы так не
сказал. Если так собеседуют обычно стараются никого не взять и
рассказать своему начальству, какие они спецы.
К империям "добра/зла" — это не относится — им вообще пофиг кого брать
или не брать.
Здравствуйте, kostik78, Вы писали:
K>Здравствуйте, white_znake, Вы писали:
_>>Мой вывод о тебе был бы точно таким же бы: не хватает опыта. K>Мой вывод — Вы занимаесь овер-инжинирингом и как следствие увеличиваете time-to-market. В нашем современом мире это сильно не приведствуется.
А как ты будешь тестировать код зашитый в функции main, в ручную каждый раз, а не увеличит ли это time-to-market на порядки, по сравнению с затратами на создание слабо связанных и тестируемых классов?
Если бы автор темы реализовал бы абстрактный класс для отправки сообщения и получения результата хотя бы с одним методом типа Send(), то думаю, что это характеризовало бы его с лучшей стороны. От него ни кто не ждал архитектуры уровня QtNetwork за короткий промежуток времени.
_>>Ты предложил плохое решение, которое сложно расширить или модифицировать, в случае, когда протокол взаимодействия клиента и сервера изменится. K>Он предложил простое и работающее решение для той постановки задачи. Если бы я был на месте собеседующего, то я бы принял это решение и поговорил бы, что нужно сделать если условия поменяются или как изменить client&server для того чтобы не зависит от транспорта (aka file).
Это решение интервьюеров, сказать стоп, вы нам абсолютно не подходите.
_>>Я думаю, что даже не нужно было бы писать код, достаточно было бы на бумажке нарисовать диаграмму классов. K>В силиконовой долине всегда просят написать код а не диаграмму классов если Вы интервьюруетсь на инжинерную позицию. Архитекторские или принципал оставим за кадром — там сильно другие требования.
Я думаю, что когда просят на собеседовании за ограниченное время (5-10 минут), что-то написать более серьезное чем реверс односвязного списка, то для интервьюверов важнее посмотреть ход мыслей кандидата, т.к. за отведенное время не возможно предоставить работающее решение.
Здравствуйте, TimurSPB, Вы писали:
TSP>Да. И вот многослойная медленная архитектура готова. Написали и код. А место на диске не кончается, на мак оно никому не надо. А какой то балбес выложил кривую тулу, которая всё хранит на диске, настраивается в hex редакторе, но ей во всю пользуются уже давно и плотно.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Вполне возможно, но мало вероятно, что от испытуемого требовалось послать предложения о множестве умных универсальных интерфейсов в корзину, и настоять на простом решении? ))) Хотя, для этого опыта и знаний мало будет, нужно ещё кое что.
Да, если испытуемый сказал бы, да ну нафиг эти ваши интерфейсы, простейшая же задача, — грех было бы не брать.
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, pkl, Вы писали:
pkl>>От них пришёл ответ о том, что у меня мало опыта.
JR>Ну правильно ответили. Будь у Вас опыт, Вы бы знали, что любой системе, которой сегодня достаточно взаимодействовать через файл, завтра обязательно потребуется работа в локальной сети, а послезавтра — в интернет.
При таком описании, как тут дали, с кружочками, и таком размере задачи (копировать файл), оптимальный подход — это при каждом изменении требований выбрасывать и переписывать. А вдруг развитие планировалось не в сторону интернет, и завтра потребуется работать через канал в 50 бод?
Здравствуйте, pkl, Вы писали:
pkl>Человек рисует два кружочка — "это клиент, а это — сервер. Давайте реализуем их взаимодействие. pkl>И: а может стоит интерфейсы определить? pkl>Я думаю: странное извращение: плодить сущности для такого говна, ну ладно...
Могу вас успокоить — вы оба неправы.
Они: сразу дали заведомо узкую задачу. Это неправильно, потому что есть как случаи, когда надо решать только эту конкретную проблему, а есть когда проблему надо обобщать. Поэтому если эти ЛАМЕРЫ ждали от вас "тырфейсов", они ОБЯЗАНЫ были сообщить вам, В КАКОМ СМЫСЛЕ задача может обобщаться. Ведь "клиент-сервер-файл" — это МОРЕ вариаций! Можно передавать файл, а можно блок данных. Можно по TCP, можно через дискетку. Можно передавать частями, можно целиком. Короче, это их лажа и непонятно, чего они ждали ещё, кроме main
Вы: действительно неопытный! Ну не ваша же функция с файлом их интересует, право! Нужно было подробнее распросить (вот как раз мои варианты выше) — какое взаимодействие, куда потенциально может расширяться система, вытащить из них более общую постановку — ведь просто файл никому не нужен, значит между К и С происходит нечто. К и С, кстати, могут быть на разных языках и вообще не иметь понятия "интерфейс".
Здравствуйте, kostik78, Вы писали:
K>Мой вывод — Вы занимаесь овер-инжинирингом и как следствие увеличиваете time-to-market.
+1
K> В нашем современом мире это сильно не привеТствуется.
-1
Увы, "современный мир" засран всякими паттернами/MV*нёй и менеджеры радостно клюют на эту лажу, поэтому строки IoC, MVVM, Agile волшебным образом превращают вас из "просто разработчика" в "крутые перцы". В их мировоззрении, конечно.
_>>Ты предложил плохое решение, которое сложно расширить или модифицировать, в случае, когда протокол взаимодействия клиента и сервера изменится.
Строго говоря, человека брали ПРОГРАММИРОВАТЬ. Думать о "расширить взаимодействие" есть специальная должность Business Analyst совместно с Architect. Т.е. до него (как программиста) должны доходить лишь тех.задания "напиши отправку файла". Всё. Какого чёрта эти умники сидят со своими тырфейсами и чешут ЧСВ — неясно.
Здравствуйте, TimurSPB, Вы писали:
TSP>Да. И вот многослойная медленная архитектура готова. Написали и код. А место на диске не кончается, на мак оно никому не надо. А какой то балбес выложил кривую тулу, которая всё хранит на диске, настраивается в hex редакторе, но ей во всю пользуются уже давно и плотно.
Бывает и по другому
Лет 5 назад понадобилось написать программу-анализатор файла с логом. Каждую команду распарсить, удалить повторы, показать на экране, добавить фильтры. Коллега сделал за несколько дней. Все легко, просто, работает.
Программка понравилась, через некоторое время захотелось анализировать другой протокол. А первая версия сильно заточена под конкретный протокол — фиксированный размер пакета, определенные поля и т.д.
Ладно, переделал.
Потом оказалось, что логи присылают из разных источников (но с одним и тем же протоколом). При этом они записаны немного по разному — там время с секундами, а там с миллисекундами, где-то HEX, где-то ASCII. Коллега сделал нахлобучки, которые разные форматы приводили к известному ему, а его затем, как и раньше, парсил. Правда за счет двух преобразований начались некоторые тормоза.
Следующий этап — несколько десятков протоколов для анализа. Коллега к тому времени научился сохранять распарсенные логи и опубликовал формат. А я подключился и написал собственно анализатор для еще нескольких протоколов, который сохранял результаты в этом самом формате. Программка коллеги теперь занималась фактически только отображением (а еще поддерживала несколько первых форматов логов).
Дальше выяснилось, что фиксированный формат файла — плохо, разным протоколам нужны разные поля, фильтры и т.д. К этому же времени стало ясно, что анализатор должен быть очень гибким — скажем есть файл лога, в котором записан обмен по разным протоколам с разными устройствами, или несколько файлов, которые надо слить, или несколько папок. Некоторые протоколы могут быть "закапсулированы" в другие протоколы — скажем есть ifsf поверх lon, а есть поверх tcp.
В общем в прошлом году обе программы были переписаны. Анализатор теперь имеет встроенный движок ява-скрипта, на котором "склеиваются" блоки конвертеров и умеет подключать плагины на том же ява-скрипте. Просмотрщик принимает файлы с произвольным количеством полей (в начале файла сидит xml-заголовок с описанием формата, а затем — бинарные данные).
Если бы мне 5 лет назад сказали, что понадобится такое решение — я бы счел это полной глупостью. И тем не менее, оно оказалось довольно удачным, позывов все переписать заново пока нет
Если бы мы с самого начала изобрели такую архитектуру — сэкономили бы много времени. С другой стороны, для нас это совершенно побочная деятельность, тратить несколько недель на проработку всего этого было бы наверное не оправдано
On 18.03.2013 15:22, enji wrote: >
> В общем в прошлом году обе программы были переписаны.
Это все говорит лишь о твоей и твоего коллеги неопытности. Нет смысла
переделывать рабочую программу, если можно написать для второго
протокола другую программу.
Этих протоколов у вас, хорошо, если 20 штук, а можно подумать, что
миллиарды и все разные.
Опытный бы разбил эти протоколлы на несколько групп по похожести и так,
что бы необходимо было делать минимальную правку кода, вынес бы
настройки в конфигурацию, но никак не занимался вот этим уродством:
"Анализатор теперь имеет встроенный движок ява-скрипта, на котором
"склеиваются" блоки конвертеров и умеет подключать плагины на том же
ява-скрипте. Просмотрщик принимает файлы с произвольным количеством
полей (в начале файла сидит xml-заголовок с описанием формата, а затем —
бинарные данные)."
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, kostik78, Вы писали:
K>>Здравствуйте, white_znake, Вы писали:
_>А как ты будешь тестировать код зашитый в функции main, в ручную каждый раз, а не увеличит ли это time-to-market на порядки, по сравнению с затратами на создание слабо связанных и тестируемых классов? _>Если бы автор темы реализовал бы абстрактный класс для отправки сообщения и получения результата хотя бы с одним методом типа Send(), то думаю, что это характеризовало бы его с лучшей стороны. От него ни кто не ждал архитектуры уровня QtNetwork за короткий промежуток времени.
Ну вот как раз про оверинжинириг я и говорил . Тестировать — написал бы простой скрипт на python который бы мне проверял бы описаный в задании use case.
_>Это решение интервьюеров, сказать стоп, вы нам абсолютно не подходите.
Обычно палка о двух концах — человек кто прришел на собеседование тоже оценивает интервьюверов по заданиям что ему дают. И если они его не устраивают то он тоже скажет стоп.
_>Я думаю, что когда просят на собеседовании за ограниченное время (5-10 минут), что-то написать более серьезное чем реверс односвязного списка, то для интервьюверов важнее посмотреть ход мыслей кандидата, т.к. за отведенное время не возможно предоставить работающее решение.
5-10 минут задачи дают обычно которые имеют obvious решение а не задачи на проектирование. И автор даного треда выдал вполне адекватное решение для той постановки задачи.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, kostik78, Вы писали:
K>> В нашем современом мире это сильно не привеТствуется.
M>-1
M>Увы, "современный мир" засран всякими паттернами/MV*нёй и менеджеры радостно клюют на эту лажу, поэтому строки IoC, MVVM, Agile волшебным образом превращают вас из "просто разработчика" в "крутые перцы". В их мировоззрении, конечно.
Ну если это какая нибудь компания аля "корпорация" то согласен. В случае стартапа или компании которой нужно выпустить проект то все это уходит на второй план. Главное то как человек решает задачи. Обычно пытаются понять насколько кандидат: bad or good enough.
Здравствуйте, Vzhyk, Вы писали:
V>Нет смысла V>переделывать рабочую программу,
Ты знаешь, мой опыт говорит, что программу стоит переделывать, как только она начинает "вонять". "Вонять" — значит в нее неприятно лезть и вносить исправления\улучшения... Даже если она при этом рабочая, все равно стоит в какой-то степени переделать, или хотя бы запланировать эти переделки. В противном случае в один прекрасный день просто не захочется идти на работу — к тоннам "воняющего" кода
V>если можно написать для второго протокола другую программу.
И имеем мы десяток одинаковых программ. Точнее, они не одинаковые, ибо постоянно допиливаются — скажем в одну добавили поле фильтра, в другие — нет, в одной в буфер обмена копируется как текст, так и таблица — в остальных — только текст. Какие-то пересобраны на новых версиях библиотек, а какие-то пока на старых.
V>Этих протоколов у вас, хорошо, если 20 штук, а можно подумать, что V>миллиарды и все разные.
Больше 30 уже...
V>Опытный бы разбил эти протоколлы на несколько групп по похожести и так, V>что бы необходимо было делать минимальную правку кода, вынес бы V>настройки в конфигурацию,
Ну вот тебе жизненный пример:
* есть внешняя программа, пишущая логи в формате "А"
* она пишет логи протоколов "Б" и "С" (не похожих друг на друга)
Соответственно если у есть две программы-анализатора, обе должны уметь читать формат "А"...
Или
* есть протокол "А"
* есть протокол "Б"
"А" передается внутри "Б", но "Б" имеет и самостоятельную ценность.
У нас есть программа-анализатор, парсящая "Б". Теперь мы учим ее парсить "А"?
А если у нас появляется "А" поверх "С"? "С" парсится другой программой...
V>но никак не занимался вот этим уродством: V>"Анализатор теперь имеет встроенный движок ява-скрипта ...
Вот ты думаешь, что это уродство. А 5-10 разных программ, делающих одно и то же — нет. Я с тобой не согласен.
И кстати, почему ты называешь это уродством? Вот например wireshark — там есть плагины, он поддерживает сотни протоколов, и все это одна программа...
V>Это все говорит лишь о твоей и твоего коллеги неопытности.
А может о твоей? Судя по вышесказанному, ты не слишком в теме, однако уже сделал заключение о моей неопытности
On 18.03.2013 19:10, enji wrote:
> Ты знаешь, мой опыт говорит, что программу стоит переделывать, как > только она начинает "вонять". "Вонять" — значит в нее неприятно лезть и > вносить исправления\улучшения... Даже если она при этом рабочая, все > равно стоит в какой-то степени переделать, или хотя бы запланировать эти > переделки. В противном случае в один прекрасный день просто не захочется > идти на работу — к тоннам "воняющего" кода
Но во время переделки контора может лишиться больщого заказа, который ее
и похоронит. Именно на такое когда-то нарвался RECIF французский. Интел
терпел, терпел, а потом попросил вернуть деньги назад, контора объявила
себя банкротом и народ пошел на улицу всей толпой и во Франции (там с
выходным пособием) и в Минске (без выходного)
> И имеем мы десяток одинаковых программ. Точнее, они не одинаковые, ибо > постоянно допиливаются — скажем в одну добавили поле фильтра, в другие — > нет, в одной в буфер обмена копируется как текст, так и таблица — в > остальных — только текст. Какие-то пересобраны на новых версиях > библиотек, а какие-то пока на старых.
Ну и что. Если оказались две очень близкие, то их можно объединить,
остальные никому не мешают.
> Больше 30 уже...
Во-во, а не 30000.
> А если у нас появляется "А" поверх "С"? "С" парсится другой программой...
Бррр. Ничего не понял, что-то вы намудрили.
> И кстати, почему ты называешь это уродством? Вот например wireshark — > там есть плагины, он поддерживает сотни протоколов, и все это одна > программа...
Не знаю что это такое и почему вы считаете его идеалом?
V>>если можно написать для второго протокола другую программу. E>И имеем мы десяток одинаковых программ. Точнее, они не одинаковые, ибо постоянно допиливаются — скажем в одну добавили поле фильтра, в другие — нет, в одной в буфер обмена копируется как текст, так и таблица — в остальных — только текст. Какие-то пересобраны на новых версиях библиотек, а какие-то пока на старых.
Есть такая классная штука, называется UNIX way ))) Дык вот, если идти по этому пути, то за каждую функцию отвечает своя программа. В вашем случае за первичный разбор каждого входного формата/протокола. Главное чтобы выхлоп у них был понятен другой программе, которая преобразует это во то что нужно.
Здравствуйте, Vzhyk, Вы писали:
V>Но во время переделки контора может лишиться больщого заказа, который ее V>и похоронит.
Ну дык — если у тебя большая система, ты ее переписываешь не всю сразу, а постепенно рефакторишь отдельные кусочки. При этом работоспособность всей системы не нарушается. У фаулера много об этом, рекомендую
>> И имеем мы десяток одинаковых программ. V>Ну и что. Если оказались две очень близкие, то их можно объединить, V>остальные никому не мешают.
Они то не мешают, но вносить одну и ту же правку в даже 10 программ — сильно утомляет. И собственно необходимость этого говорит, что что-то у нас не так...
>> Больше 30 уже... V>Во-во, а не 30000.
Я в начале говорил о десятках. Ты же назвал цифру миллиард, теперь 30000. Что дальше?
>> А если у нас появляется "А" поверх "С"? "С" парсится другой программой... V>Бррр. Ничего не понял, что-то вы намудрили.
Эт не мы, это жизнь такая.
Реальный пример — есть протокол lon. Есть протокол ifsf. Ifsf может транслироваться поверх lon, а может поверх tcp. ifsf в свою очередь многоуровневый, там есть общий базовый слой и протокол уровня приложения (свой для каждого приложения)
>> И кстати, почему ты называешь это уродством? Вот например wireshark... V>Не знаю что это такое и почему вы считаете его идеалом?
Про идеал ты сказал Погугли, если интересно, распространенная прога для анализа сетевых протоколов
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Есть такая классная штука, называется UNIX way ))) Дык вот, если идти по этому пути, то за каждую функцию отвечает своя программа. В вашем случае за первичный разбор каждого входного формата/протокола. Главное чтобы выхлоп у них был понятен другой программе, которая преобразует это во то что нужно.
собственно, это и было источником вдохновения У нас вместо отдельных программ плагины и компоненты, в вместо шела — яваскрипт.
Можно было бы конечно выделить компоненты в отдельные программы, но пришлось бы заводить библиотеку с общим кодом + между компонентами ходят объекты, а не текст. В powershell вроде как можно этого добиться, но насколько я понимаю, только с управляемыми языками. У нас же мало опыта с шарпом, зато много кода на с++ и некоторые знания яваскрипта
Здравствуйте, pkl, Вы писали:
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
С чего вы взяли что задача пустяковая? Может там тысячи клиентов, которые коннектятся к серверу, и шлют в сумме 1000 файлов в секунду, может быть немаленьких размеров. Если по вашему это пустяковая задача, то уже заранее понятно, что говорить с вами не о чем.
Можно возразить — этого не было в условии задачи. Так опытность и определяется тем, возникнут ли нужные вопросы или нет, наступали ли на грабли, решали ли проблемы, можете ли предвидеть проблемы. Если вопросов нет — no hire без вариантов.
Здравствуйте, pkl, Вы писали:
pkl>...Я думаю: странное извращение: плодить сущности для такого говна, ну ладно...
pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить ...
Вспоминается кусочек из какого-то романа, читал давным давно но...
Главный герой — химик, проводится собеседование
— Сделайте анализ образца.
— Какого?
— Да любого — вон полный шкаф.
Я подхожу к шкафу с образцами, отрываю первую попавшуюся банку,
высыпаю немного в руку, несу к лабораторному столу беру пробирку,
высыпаю туда, ставлю пробирку на горелку, зажигаю, и тут меня прерывают.
— Достаточно! Вы уже сделали кучу ошибок!
"Нормальные герои всегда идут в обход!"
