В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Архитектура ИТ-решений

1588 membersпожаловаться на группу
2019 August 25

S

Sergey in Архитектура ИТ-решений
Alexander Luchkov
MDD хорош когда:
1. Есть компетенции в людях в отношении процесса разработки и необходимо снизить рутинные затраты на провеку качества принимаемых решений.
2. Есть заведомо качественное описание и его нужно проанализировать на возможность внесения изменений.
MDD завязывается на конкретный инструмент. Глюки в продукте могут все затормозить. Миграция между CASE тулами почти не реальна. Синхронизация кода и модели далеко не всегда идеальна. Потому лучше не пытаться внедрять MDD. Потом больше проблем чтоб его выдрать и уйти на что-то иное, когда продукт, на какое все было завязано, помирает
источник
16:46пожаловаться

AL

Alexander Luchkov in Архитектура ИТ-решений
Sergey
MDD завязывается на конкретный инструмент. Глюки в продукте могут все затормозить. Миграция между CASE тулами почти не реальна. Синхронизация кода и модели далеко не всегда идеальна. Потому лучше не пытаться внедрять MDD. Потом больше проблем чтоб его выдрать и уйти на что-то иное, когда продукт, на какое все было завязано, помирает
Поэтому если кто и берётся внедрять себе MDD то сразу делают команду его разрабтки внутри.
источник
16:47пожаловаться

S

Sergey in Архитектура ИТ-решений
без разницы, команда ушла - компетенции пропали
источник
16:47пожаловаться

S

Sergey in Архитектура ИТ-решений
так даже еще хуже
источник
16:47пожаловаться

S

Sergey in Архитектура ИТ-решений
коробочный продукт продержится чуть дольше
источник
16:47пожаловаться

AL

Alexander Luchkov in Архитектура ИТ-решений
Sergey
без разницы, команда ушла - компетенции пропали
Сергей, коробочный продукт не продержится нисколько. Потому, что он просто не встанет в процессы производства как коробка. Его придётся допиливать либо силами вендора, либо своими.
Риск, что сдохнет вендор или "уйдёт команда", это примерно как риск, что в аварии разом погибнет вся продуктовая команда.
источник
16:49пожаловаться

AL

Alexander Luchkov in Архитектура ИТ-решений
С этими рисками есть понятные способы работы.
источник
16:49пожаловаться

S

Sergey in Архитектура ИТ-решений
я был частью команды  IBM Rational Software Architect, это коробочный продукт. Сейчас можно сказать что изначальных девелоперов там не осталось, лишь мелкая кучка индусов. Те кастомеры, кто оказался завязан на него страдают. Благо что это был Эклипс и кой что сами могут допиливать. На счет "уйдет" - IBM просто взял и продал весь Rational индусам
источник
16:53пожаловаться

S

Sergey in Архитектура ИТ-решений
и по страданию кастомеров как раз видел к чему приводит MDD
источник
16:53пожаловаться

S

Sergey in Архитектура ИТ-решений
хотя планов и идей было громадье и Буч в довесок...
источник
16:54пожаловаться

S

Sergey in Архитектура ИТ-решений
вот System Architect-у (изначальный от Popkin Software) повезло, его не индусам продали а американской конторке
источник
16:57пожаловаться

S

Sergey in Архитектура ИТ-решений
другие вендоры подобных тулов в той же лодке. Общий настрой на MDD не особо, просто кто уже привязался к тулам, то трудно сбежать. Если много кода генерится
источник
17:00пожаловаться

S

Sergey in Архитектура ИТ-решений
внедрение МДД никогда как коробка не идет. Т.е если берется коробка, то потом процедура внедрения порядка года  а то и больше
источник
17:02пожаловаться

S

Sergey in Архитектура ИТ-решений
в данном случае коробка это тоже скорей конструктор
источник
17:02пожаловаться

S

Sergey in Архитектура ИТ-решений
кодогенерация - это хорошая и правильная идея, если исходник откель генерим не привязан к конкретному тулу и его можно редактировать в чем-то еще. Как только возникает жесткая привязка, то мы закладываем бомбу
источник
17:11пожаловаться

S

Sergey in Архитектура ИТ-решений
так некоторые бедолаги с Rose-ой попали как раз
источник
17:11пожаловаться

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Не только с Rose-ой. Всё описанное выше в той или иной степени справедливо и по отношению к другим тулам.
источник
17:16пожаловаться

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Кодогенерация также должна предусматривать возможность "ручного" расширения. Хуки, интерфейсы. Так как трудно представить ситуацию, когда можно избежать "ручных" изменений. Иногда "честных", но чаще "костылей". И тут кроется основная сложность. Как сделать, чтобы при перегенерации не "поехали" ручные правки.
источник
17:19пожаловаться

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Со структурой базы то же самое. Можно поменять структуру за счёт перегенерации из модели. Но что делать с данными, их нужно мигрировать и при этом не потерять и сами данные и производительность. А когда структура и её изменения в коде, там же и скрипты миграции. Причём оттестированные
источник
17:24пожаловаться

S

Sergey in Архитектура ИТ-решений
Gennadiy Kruglov
Кодогенерация также должна предусматривать возможность "ручного" расширения. Хуки, интерфейсы. Так как трудно представить ситуацию, когда можно избежать "ручных" изменений. Иногда "честных", но чаще "костылей". И тут кроется основная сложность. Как сделать, чтобы при перегенерации не "поехали" ручные правки.
кодогенерация оптимальна для тех случаев, когда внутрь сгенеренного кода уже не лезут, а кастомизации задаются в исходном коде (вставки таргет кода). Типичный пример - все генераторы парсеров, лексеров, аст-ов.  Или протоколы аля gRPC,  языки сериализации типа ASN.1 и т.п
источник
17:32пожаловаться