Как вы оцениваете доработки D365FO Enterprise

[EVGL]

Цитата:

Сообщение от raz

ИМХО, x4.
x2 - чисто разработка,
еще x2 - анализ кода (сейчас не найдешь где идет присвоение, как раньше по перекресным ссылкам с типом write) и билдинг, синхронизация, рестарт (это просто нечто временами).

Я свои x2 как раз из-за этого написал: большая трата времени на отладку. Особо пикантно становится, когда и ISV, и ваш код цепляет обработчик на один и тот же метод типа *JournalPost.run(). Начинает беспорядочно вызываться один, другой. Хотя это и в AX2012 уже было. Чего не было в AX2012, так это перезапусков и ожидания, пока отладчик все загрузит. Меня в свое время коллеги почему-то не понимали, когда я указывал на разницу в трудозатратах как между интерпретатором типа SQL или R и компилятором типа C#.

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

[belugin]

Цитата:

Сообщение от EVGL

Чего не было в AX2012, так это перезапусков и ожидания, пока отладчик все загрузит. Меня в свое время коллеги почему-то не понимали, когда я указывал на разницу в трудозатратах как между интерпретатором типа SQL или R и компилятором типа C#.

В C# есть Edit and continue JFYI.

Особенность Ax, в том что сейчас там есть гигантский монолитный модуль Application Suite, который превращается в гигантскую сборку, которую приходится разбивать на netmodules. Если работать внутри модуля поменьше и настроить VS так чтобы он не грузил символы для других сборок, то все более менее прилично.

[raz]

Цитата:

Сообщение от EVGL

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

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

[trud]

Цитата:

Сообщение от raz

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

А вот кстати интерестно зачем это делать?(кроме конечно случаев когда разработчику выгоднее потратить больше времени)
ну т.е. сейчас использование оверлея по большей части не является даже ошибкой Best practice(там где это возможно)
кроме того, даже для таких базовых вещей как дисплей методы extension возможности далеко не финализированы

Цитата:

In an upcoming platform update we hope to provide a much more intuitive way of adding display methods, however the above approach will keep being supported.

и народ на яммере репортит кучу глюков по chain-of-command
т.е. на мой взгляд надо просто стараться не особо менять стандарт и делать более обособленные изменения, но тратить время на поиски куда вклиниться нужно только если клиент конкретно за это будет платить(плюс сюда еще включать часы на регистрацию extensions requests на коннект) т.е. данное время надо прибавлять к x2, причем занимает в отдельных случаях это довольно много(иногда больше чем выполнение модификации)