Статья выстраданная, но в ней не упомянуто, что это уже как минимум третья попытка продавать серебряную пулю архитектуры систем из микрокомпонентов.
Об этом в статье «Блеск и нищета микросервисов» www.arbinada.com/ru/node/1651
Статья полезная, я бы добавил еще грех №21 "использование мьютексов вместо событий".
Главное, что если убрать из заголовка "С++", то смысл не изменится: все эти проблемы (ну, разве что кроме GUI) известны системным программистам с 1960-х годов.
Некрокомментарий.
Данная схема работает (и в Git, и в SVN) при условии только одной версии в эксплуатации. Это типично, например, для заказной разработки под клиента.
Если поддерживаем одновременно несколько релизов (типично для вендоров), то схему придется основательно ломать.
Без конкретики получается наброс, а жаль.
На С++ много удачных проектов, далеко за 6 млн. строк. Судьбу MS Office можно пожелать любому проекту. Дело не столько в миллионах, сколько в их структуре. CORBA — красивая промышленная технология, позволявшая работать с хайповыми нынче «микросервисами» еще 20 лет назад. Коррупция во Франции, разумеется, есть, только автор не вполне разобрался с ситуацией распределения крупных заказов проектным конторам. 3 месяца — срок уведомления о желании уволиться для ИТР и управленцев, несложно договориться о его сокращении. Для техников-программистов — 1 месяц. В общем, все не так плохо, хотя мы все, конечно, умрем.
Есть и противоположные оценки, например "Agile is a cancer that we have to eliminate from the industry".
Представляю себе лица многочисленных клиентов, которым я осмелился бы предложить непрекращающуюся «после каждого коммита» поставку продукта, любое обновление которого (кроме хотфиксов) требует недель их внутренних тестов и опытной эксплуатации.
Допустим, основная система — 1М строк кода, одна из сторонних библиотек — 4М строк.
Автор предлагает проверять эту библиотеку отдельно?
Да, production server по-русски называется рабочий сервер или сервер эксплуатации.
Тестовых и приемочных сред должно быть несколько, все они с разными целями и, соответственно, с разными параметрами окружения. Например, нагрузочное тестирование ориентировано на время отклика, приемочные тесты ориентированы на функционал. В эксплуатации несколько мелких клиентов будут использовать один сервер и разделяемое хранилище данных, крупный — выделенный кусок этого хранилища и несколько серверов. Как при этом контейнеризация поможет быстрее доставить продукт клиенту не вполне ясно.
Если данные живут отдельно от контейнеров, можно ли вообще говорить об идентичности окружения? Разница уровня одной строки в таблице параметров может полностью менять поведение системы.
Если докер работает в виртуальной среде, как он может быть быстрее непосредственной работы приложения в этой среде? Каждый уровень виртуализации, пусть даже тонкий, только снижает производительность.
Вопрос для использующих контейнеры (и докер в частности).
Насколько я понял, концепт упирается на т.н. микросервисы: не нужно упаковывать всю систему в один контейнер (иначе разница с полноценной виртуальной машиной невелика), а запускать интеграцию, например, из трех контейнеров: веб-сервер+приложение, сервер приложений и СУБД.
В статьях увлекательно пишут, о том, что если это работало на машине разработчика, то без изменений будет крутиться в эксплуатации.
Первый вопрос, параметры системы (речь о системе уровня небольшой ERP) у разработчика, у испытателей и в эксплуатации у клиентов принципиально разные, поскольку разные цели. Как это совместить?
Второй вопрос, какой смысл упаковывать в контейнер терабайтную… ладно, даже 50 Гб базу данных?
Третий вопрос, с какого масштаба системы докер становится бесполезен и использование полноценной виртуальной среды (а то и физической) становится выгоднее (могу ошибаться, но у меня есть подозрения на уровень LAMP-приложения до 100К строк кода и 100 таблиц в БД)?
Спасибо за пояснения на реальных примерах.
Засунуть можно и абстрактный Object, от которого все наследуется. Кроме доступа к Id и типу (классу) вам это ничего не даст. Поэтому обычно туда засовывают нечто более конкретное, чтобы дергать нужные в данном контексте свойства и функции.
Ладно, понятно, не будем по кругу ходить.
Как-то лихо вы перешли с объектов на таблицы, давайте все же вернемся в терминологии ООП. То что вы предлагаете — правильный путь, но это не решение проблемы, а надстройка еще одного уровня is a part of.
Поясню. Товарная позиция (aka SQU) — действительно контейнер для товара. Но чтобы засунуть объект в этот контейнер, нужно чтобы этот объект обладал свойствами товара (нечто пригодное к продаже). Сделать это для условной «книги» можно тремя способами: наследованием от абстрактного товара, агрегацией реализации абстрактного товара и его экспозицией через свойство (уже упомянуто выше), или интерфейсом.
Проблема с книгой приведена для того, чтобы читатель начал думать сам. Во многих простых случаях наследования от «абстрактного товара» достаточно, проблема расширения может не возникнуть вовсе, тем более в аджайлах — кто об этом будет думать загодя. Агрегацию вы путаете с интерфейсами, «товар» — свойство книги, а не наоборот. Насчет цены вы частично правы, это не имманентное свойство товара (в реальном мире это баланс спроса и предложения), а значение из очень многомерного массива. Вопрос, самостоятельный ли это класс объектов «Цена» или просто многокритериальная функция извлечения нужного значения однозначно не решается, но никто не запрещает сделать функцию «GetPrice(...)» товара фасадом.
То есть ENotImplemented или иное исключение в ответ на вызов метода для вас не предполагает «свободы получателя»? Странно, ведь вся-то разница в пристыковке реализации к интерфейсам: динамически или статически.
ООП на концептуальном уровне требует посылку сообщений, но не оговаривает механизмы реализации. Вызов метода объекта — тоже посылка сообщения. Динамика не только не требуется, от не нее многие стараются убежать в интерфейсы, как от чумы.
Вот пример ролевого подхода к реализации ООП www.arbinada.com/ru/node/8
Разделение на уровни важно. Представьте, например, к чему приведет его игнорирование для СУБД. На концептуальном есть сущности, атрибуты и связи. На логическом появляются первые ограничения, связанные с графовым или множественным подходом. Выбор реляционной модели означает использование ключей. Выбор графовой-сетевой — физических связей между записями. Иерархии даже для документ-ориентированных моделей типа XML продолжают порождать проблемы дублирования одних и тех сущностей.
Так и с ООП. На логическом уровне посылка объекту сообщения может быть реализована и как в Смоллтоке — что надо, то и шлю, а если объект не умеет обрабатывать сообщение, то получаю отказ. Чистая незамутненная динамика. А может быть зафиксированной жесткой статикой вызовом метода. И то и другое — объектный подход, каждая реализация которого имеют свои плюсы и минусы.
Об этом в статье «Блеск и нищета микросервисов»
www.arbinada.com/ru/node/1651
Статья полезная, я бы добавил еще грех №21 "использование мьютексов вместо событий".
Главное, что если убрать из заголовка "С++", то смысл не изменится: все эти проблемы (ну, разве что кроме GUI) известны системным программистам с 1960-х годов.
Данная схема работает (и в Git, и в SVN) при условии только одной версии в эксплуатации. Это типично, например, для заказной разработки под клиента.
Если поддерживаем одновременно несколько релизов (типично для вендоров), то схему придется основательно ломать.
На С++ много удачных проектов, далеко за 6 млн. строк. Судьбу MS Office можно пожелать любому проекту. Дело не столько в миллионах, сколько в их структуре. CORBA — красивая промышленная технология, позволявшая работать с хайповыми нынче «микросервисами» еще 20 лет назад. Коррупция во Франции, разумеется, есть, только автор не вполне разобрался с ситуацией распределения крупных заказов проектным конторам. 3 месяца — срок уведомления о желании уволиться для ИТР и управленцев, несложно договориться о его сокращении. Для техников-программистов — 1 месяц. В общем, все не так плохо, хотя мы все, конечно, умрем.
Представляю себе лица многочисленных клиентов, которым я осмелился бы предложить непрекращающуюся «после каждого коммита» поставку продукта, любое обновление которого (кроме хотфиксов) требует недель их внутренних тестов и опытной эксплуатации.
Допустим, основная система — 1М строк кода, одна из сторонних библиотек — 4М строк.
Автор предлагает проверять эту библиотеку отдельно?
Да, production server по-русски называется рабочий сервер или сервер эксплуатации.
Если данные живут отдельно от контейнеров, можно ли вообще говорить об идентичности окружения? Разница уровня одной строки в таблице параметров может полностью менять поведение системы.
Если докер работает в виртуальной среде, как он может быть быстрее непосредственной работы приложения в этой среде? Каждый уровень виртуализации, пусть даже тонкий, только снижает производительность.
Насколько я понял, концепт упирается на т.н. микросервисы: не нужно упаковывать всю систему в один контейнер (иначе разница с полноценной виртуальной машиной невелика), а запускать интеграцию, например, из трех контейнеров: веб-сервер+приложение, сервер приложений и СУБД.
В статьях увлекательно пишут, о том, что если это работало на машине разработчика, то без изменений будет крутиться в эксплуатации.
Первый вопрос, параметры системы (речь о системе уровня небольшой ERP) у разработчика, у испытателей и в эксплуатации у клиентов принципиально разные, поскольку разные цели. Как это совместить?
Второй вопрос, какой смысл упаковывать в контейнер терабайтную… ладно, даже 50 Гб базу данных?
Третий вопрос, с какого масштаба системы докер становится бесполезен и использование полноценной виртуальной среды (а то и физической) становится выгоднее (могу ошибаться, но у меня есть подозрения на уровень LAMP-приложения до 100К строк кода и 100 таблиц в БД)?
Спасибо за пояснения на реальных примерах.
Ладно, понятно, не будем по кругу ходить.
Поясню. Товарная позиция (aka SQU) — действительно контейнер для товара. Но чтобы засунуть объект в этот контейнер, нужно чтобы этот объект обладал свойствами товара (нечто пригодное к продаже). Сделать это для условной «книги» можно тремя способами: наследованием от абстрактного товара, агрегацией реализации абстрактного товара и его экспозицией через свойство (уже упомянуто выше), или интерфейсом.
Вот пример ролевого подхода к реализации ООП
www.arbinada.com/ru/node/8
Так и с ООП. На логическом уровне посылка объекту сообщения может быть реализована и как в Смоллтоке — что надо, то и шлю, а если объект не умеет обрабатывать сообщение, то получаю отказ. Чистая незамутненная динамика. А может быть зафиксированной жесткой статикой вызовом метода. И то и другое — объектный подход, каждая реализация которого имеют свои плюсы и минусы.