"Нужна возможность замены любых классов и методов целиком" Снизит ли это трудоемкость в долгосрочной перспективе?

[mazzy]

Хочу выделить в отдельную тему:

Quote:

Originally Posted by ax_mct

Нужна возможность замены любых классов и методов целиком. Через конфигурационные файлы.

Учитывая стиль ax_mct предлагаю читать не "конфигурационные файлы", а "метаданные". Метаданные могут быть устроены любым удобным способом. Не суть.

Предлагаю обсудить тезис "Нужна возможность замены любых классов и методов целиком"
сразу можно задать тривиальные вопросы: кому нужна? зачем?

но я предлагаю сразу пропустить тривиальные шаги
и подумать над следующим:

Есть стоимость владения - ТСО.
Эта стоимость включает в себя затраты, которые несет купиший продукт на протяжении всей жизни продукта.
Для компьютерных систем это:
= стоимость покупки
= стоимость трудозатрат на доработку
= стоимость трудозатрат на настройку и ввод в экслуатацию
= стоимость трудозатрат во время эксплуатации (пользователям удобно или не удобно => пользователи выполняют операции с меньшими трудозатратами или с большими)
= стоимость трудозатрат на исправление ошибок (пользовательских или программных)
= стоимость трудозатрат на апгрейд продукта на новую версию
= стоимость вывода из эксплуатации и замены на другой продукт

покупатели сравнивают конкурирующие продукты по размеру TCO - чем меньше, тем лучше.

конечно же, покупатели могут ошибаться в своих оценках.
этими ошибками конечно же пользуются продавцы.

но для продукта, который существует на рынке достаточно долго, TCO вполне точно прогнозируемая величина.
======================

теперь собственно к разработке

трудоемкость разработки влияет на TCO в следующих моментах:
= создание новой фичи
= вписывание новой фичи в уже существующий функционал
= кастомизация фичи на конкретном проекте
= изменение/агрпейд уже существующих фич с созданием инструментов апгрейда

======================
так вот... насколько я понимаю, "возможность замены любых классов и методов целиком" уменьшает трудоемкость кастомизации. но сильно увеличивает трудоемкость апгрейда.

а отсутствие возможности "замены любых классов и методов целиком" наоборот, увеличивает трудоемкость кастомизации, но зато уменьшает трудоемкость апгрейда.

собственно см. холивары на тему "открытые/закрытые системы"

======================
собственно вопрос:
Снизит ли "возможность замены любых классов и методов целиком" трудоемкость в долгосрочной перспективе?
Снизит ли TCO?

[EVGL]

Здорово заниматься абстракциями, а не внедрением на клиенте, да?

Стоимость владения теперь в основном определяется Microsoft и составляет как минимум 200 евро в месяц за голову. Эта стоимость владения определяется Excel'ем на рабочем столе у Мишель Матисс в Сиэтле, а также входными параметрами, заданными ее руководством и целевым бюджетом. 200 евро могут стать с июля 250, могут стать 300, а могут - 150 или вообще не измениться. Вот и попробуйте оценить ТСО в долгосрочной перспективе.

[fed]

Ты не совсем правильно вопрос ставишь. Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом. Как в этом случае TCO посчитать ? Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?

[mazzy]

Quote:

Originally Posted by EVGL

Здорово заниматься абстракциями, а не внедрением на клиенте, да?

Почему или-или?

Здорово и заниматься абстракциями, и внедрением на клиенте. да.

Quote:

Originally Posted by EVGL

Стоимость владения теперь в основном определяется Microsoft и составляет как минимум 200 евро в месяц за голову.

Конечно же, нет.
Конечно же, это не стоимость владения, а всего лишь одно из слагаемых - стоимость лицензий

[mazzy]

Quote:

Originally Posted by fed

Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом.

Почему? Они тупые? (С)

Я бы сформулировал так:
ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO),
ТО клиент просто не станет внедрять систему.

Quote:

Originally Posted by fed

Как в этом случае TCO посчитать ?

в этом случае достаточно констатации, что TCO будет неподъемной для целевой аудитории или существенно выше, чем у конкурентов.

Quote:

Originally Posted by fed

Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?

Дык, нет внедрения - нет владения.
нет владения - нет доходов от продажи у вендора.
нету ручек - нет конфетки.
https://www.youtube.com/watch?v=7KyZJ3xrreA

TCO - не единственный показатель )))

[fed]

Quote:

Originally Posted by mazzy

Почему? Они тупые? (С)

Я бы сформулировал так:
ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO),
ТО клиент просто не станет внедрять систему.

Так тут и стоит проблема: Обычно клиент требует замены стандартной логики, потому что риски и косты замены бизнес-процессов очень тяжело оценить. А риски и косты разработки - не очень. То есть - по разработке можно раза в 2-3 ошибится в оценке в худшем случае, а при смене бизнес-процессов - эдак раз в 30-50
Поэтом и дорабатывают так много...

[ax_mct]

Quote:

Originally Posted by mazzy

Почему? Они тупые? (С)

Большинству типичных клиентов AX - TCO это прежде всего вопрос нахождения надежного Партнера которому можно доверять. Затем возможности самой системы.
И только после этого - стоимость. Это только вендор думает что TCO на первом месте.

Причем всегда большой бизнес - нетипичен и нестандартен, он хочет свою разработку. Если через метаданные мы сможем заменять вызов любого класса или метода - это и просто, и эффективно.

В Java и PHP это делается через конфигурационные файлы *.xml на уровне конкретных фрэймворков. По сути AX/D365FO тот самый фрэймворк и есть и с учетом того что уже есть через метаданные это действительно проще.

Но это не избавляет от (функциональных) конфликтов при обновлениях и раз так то проще использовать слои. Все что нужно вендору - это разные режимы и настройки продукта относительно обновлений и overlayering которые определяет сам клиент/партнер.

[AlexeyS]

вот типичный пример программирования (или настройки) через XML-файлы от Microsoft
https://technet.microsoft.com/en-us/.../hh389762.aspx
попробуйте экстраполировать это на аксапту

[ax_mct]

Quote:

Originally Posted by AlexeyS

вот типичный пример программирования (или настройки) через XML-файлы от Microsoft
https://technet.microsoft.com/en-us/.../hh389762.aspx
попробуйте экстраполировать это на аксапту

Новый узел в AOT содержащий файлы XML. При создании любого обьекта проверка на наличие XML файла c этим именем и применение другого обьекта или метода там указанного. В случае компиляции в CIL компиляция с учетом этой перезаписи.

[Андре]

Quote:

вот типичный пример программирования (или настройки) через XML-файлы от Microsoft

Это не очень хороший пример

Quote:

"Нужна возможность замены любых классов и методов целиком"

Вот эта возможность, как принцип проектирования ПО называется Dependency Injection, который в свою очередь является частным случаем Inversion of Control.

Я вот не возьмусь доказывать, как подобный подход скажется на TCO, так как у меня нет таких данных, но, в общем то, такой подход очень широко распространен. Например, Spring (https://spring.io/) - фреймворк #1 для enterprise решений в мире java - целиком построен на этом принципе.

Можно написать свою реализацию существующего интерфейса, задеплоить его в виде отдельного jar файла на application server, а в конфигурационном файле просписать, что в качестве реализации интерфейса использовать вот эту конкретную реализацию. Вот так примерно:

<bean name="customerRepository"
          class="com.demas.repository.HibernateCustomerRepositoryImpl" />

p.s. Да, в мире NET есть тоже очень много библиотек, реализующих этот паттерн. MS, если я не ошибаюсь, советует/поддерживает Unity (https://msdn.microsoft.com/library/ff647202.aspx). Но, нужно понимать, что в отличии от Spring - это просто DI контейнер, без всей тучи инфрастуктуры, которая написана вокруг него для Spring.

[AlexeyS]

Quote:

Originally Posted by Андре

Это не очень хороший пример

Можно написать свою реализацию существующего интерфейса, задеплоить его в виде отдельного jar файла на application server, а в конфигурационном файле просписать, что в качестве реализации интерфейса использовать вот эту конкретную реализацию. Вот так примерно:

<bean name="customerRepository"
          class="com.demas.repository.HibernateCustomerRepositoryImpl" />

Рад бы видеть что-то попроще, но это то, что имеем сейчас.
Есть SSRS, который умеет работать с определенными расширениями, а мы добавляем еще, прописывая их в конфигурационном файле.
Тот-же самый принцип, что и bean, только сложнее прописывать и пока непонятно, как это дебажить в случае необходимости

<Extension Name="AXQUERY" Type="Microsoft.Dynamics.Framework.Reports.AxQueryConnection,Microsoft.Dynamics.Framework.ReportsExtensions, ...

[S.Kuskov]

А чем эта "замена любых классов и методов целиком через конфигурационные файлы" отличается от механизма слоёв в аксапте?
Замену нужно поддерживать в рантайм?
Количеством слоёв?
Как мержить два решения заменчющих оди и тот же класс, метод?

[ax_mct]

Quote:

Originally Posted by S.Kuskov

А чем эта "замена любых классов и методов целиком через конфигурационные файлы" отличается от механизма слоёв в аксапте?
Замену нужно поддерживать в рантайм?
Количеством слоёв?
Как мержить два решения заменчющих оди и тот же класс, метод?

Отличие только в (почти) отстутствии технических конфликтов при обновлениях от вендора так как замена "сбоку", а не "сверху". Механизм слоев это как блин на блине, а подобная замена - возьми другой пирожок со сторонней полочки.

Но да, от потенциальных функциональных конфликтов это не спасает, впрочем как и реализация через extensions сама по себе от конфликта логики не спасет.

Замену нужно поддерживать в рантайм, но при наличии скомпилированной сборки CIL это ничего не стоит.

Как мержить два решения заменчющих один и тот же класс, метод? Если ISV то пусть сертифицируются и встраиваются только через extensions, а данная перезапись как бы логический слой USR - только на конечном клиенте.

Но вопрос еще и в том хочет ли MS быть эдаким супер-партнером (Крысиным королем) который колбасит и колбасит новый фунционал и устанавливает эти обновления когда и как ему захочется. Тут и решения на extensions не дают стабильности.

При нахождении on-premise когда как я понимаю не может быть автоматических обновлений (или может?) действительно самое простое это позволять overlayering в старом добром стиле.