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

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

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

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

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

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

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

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

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

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

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

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

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

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

======================
собственно вопрос:
Снизит ли "возможность замены любых классов и методов целиком" трудоемкость в долгосрочной перспективе?
Снизит ли TCO?
__________________
Facebook, mazzy.priot, mazzy.music, coub.
Старый 21.03.2017, 15:00   #2  
EVGL is offline
EVGL
Moderator
Лучший по профессии 2014
Соотечественники
 
3,390 / 1833 (68) ++++++++
Регистрация: 09.07.2002
Адрес: AT
Здорово заниматься абстракциями, а не внедрением на клиенте, да?

Стоимость владения теперь в основном определяется Microsoft и составляет как минимум 200 евро в месяц за голову. Эта стоимость владения определяется Excel'ем на рабочем столе у Мишель Матисс в Сиэтле, а также входными параметрами, заданными ее руководством и целевым бюджетом. 200 евро могут стать с июля 250, могут стать 300, а могут - 150 или вообще не измениться. Вот и попробуйте оценить ТСО в долгосрочной перспективе.
Старый 21.03.2017, 15:01   #3  
fed is offline
fed
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Ex AND Project
Соотечественники
 
2,028 / 3731 (129) ++++++++++
Регистрация: 13.03.2002
Адрес: İstanbul
Ты не совсем правильно вопрос ставишь. Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом. Как в этом случае TCO посчитать ? Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?
За это сообщение автора поблагодарили: EVGL (1).
Старый 21.03.2017, 15:11   #4  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,472 / 3148 (145) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
Здорово заниматься абстракциями, а не внедрением на клиенте, да?
Почему или-или?

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

Цитата:
Сообщение от EVGL Посмотреть сообщение
Стоимость владения теперь в основном определяется Microsoft и составляет как минимум 200 евро в месяц за голову.
Конечно же, нет.
Конечно же, это не стоимость владения, а всего лишь одно из слагаемых - стоимость лицензий
__________________
Facebook, mazzy.priot, mazzy.music, coub.
Старый 21.03.2017, 15:17   #5  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,472 / 3148 (145) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом.
Почему? Они тупые? (С)

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

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

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

TCO - не единственный показатель )))
__________________
Facebook, mazzy.priot, mazzy.music, coub.
Старый 21.03.2017, 15:26   #6  
fed is offline
fed
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Ex AND Project
Соотечественники
 
2,028 / 3731 (129) ++++++++++
Регистрация: 13.03.2002
Адрес: İstanbul
Цитата:
Сообщение от mazzy Посмотреть сообщение
Почему? Они тупые? (С)

Я бы сформулировал так:
ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO),
ТО клиент просто не станет внедрять систему.
Так тут и стоит проблема: Обычно клиент требует замены стандартной логики, потому что риски и косты замены бизнес-процессов очень тяжело оценить. А риски и косты разработки - не очень. То есть - по разработке можно раза в 2-3 ошибится в оценке в худшем случае, а при смене бизнес-процессов - эдак раз в 30-50
Поэтом и дорабатывают так много...
За это сообщение автора поблагодарили: mazzy (2).
Старый 21.03.2017, 16:48   #7  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,424 / 412 (16) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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
Участник
 
314 / 204 (7) ++++++
Регистрация: 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
Участник
Аватар для ax_mct
 
1,424 / 412 (16) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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,371 / 444 (19) +++++++
Регистрация: 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.
За это сообщение автора поблагодарили: mazzy (2), ax_mct (5).
Старый 21.03.2017, 18:21   #11  
AlexeyS is offline
AlexeyS
Участник
 
314 / 204 (7) ++++++
Регистрация: 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
Участник
Лучший по профессии 2014
 
3,088 / 1513 (57) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
А чем эта "замена любых классов и методов целиком через конфигурационные файлы" отличается от механизма слоёв в аксапте?
Замену нужно поддерживать в рантайм?
Количеством слоёв?
Как мержить два решения заменчющих оди и тот же класс, метод?
Старый 21.03.2017, 20:52   #13  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,424 / 412 (16) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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:09.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.