В процессе разработки проекта, так как-то исторически получилось, что работа с обработкой входных данных взял на себя сам заказчик. То есть я делаю графику, GUI, физику — заказчик в этом ничего не понимает, но зато вот данные для всего этого у него хранятся в миллионах Excel таблиц, между ними крайне хитрые связи, в одной ссылка на другую, в этой другой ссылки на еще десять и все в каше и перепутано.
Так вот мы потихоньку по мере развития проекта пришли к такому способу — заказчик пишет небольшие тулзовины, консольные, которые принимаеют на вход некие параметры и выводят на консоль результат или в человекочитаемый JSON файл, я уже это все подцепляю в своей проге и делаю что нужно. То есть папка с прогой выглядит, как набор из 20 exe файлов. Из которых только 1 моя большая прога, остальные — небольшие тулзовины заказчика.
Ясно, что во всех проектах это выглядит как одна EXE и куча DLL
И самое главное — никакой просадки в скорости на реальных тестах — нету. То есть понятно, что получить из DLL прямой укзатель — это будет гораздо производительнее, чем сохранение в json файл и потом чтение из него. Но на реальных тестах в условиях как будет использоваться программа — никаких просадок не заметно.
Но минус DLL в том, что ее функционал так просто не проверишь, надо прогу писать. А у консольной проги плюс — все можно вывести в консоль и посмотреть.
Так вот и вопрос — у нас совсем кривой метод и лучше переделать в DLL-ки? Или вы уже где-то видели такой подход и все нормально работает?
И да, я знаю что такое маппинг файлов в памяти и пайпы, но заказчик не хочет во всем этом копаться, его знание программирования заканчивается на fprintf
Здравствуйте, Homunculus, Вы писали:
H> его знание программирования заканчивается на fprintf
Ну и остановись на этом. Занятся нечем? Твой продукт? Нет. Решай задачи которые ставит заказчик, а не создавай их.
Здравствуйте, Kernan, Вы писали:
H>> его знание программирования заканчивается на fprintf K>Ну и остановись на этом. Занятся нечем? Твой продукт? Нет. Решай задачи которые ставит заказчик, а не создавай их.
Ну так я и спросил — может это чем-то чревато, а я просто не знаю про это — вот и спросил у вас.
Здравствуйте, Homunculus, Вы писали:
H>Но минус DLL в том, что ее функционал так просто не проверишь, надо прогу писать. А у консольной проги плюс — все можно вывести в консоль и посмотреть.
А нельзя договориться, чтобы у всех этих DLL-ек был одинаковый интерфейс? Тогда можно было бы для проверки одну програмку написать, а не 20...
H>Так вот и вопрос — у нас совсем кривой метод и лучше переделать в DLL-ки? Или вы уже где-то видели такой подход и все нормально работает?
Ну по хорошему, если внешние программы запускаешь, надо бы и ошибки всякие проверять, и уметь отличать, если вдруг такая программа сгененерировала половину результата, а потом упала. С DLL это проще, упадет, так и все за собой потянет.
Здравствуйте, Pzz, Вы писали:
Pzz>А нельзя договориться, чтобы у всех этих DLL-ек был одинаковый интерфейс?
Можно, но ведь в реальной жизни всегда так, что заказчику результат нужен вчера и чем быстрее он увидит картинку на экране — тем лучше. Я просил как-то остановиться и привести архитектуру в нормальный вид, но он говорит, что ему надо быстрее менеджерам показывать, что мы тут наделали.
Здравствуйте, Homunculus, Вы писали:
Pzz>>А нельзя договориться, чтобы у всех этих DLL-ек был одинаковый интерфейс?
H>Можно, но ведь в реальной жизни всегда так, что заказчику результат нужен вчера и чем быстрее он увидит картинку на экране — тем лучше. Я просил как-то остановиться и привести архитектуру в нормальный вид, но он говорит, что ему надо быстрее менеджерам показывать, что мы тут наделали.
Ну скажи ему, что в проекте уже столько бардака, что вперед не получается двигаться быстро. Лучше достать метлу и слегка прибраться, чем пытаться выживать на помойке, переступая через разбросанные повсюду вещи с риском поскользнуться и сломать ногу.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну скажи ему, что в проекте уже столько бардака, что вперед не получается двигаться быстро.
Так в том-то и штука, что пока вроде получается. И все работает. Я у себя сделал некий общий подход к таким Exe-шникам, и сейчас добавление нового занимает 10 минут. Так что сказать ему, что у нас жопа — будет неправдой Как у него организованы эти тулзовины — понятия не имею.
H>Или вы уже где-то видели такой подход и все нормально работает?
unix?
H>И да, я знаю что такое маппинг файлов в памяти и пайпы, но заказчик не хочет во всем этом копаться, его знание программирования заканчивается на fprintf
ну ты можешь сделать фреймворк, который билдится в DLL со стандартным интерфейсом, и имеет набор интерфейсов обмена между хостом и "плагином", в т.ч. аналог printf потом может мутирует с отправки форматированной строки в отправку объектов.
Нормальный вариант, имхо. От добра добра не ищут. Проблема программы в дополнительных накладных расходах, но если они не ощутимы, то и не надо никакие DLL. Вот начнёт падать эта DLL, и всю твою программу за собой утянет. А внешняя программа может падать сколько угодно.
Здравствуйте, Homunculus, Вы писали:
H>И да, я знаю что такое маппинг файлов в памяти и пайпы, но заказчик не хочет во всем этом копаться, его знание программирования заканчивается на fprintf
Если ты прав в оценке знаний программирования твоим заказчиком, то задай себе вопрос — как этот переход он будет осуществлять ?
Его знаний для этого не хватит. Кто это будет делать ?
Вариант 1. Ты его долго учишь (допустим даже, что он согласится), а он делает дурацкие ошибки, которые тебя раздражают, а его тем более. Делал себе, делал, все работало, а тут коллега предложил делать иначе, профита ноль (он оценить преимуществ DLL не сможет), а все работать перестало, а когда наконец что-то начинает не падать и что-то выдавать — не поймешь, как это проверить, вывода-то больше нет
Вариант 2. ты ему пишешь некий код темплейта для DLL, в которой он должен вставлять свои куски. Немного лучше, ты ерунду не напишешь, но все равно для него куча проблем. Он же не понимает, как все это устроено, а делать код под некий шаблон, которого не понимаешь — тоже не подарок, особенно с учетом его квалификации. И опять же вывода нет.
В общем, и так плохо, и так плохо. Кроме проблем, ничего не создадите.
Так что мой совет прост : работает — не трогай.
Единственный хороший вариант — это если ты возьмешь написание всех этих DLL на себя полностью. Тут ты сделаешь как надо. Однако, судя по твоим словам, это едва ли реальный вариант.
Здравствуйте, Homunculus, Вы писали:
H>Так вот и вопрос — у нас совсем кривой метод и лучше переделать в DLL-ки? Или вы уже где-то видели такой подход и все нормально работает?
Не кривой. Даже наоборот, если ты умеешь определять упала программа или нет, правильно ли выдала результат или нет, то путь отличный, главная программа более устойчива к ошибкам. Тем более, что модули пишет не самый опытный программист. Лучше в случае ошибки сказать пользователю, где и как она была, чем упасть самому.
В качестве примера с множеством dll можно взять Far: если падает плагин, то он закрывается. Например, я одно время часто пользовался плагином exe browser, чтобы смотреть на зависимости бинарников. Но на некоторых dll плагин падал вместе с самим Fra'ом — очень неприятная ситуация.
А так, у тебя Unix way, микросервисы, все дела. Оставляй.
Здравствуйте, Homunculus, Вы писали: H>Ну так я и спросил — может это чем-то чревато, а я просто не знаю про это — вот и спросил у вас.
С файлами может вмешиваться антивирус. Особенно, если в темпе их создавать.
Винда еще при создании файлов в темпе ставит им собственные права доступа (ACL), а не наследуемые от родительской папки.
Соответственно, при копировании в другие папки файлик будет доступен только владельцу и админу.
Но даже, если темп не использовать, то просто в текущей директории exe антивирус может запросто перемещать в карантин подозрительные для него файлы.
Сталкивался в такой ситуацией, когда копирую exe в какую-то директорию Far'ом — бах, нет его. Еще раз копирую — опять исчезает.
Exe был мой, не вирус точно, просто не понравился антивирусу.
Здравствуйте, Homunculus, Вы писали:
H>Ну так я и спросил — может это чем-то чревато, а я просто не знаю про это — вот и спросил у вас.
Если это не влияет на сложность сопровождения проекта, скорость багфикса и фичадевелопмента, то просто ничего не меняй.
Здравствуйте, Homunculus, Вы писали:
Pzz>>Ну скажи ему, что в проекте уже столько бардака, что вперед не получается двигаться быстро.
H>Так в том-то и штука, что пока вроде получается. И все работает. Я у себя сделал некий общий подход к таким Exe-шникам, и сейчас добавление нового занимает 10 минут. Так что сказать ему, что у нас жопа — будет неправдой Как у него организованы эти тулзовины — понятия не имею.
Здравствуйте, Nuzhny, Вы писали:
N>Не кривой. Даже наоборот, если ты умеешь определять упала программа или нет, правильно ли выдала результат или нет, то путь отличный, главная программа более устойчива к ошибкам. Тем более, что модули пишет не самый опытный программист. Лучше в случае ошибки сказать пользователю, где и как она была, чем упасть самому. N>В качестве примера с множеством dll можно взять Far: если падает плагин, то он закрывается. Например, я одно время часто пользовался плагином exe browser, чтобы смотреть на зависимости бинарников. Но на некоторых dll плагин падал вместе с самим Fra'ом — очень неприятная ситуация. N>А так, у тебя Unix way, микросервисы, все дела. Оставляй.
IMHO может ТС и оставит так, вот только микросервисы обычно обмениваются через TCP/IP, а здесь — файлы
При микросервисах — возможно масштабирование системы — на несколько (много) компов.
Ну и поддержка всего этого, при микросервисах окажется все же дешевле и проще.
Я понимаю, что ТСу сложно объяснить Заказчику недостатки данной архитектуры, и если не требуется развития системы — можно забить на это.
Вот только не нужно утверждать, что всё это хорошо...
P.S. Здесь выше уже указывали на недостатки данного подхода.
На мой взгляд — возможно три различных пути (решения проблемы):
1) Монолитное приложение с применением DLL (есть свои недостатки);
2) Монолитное статической линковки. При этом, все приложения Закзчика — это просто классы (с одним общим интерфейсом), а ТС просто сделает юнит-тесты для него;
3) Микросервисы с сетевым обменом;
В куче утилит ничего плохого нет. Особенно если и вам и заказчику так удобно, и никаких реальных аргументов кроме "а вон у 'ведущих собаководов' всё по другому устроено" нет.
Переделывать на DLL — а как это заказчик писать и отлаживать будет? Дополнительно писать консольное приложение? А оно ему надо?
Если сама идея не нравится и есть ощущение, что будут просадки на больших объёмах данных — возьмите какое-нибудь одно такое приложение, сконвертируйте в DLL и посмотрите, на каких объёмах данных оно начнёт работать реально быстрее, чем текущая идея с консольками. Если объёмы заведомо недостижимы, то и фиг бы с ним. Ну а уж если достижимо, то, возможно, имеет смысл эту тему с заказчикам поднимать.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Здравствуйте, Homunculus, Вы писали:
H>И да, я знаю что такое маппинг файлов в памяти и пайпы, но заказчик не хочет во всем этом копаться, его знание программирования заканчивается на fprintf
Есть три похода к взаимодействию с не квалифицированным партнером:
1) Партнетр пишет на скриптовом языке, который можно запустить "в песочнице".
2) Передача исходных текстов, которые вы сами проверяеете статическими анализаторами / покрываете тестами / переписываете ...
3) консольные exe файлы (или на его любимом скриптовом языке).
Примерно то что у вас и есть.
Недостатки:
(1) если дочерний процесс завис, то его недостаточно убить. Нужно проанализировать внучатые процессы и т.д. (Особенно актуально для скриптов. Рекомендую запускать процессы в Job-е).
(2) если за качеством написания дочерних программ совсем не следить, они начинают срать логами и временными файлами куда только смогут дотянуться. Этот вопрос (логов и временных файлоов) нужно согласовывать заранее.
Если смущают временные файлы, как таковые, можно использовать перенаправляемые потоки консольного ввода/вывода.
Здравствуйте, Homunculus, Вы писали:
H> его знание программирования заканчивается на fprintf
Тем ни менее насколько я понял он читает Excel файлы (как?), пишет JSON, но не может освоить основы работы c dll. Как то не сочетается
Нормально сочетаеться, com обьект для чтенния, стандартный сериализатор для записи. Делаеться в полтора движения без использования каких либо навыков кроме копирования текста E>Тем ни менее насколько я понял он читает Excel файлы (как?), пишет JSON, но не может освоить основы работы c dll. Как то не сочетается
Как у него организованы эти тулзовины — понятия не имею.
потом может мутирует с отправки форматированной строки в отправку объектов.
