А что такого принципиального в 2012? По моему хороший разработчик без труда в ней разберется

[belugin]

Цитата:

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

только для SysOp-ов больше вероятность ошибки на копипасте.

А почему больше - по идее там избыточность меньше. В стандартном случае никаких DialogField не требуется. Даже main не обязательно копипастить.

[CDR]

Цитата:

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

Слово "проще" появилось не с самого начала. Изначально тема возникла из моего видения, что разработчик в AX 2012 потратит больше времени на аналогичную задачу. При этом я могу судить по десяткам разработчиков и десятку проектов, к которым я имею непосредственное отношение.

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

Цитата:

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

Не соглашусь. Одни кнопки чего стоят. А если делать "красивые" формы как в стандарте (ListPage), то это намного больше времени. И дело не в программисте, технологии или еще чем - просто в AX 2012 теперь так.

А чего кнопки стоят? Картинку приделать? Так я сейчас наоборот получаю эстетическое удовольствие от этого. В ListPage так же не вижу ничего сложного - квери, простой класс и элементарная форма. Зато получается единый интерфейс.

Цитата:

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

У всех уважаемых разработчиков давно есть свое семейство классов для таких отчетов.

А также свои панельки, модульчики, скриптики и прочие прибацончики. Это ведь так понятно и просто. А вот научиться пользоваться хотя бы той же системой контроля версий... Неее, это сложно!

Цитата:

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

А все остальные репорты в RS - с ним разбираться с нуля очень сложно, для многих очень-очень сложно.

Для многих вообще в чем-либо разбираться - это очень-очень сложно.

Цитата:

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

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

Везде, где используются поля "Дата С" и/или "Дата По". Это различные ставки, курсы, цены, прайсы, планы, прогнозы и т.п.

Цитата:

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

А разобраться с ОСВ и понять почему она тормозит?

Разобраться с ОСВ (особенно модульными) и в предыдущих версиях было тем еще челенджем.

Цитата:

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

Еще раз сформулирую свою мысль. Аналогичный проект AX 2012 первый раз разработчик делает в 1,5 - 2 раза дольше. Второй и дальше - дольше процентов на 20%. По консам похожие цифры.

Ну так в итоге стало сложнее в 1,5-2 раза? или на 20%?

[Ivanhoe]

Сложнее - это нужен более "умный разработчик"? Тогда действительно, у нас термины расходятся . По мне сложнее - больше усилий нужно. Либо более умный разработчик (читай опытный), либо больше времени. Пока разработчик не опытный - он делает дольше. Вот и получается в два раза медленнее.

Когда он станет опытным - разница не в разы, но все равно остается. Сложнее стала система (больше элементов). И бюджеты растут, и требования. Все сложнее. Просто нужно это принять.

[Wamr]

Цитата:

Inside Microsoft Dynamics AX 2012
"Of course, the developers had several perspectives on this breakthrough event.
One morning when we came to work, nothing was working. Later in the
morning, we realized that we had changed programming languages! ...."

Все разработчики попали в похожую ситуацию с выходом AX2012. Весь n-летний опыт сильно сократился и, естественно, мы стали тратить на задачи также как любые стажеры в DAX. И это не 1-2 раза, а 4+ на первых модифах. Но опыт нарабатывается быстро (при наличии проектов) и через годик эффективность возвращается на прежний уровень.
Так что, на мой взгляд, дело не в сложности, а в освоении новых шаблонов проектирования, программирования, решения стандартных задач.

[trud]

Цитата:

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

Везде, где используются поля "Дата С" и/или "Дата По". Это различные ставки, курсы, цены, прайсы, планы, прогнозы и т.п.

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

[CDR]

Цитата:

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

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

Какое тонкое понимание технологии, снимаю шляпу.

А если серьезно, то я имел ввиду реализацию какого-либо планового/прогнозного показателя внутри одного плана.

Ну, например, есть оптимистичный план "А" на год. В этом плане прогнозируется среднедневное значение какого-то показателя для определенных интервалов дат. А есть пессимистичный план "Б" на год, в котором этот же показатель прогнозируется немного подругому, и, возможно, для других интервалов дат.

А вообще в AX, как и в любой другой системе, есть объекты, а есть их характеристики. Так вот как только возникает практическая задача хранить изменения какой-либо характеристики во времени (а такие задачи возникают довольно регулярно), то сразу же можно использовать Date-Effective таблицы.

Но это сложно.
Значительно проще по старинке закодировать обычные таблицы историй, значений и пачку методов типа findCurrent(), findOnDate() и т.п.

[CDR]

Цитата:

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

Так что, на мой взгляд, дело не в сложности, а в освоении новых шаблонов проектирования, программирования, решения стандартных задач.

This.

[gl00mie]

Подниму еще раз тему.

Цитата:

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

Сложнее стала система (больше элементов). И бюджеты растут, и требования. Все сложнее. Просто нужно это принять.

С этой точки зрения кажется интересным обсуждение конца 2010-го года В какой системе быстрее вести разработку? AX или NAV:

Цитата:

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

Определение: "быстрее вести разработку" значит добиваться заранее определенных результатов посредством программирования за меньшее время.
Ответ: быстрее вести разработку в той системе, где связей меньше.
Пояснение: "скорость разработки" зависит не от удобств самой системы, а от количества объектов, которые затрагиваются (прямо или косвенно) данной разработкой.
Следствие: Чем более функционально развитая система, тем больше вероятность зацепить большое количество системных объектов. Тем больше вероятность "медленной" разработки.

Возможно, этим и объясняется увеличение времени на разработку:

Цитата:

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

Еще раз сформулирую свою мысль. Аналогичный проект AX 2012 первый раз разработчик делает в 1,5 - 2 раза дольше. Второй и дальше - дольше процентов на 20%. По консам похожие цифры.

[belugin]

Количество связей зависит так же от качества проектирования (вспомним всякие Law of Demeter).

Также обычно интересуют связи в какой-то выделенной области.
К сожалению, среда X++ не поддерживает разбиение кода на Namespaces/Packages то есть размер областей, на которые можно формально разбить довольно велик + даже, если такое будет сделано, само по себе приложение не разбито на куски с контролируемыми связями и разбиение будет трудоемко.

Еще часть абстракций в 2012 довольно "дырявые" например, для работы с LedgerDimension необходимо знать их внутреннюю структуру + не поддерживается польностью MorphX на уровне остальных типов данных (кроме бросания поля на форму надо еще создавать спецобъекты для управления контролом).

[gl00mie]

Так это "да" или "нет"? Или "да" + "еще зависит от количества связанных дырявых абстракций, подноготную которых надо знать"?

[belugin]

Цитата:

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

Так это "да" или "нет"? Или "да" + "еще зависит от количества связанных дырявых абстракций, подноготную которых надо знать"?

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