Здравствуйте, white_znake, Вы писали:

_>Мой вывод о тебе был бы точно таким же бы: не хватает опыта.
Мой вывод — Вы занимаесь овер-инжинирингом и как следствие увеличиваете time-to-market. В нашем современом мире это сильно не приведствуется.

_>Ты предложил плохое решение, которое сложно расширить или модифицировать, в случае, когда протокол взаимодействия клиента и сервера изменится.
Он предложил простое и работающее решение для той постановки задачи. Если бы я был на месте собеседующего, то я бы принял это решение и поговорил бы, что нужно сделать если условия поменяются или как изменить client&server для того чтобы не зависит от транспорта (aka file).

_>Я думаю, что даже не нужно было бы писать код, достаточно было бы на бумажке нарисовать диаграмму классов.
В силиконовой долине всегда просят написать код а не диаграмму классов если Вы интервьюруетсь на инжинерную позицию. Архитекторские или принципал оставим за кадром — там сильно другие требования.

Здравствуйте, pkl, Вы писали:

pkl>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))

Прокол в том, что берут человека для совместной работы, и нужно представлять, как он вольется в коллектив. Какое у него мировозрение, способ решения задач и т. п.

В таком случае я становлюсь разведчиком и задаю выясняющие вопросы, с целью выяснить, что от меня хотят. Если кандидат таких вопросов не задает, а сразу начинает что-то делать, это тревожный знак. Значит и в рабочих моментах в случае возникновения неясностей велика вероятность, что будут приниматься самостоятельные решения, идущие в разрез в общей архитектурой. А потом будет все тот-же ответ: "Мне надо было сразу догадаться?"

pkl>>Открываю редактор,
TSP>Вот и фейл. Тру мастера собеседований берут бумажку и ручку. Потому что, это.. не помню уже почему но важно что бы на бумажке!

это еще классик сказал: "без бумажки ты какашка"

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, pkl, Вы писали:

pkl>>Где тут прокол — мне надо было сразу догадаться, что для пустяковой проблемы следует нагородить умных универсальных интерфейсов с шаблонами или им следовало точнее задавать вопрос? ))
E>Напишу свое ИМХО. Навороченные интерфейсы делать было не нужно. Все можно было сделать в двух файлах. Но — интерфейсы (в виде обычных процедур) нужно было продумывать сразу.

E>Итак — предположу, что делаем решение ASAP и в лоб. Самое простое из возможных, которое приемлемо в будущем. Итого — клиент ничего о сервере не знает. Но определен протокол — клиент и сервер знают о существовании какого либо файла (двух файлов). Клиент в файл пишет, сервер его читает. В файле содержится путь к файлу, который нужно прочесть. В ответном файле содержится результат. Все — тривиально до невозможности.


Спасибо, хороший ответ. Большой. Я его щас чаем запью даже.

Но после того, как я начал писать функцию main и меня одёрнули, я догадался и пошла разработка интерфейсов. В результате получился класс клиента, класс сервера с инкапсулированной реализацией конкретного протокола и определёнными интерфейсами.

Может, сыграло роль то, что я сразу не пошёл по этому пути, а подумал "не буду плодить сущностей с самого начала"... Я вообще последние 2 месяца на Python пишу, захотелось отвлечься от плюсов, чёрт побери )

Здравствуйте, Vzhyk, Вы писали:


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 ))) Дык вот, если идти по этому пути, то за каждую функцию отвечает своя программа. В вашем случае за первичный разбор каждого входного формата/протокола. Главное чтобы выхлоп у них был понятен другой программе, которая преобразует это во то что нужно.