Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Скажите, пожалуйста, честно, что вы предлагаете? Отказаться от использования внешних зависимостей? Или вот скажите, вы про nuget не слышали?
PS «Основное назначение шаблонов так называемого проектирования — создание костылей и подпорок.»
Ну да, конечно, человек, за плечами которого две сотни проектов по всему миру, докторская по архитектуре и еще некоторое количество бумажек, строил здания на костылях и подпорках.
PS «Основное назначение шаблонов так называемого проектирования — создание костылей и подпорок.»
Ну да, конечно, человек, за плечами которого две сотни проектов по всему миру, докторская по архитектуре и еще некоторое количество бумажек, строил здания на костылях и подпорках.
Ну да, конечно, человек, за плечами которого две сотни проектов по всему миру, докторская по архитектуре и еще некоторое количество бумажек, строил здания на костылях и подпорках.
Скрытый текст
В тексте упомянуты, как минимум, 2 тезиса по частным решения на относительно малом масштабе:
— ответственно относиться к разработке сторонних компонентов
— снизить риски наличием исходного кода
В общем случае проблема не решается. Подтверждается великим множеством эксплуатируемого ПО, которого поставщики уже не поддерживают. Далеко не всегда у такого ПО есть исходники, что вынуждает клиентов иметь в резерве уже давно не производящееся «железо». Далеко не всегда даже имеющиеся исходники могут быть перенесены в новую архитектуру.
— ответственно относиться к разработке сторонних компонентов
— снизить риски наличием исходного кода
В общем случае проблема не решается. Подтверждается великим множеством эксплуатируемого ПО, которого поставщики уже не поддерживают. Далеко не всегда у такого ПО есть исходники, что вынуждает клиентов иметь в резерве уже давно не производящееся «железо». Далеко не всегда даже имеющиеся исходники могут быть перенесены в новую архитектуру.
Что такое «разработка сторонних компонентов»? Как наличие исходных кодов избавляет от dependency hell?
Чем вас в общем случае не устраивают решения с локально распространяемыми зависимостями?
Чем вас в общем случае не устраивают решения с локально распространяемыми зависимостями?
Компонент программной системы — это минимальная единица развертывания. В данном случае речь идет еще и компоненте в понятии COM.
В продуктовом софтостроении каждый сторонний компонент, то есть поставляемый третьей стороной, увеличивает риски несовместимости и отказа отдельных функций основной системы.
Жестко зафиксировать конфигурацию установленного ПО у сотен клиентов не представляется возможным. Поэтому для относительно небольших компонентов выбирается вариант его внедрения в общую систему. В этом случае наличие исходников значительно облегчает задачу внедрения и последующего сопровождения.
Простой пример был приведен — экспорт в PDF. Поскольку разработчики PDF Creator безответственно относятся к разработке, то эта функция должна быть внедрена в основную систему, возможно уже на базе другой реализации.
Другие часто встречающиеся примеры — архивация и распаковка, сканирование (без драйверов), доступ к БД, генерация отчетности, реализации сетевых протоколов разных уровней и т.д.
Чем больше основная система, тем больше в ней внедрено сторонних решений, зависимость с которыми разорвана на уровне поглощения исходников.
В продуктовом софтостроении каждый сторонний компонент, то есть поставляемый третьей стороной, увеличивает риски несовместимости и отказа отдельных функций основной системы.
Жестко зафиксировать конфигурацию установленного ПО у сотен клиентов не представляется возможным. Поэтому для относительно небольших компонентов выбирается вариант его внедрения в общую систему. В этом случае наличие исходников значительно облегчает задачу внедрения и последующего сопровождения.
Простой пример был приведен — экспорт в PDF. Поскольку разработчики PDF Creator безответственно относятся к разработке, то эта функция должна быть внедрена в основную систему, возможно уже на базе другой реализации.
Другие часто встречающиеся примеры — архивация и распаковка, сканирование (без драйверов), доступ к БД, генерация отчетности, реализации сетевых протоколов разных уровней и т.д.
Чем больше основная система, тем больше в ней внедрено сторонних решений, зависимость с которыми разорвана на уровне поглощения исходников.
Поскольку разработчики PDF Creator безответственно относятся к разработке, то эта функция должна быть внедрена в основную систему, возможно уже на базе другой реализации.
Нет, должен быть выбран другой компонент.
Чем больше основная система, тем больше в ней внедрено сторонних решений, зависимость с которыми разорвана на уровне поглощения исходников.
То есть кроме поглощения исходников вы других вариантов разрыва dependency hell не знаете?
Давайте вернемся к примеру. У вас есть система, развернутая на сотнях рабочих мест. Предположим, она использует упомянутый PDFCreator для печати. Разработчики PDFCreator выпустили новую версию. Несколько клиентов обновили PDFCreator и обнаружили, что печать больше не работает (технические причины описаны в тексте). Они начинают звонить в поддержку вендора.
Вы предлагаете:
— выбрать другой компонент (надо полагать, его разработчики более ответственны, такое тоже бывает). Извините, этот вариант нам не подходит.
— какой-то другой вариант кроме (1) поглощения или (2) поддержки совместимости со всеми версиями (механизм также описан в тексте)
Готов внимательно выслушать про другой вариант, только не теоретический, а подкрепленный реальной практикой в похожих условиях.
Вы предлагаете:
— выбрать другой компонент (надо полагать, его разработчики более ответственны, такое тоже бывает). Извините, этот вариант нам не подходит.
— какой-то другой вариант кроме (1) поглощения или (2) поддержки совместимости со всеми версиями (механизм также описан в тексте)
Готов внимательно выслушать про другой вариант, только не теоретический, а подкрепленный реальной практикой в похожих условиях.
Я предлагаю вам выбрать компонент, используемую версию которого вы сможете гарантированно зафиксировать (например, через bin-deploy).
То есть поглотить, но без исходников, взяв на себя ответственность по развертыванию зафиксированной версии со всеми вытекающими.
Спасибо, как вариант иногда проходит. Например, в случае embedded СУБД, они развертываются примерно так.
Спасибо, как вариант иногда проходит. Например, в случае embedded СУБД, они развертываются примерно так.
Нет никакого поглощения — вы не несете ответственность за этот код, это просто используемый вами компонент. Когда он обновляется у производителя, и если вам нужна функциональность этого обновления — вы прогоняете тесты и включаете в свой следующий релиз.
Win-win.
Win-win.
Совершенно верно, это называется поглощение бинарников. Развертывая их в составе своей системы, вы несете ответственность за них перед клиентами, не имея исходного кода, полагаясь исключительно на тесты типа «черный ящик».
В некоторых случаях это возможно, когда компонент достиг определенного уровня зрелости и риск обнаружения в нем критичных ошибок невелик. Иначе это не работает., к сожалению.
В некоторых случаях это возможно, когда компонент достиг определенного уровня зрелости и риск обнаружения в нем критичных ошибок невелик. Иначе это не работает., к сожалению.
Вы не несете ответственность за них, вы несете ответственность за вашу систему. И да, предполагается, что вы критичные ошибки найдете до выпуска вашего продукта.
Если вы не несете ответственность перед клиентом, скажем, за ошибку в SQL Server Compact (который поставляется вместе с вашей системой простым copy deployment), это означает, что вы можете клиенту предложить обратиться в Микрософт, а не к вам.
Поскольку это не так практически всегда, предлагаю не заниматься терминологическими изысками.
С сутью же ваших предложений понятно, спасибо.
Поскольку это не так практически всегда, предлагаю не заниматься терминологическими изысками.
С сутью же ваших предложений понятно, спасибо.
Вы не понимаете, о чем я. Когда вы несете ответственность за компонент — пользователь предполагает, что он может использовать компонент независимо от вашей программы.
В случае развертывания SQL Server Express — может использовать. В случае PDFCreator — тоже. Зафиксировать их версии возможным не представляется. Поэтому предлагаемый подход в таких случаях не работает.
Для таких случаев придумали opensource.
Нет, .NET.
Проблема тогда просто в другой фантик заворачивается.
Почему это? Там все сборки версионируются, угробить другое приложение, просто разместив сборку в GAC уже сложнее.
К сожалению, это лишь аналог пожеланий того, что поставщик компонента должен обеспечить функционирование нескольких версий одновременно на одном устройстве.
В случае COM-DLL сделать это даже проще, чем для сборки в GAC: всего лишь установить DLL новой версии в другой директорий, и не надо никаких strong name и прочего.
Однако… см. по тексту.
В случае COM-DLL сделать это даже проще, чем для сборки в GAC: всего лишь установить DLL новой версии в другой директорий, и не надо никаких strong name и прочего.
Однако… см. по тексту.
Для таких случаев придумали таскать зависимости вместе с приложением.
А если лицензия говорит нельзя? В случае общих библиотек опенсорс дохрена головной боли снимает.
Для таких случаев придумали redistributable packages… Разумеется, о портабельности библиотеки должен думать ее создатель.
PS как там по-русски будет «портабельность»? «Таскаемость»? :)
PS как там по-русски будет «портабельность»? «Таскаемость»? :)
Навскидку не могу вспомнить коммерческой библиотеки, которую по лицензии пользователь должен покупать самостоятельно.
Не туда.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про интерфейсы