Комментарии 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 как там по-русски будет «портабельность»? «Таскаемость»? :)
Навскидку не могу вспомнить коммерческой библиотеки, которую по лицензии пользователь должен покупать самостоятельно.
Не туда.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про интерфейсы