Здравствуйте, 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, тогда можно писать только для текущей задачи. Более того рекомендуется так делать. Когда функционал заработает будет понятно как его нужно переделать в последствии для того чтобы был расширяем.
"Нормальные герои всегда идут в обход!"
