AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 21.03.2017, 14:38   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
"Нужна возможность замены любых классов и методов целиком" Снизит ли это трудоемкость в долгосрочной перспективе?
Хочу выделить в отдельную тему:

Цитата:
Сообщение от ax_mct Посмотреть сообщение
Нужна возможность замены любых классов и методов целиком. Через конфигурационные файлы.
Учитывая стиль ax_mct предлагаю читать не "конфигурационные файлы", а "метаданные". Метаданные могут быть устроены любым удобным способом. Не суть.

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

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

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

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

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

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

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

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

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

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

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

======================
собственно вопрос:
Снизит ли "возможность замены любых классов и методов целиком" трудоемкость в долгосрочной перспективе?
Снизит ли TCO?
__________________
полезное на axForum, github, vk, coub.
Старый 21.03.2017, 15:00   #2  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Здорово заниматься абстракциями, а не внедрением на клиенте, да?

Стоимость владения теперь в основном определяется Microsoft и составляет как минимум 200 евро в месяц за голову. Эта стоимость владения определяется Excel'ем на рабочем столе у Мишель Матисс в Сиэтле, а также входными параметрами, заданными ее руководством и целевым бюджетом. 200 евро могут стать с июля 250, могут стать 300, а могут - 150 или вообще не измениться. Вот и попробуйте оценить ТСО в долгосрочной перспективе.
Старый 21.03.2017, 15:01   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Ты не совсем правильно вопрос ставишь. Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом. Как в этом случае TCO посчитать ? Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?
За это сообщение автора поблагодарили: EVGL (1).
Старый 21.03.2017, 15:11   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
Здорово заниматься абстракциями, а не внедрением на клиенте, да?
Почему или-или?

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

Цитата:
Сообщение от EVGL Посмотреть сообщение
Стоимость владения теперь в основном определяется Microsoft и составляет как минимум 200 евро в месяц за голову.
Конечно же, нет.
Конечно же, это не стоимость владения, а всего лишь одно из слагаемых - стоимость лицензий
__________________
полезное на axForum, github, vk, coub.
Старый 21.03.2017, 15:17   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом.
Почему? Они тупые? (С)

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

Цитата:
Сообщение от fed Посмотреть сообщение
Как в этом случае TCO посчитать ?
в этом случае достаточно констатации, что TCO будет неподъемной для целевой аудитории или существенно выше, чем у конкурентов.

Цитата:
Сообщение от fed Посмотреть сообщение
Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?
Дык, нет внедрения - нет владения.
нет владения - нет доходов от продажи у вендора.
нету ручек - нет конфетки.
https://www.youtube.com/watch?v=7KyZJ3xrreA

TCO - не единственный показатель )))
__________________
полезное на axForum, github, vk, coub.
Старый 21.03.2017, 15:26   #6  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mazzy Посмотреть сообщение
Почему? Они тупые? (С)

Я бы сформулировал так:
ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO),
ТО клиент просто не станет внедрять систему.
Так тут и стоит проблема: Обычно клиент требует замены стандартной логики, потому что риски и косты замены бизнес-процессов очень тяжело оценить. А риски и косты разработки - не очень. То есть - по разработке можно раза в 2-3 ошибится в оценке в худшем случае, а при смене бизнес-процессов - эдак раз в 30-50
Поэтом и дорабатывают так много...
За это сообщение автора поблагодарили: mazzy (2).
Старый 21.03.2017, 16:48   #7  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от mazzy Посмотреть сообщение
Почему? Они тупые? (С)
Большинству типичных клиентов AX - TCO это прежде всего вопрос нахождения надежного Партнера которому можно доверять. Затем возможности самой системы.
И только после этого - стоимость. Это только вендор думает что TCO на первом месте.

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

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

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

Последний раз редактировалось ax_mct; 21.03.2017 в 16:51.
Старый 21.03.2017, 17:01   #8  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
вот типичный пример программирования (или настройки) через XML-файлы от Microsoft
https://technet.microsoft.com/en-us/.../hh389762.aspx
попробуйте экстраполировать это на аксапту
Старый 21.03.2017, 17:47   #9  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от AlexeyS Посмотреть сообщение
вот типичный пример программирования (или настройки) через XML-файлы от Microsoft
https://technet.microsoft.com/en-us/.../hh389762.aspx
попробуйте экстраполировать это на аксапту
Новый узел в AOT содержащий файлы XML. При создании любого обьекта проверка на наличие XML файла c этим именем и применение другого обьекта или метода там указанного. В случае компиляции в CIL компиляция с учетом этой перезаписи.
Старый 21.03.2017, 17:48   #10  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
вот типичный пример программирования (или настройки) через XML-файлы от Microsoft
Это не очень хороший пример

Цитата:
"Нужна возможность замены любых классов и методов целиком"
Вот эта возможность, как принцип проектирования ПО называется 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.

Последний раз редактировалось Андре; 21.03.2017 в 17:53.
За это сообщение автора поблагодарили: ax_mct (5), mazzy (2).
Старый 21.03.2017, 18:21   #11  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от Андре Посмотреть сообщение
Это не очень хороший пример

Можно написать свою реализацию существующего интерфейса, задеплоить его в виде отдельного 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, ...
Старый 21.03.2017, 19:13   #12  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
А чем эта "замена любых классов и методов целиком через конфигурационные файлы" отличается от механизма слоёв в аксапте?
Замену нужно поддерживать в рантайм?
Количеством слоёв?
Как мержить два решения заменчющих оди и тот же класс, метод?
Старый 21.03.2017, 20:52   #13  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
А чем эта "замена любых классов и методов целиком через конфигурационные файлы" отличается от механизма слоёв в аксапте?
Замену нужно поддерживать в рантайм?
Количеством слоёв?
Как мержить два решения заменчющих оди и тот же класс, метод?
Отличие только в (почти) отстутствии технических конфликтов при обновлениях от вендора так как замена "сбоку", а не "сверху". Механизм слоев это как блин на блине, а подобная замена - возьми другой пирожок со сторонней полочки.

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

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

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

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

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

Последний раз редактировалось ax_mct; 21.03.2017 в 21:00. Причина: on-premise
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Что ж, поздравляю, долго ждал, когда представится возможность найти, до чего можно открыто придраться, и наконец-то "открыть личико". S.Kuskov Курилка 8 03.02.2011 11:19
MorphX: Научите "сохранять всенастройки непосредственно в основной базе данных (БД) ERP Axapta и возможность их настройки с использованием возможностей интерфейса MorphX" aidsua Курилка 4 05.06.2008 23:49
Нужна ли кнопка "Рекомендовать в Полезное"? mazzy Обсуждение форума 6 12.03.2007 10:21
В списке "Новые сообщения" добавлена возможность перехода на новое сообщение... mazzy Информация для участников 31 01.02.2007 19:31
Опрос: "Нужна ли на форуме пополняемая база данных об ошибках и недоделках Аксапты" ? Zabr Обсуждение форума 93 13.11.2004 20:08
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:30.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.