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

[twilight]

***Тема выделена из Состояние рынка труда разработчик Axapta, Москва //oip ***

Цитата:

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

P.S. надо бы изучать 2012, я, например, без хоть какого-то опыта в 2012 сейчас не рассматриваю в штат.

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

[Ivanhoe]

Вот только первый проект на AX 2012 разработчик делает в 1,5-2 раза дольше. Ну и с оценками промахивается. Можем в отдельной теме обсудить

[Pustik]

С точки зрения разработчика, не вижу проблем работы для кандидата, знающего и имеющего опыт работы в АХ в предыдущей версии. С точки зрения консультанта, возможно, что это не так. Но давайте подумаем, насколько консультант, знающий АХ2009, отличается от себя самого "якобы" знающего АХ2012. И теперь также, только для разработчика?

[gl00mie]

Цитата:

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

С точки зрения разработчика, не вижу проблем работы для кандидата, знающего и имеющего опыт работы в АХ в предыдущей версии.

- стоит задача при разноске банковской выписки тянуть определенную фин.аналитику для банковского счета из счета контрагента.
- а, ну это я щас подтяну Dimension[4]. Ой, а где всё?..
- стоит задача создать артефакты контроля доступа для метода сервиса, вызываемого через SysOperation framework.
- а, ну это я щас SecurityKey повешу на пункт меню. Ой, а где всё?
- стоит задача добавить новый класс-наследник в иерархию классов, использующую SysExtension framework.
- а, ну это я щас пару строк кода в switch добавлю для своего наследника. Ой, а где ж оно? Что еще за атрибуты?..
- стоит задача доработать интеграцию стороннего приложения с Аксаптой.
- сейчас быстренько дернем .NET Business Connector. Ой, приложение не в том же домене работает? Какие-такие веб-сервисы?..
- стоит задача сделать импорт продуктов из Excel-файла.
- это импорт номенклатуры что ли? так у меня уже готовый код есть, с проекта на проект таскаю. Ой, а чего за EcoRes*-таблицы? А как мне теперь добавить значение аналитики "размер"?..
- стоит задача доработать кастомизацию, отрабатывающую на validateWrite() такой-то стандартной таблицы.
- ну это как два пальца... ой, тут ведь только sys-слой, а где же код кастомизации-то? какие-такие pre-/post-обработчики событий?..
- стоит задача реализовать обобщенный код, который в зависимости от типа переданного табличного буфера...
- как нечего делать. Ой, а разве buffer.tableId не определяет однозначно таблицу? Что еще за InstanceRelationType?..
- стоит задача реализовать lookup-форму с парой закладок.
- это вообще детский сад. Ой, а что это за ReferenceGroup такой? И почему моя lookup-форма вместо исходной записи, на поле которой вызывается, получает в аргументах запись моего же справочника, который я показываю в lookup'е?
- стоит задача разобраться, почему интерактивно периодическая операция отрабатывает нормально, а в пакете - валится.
- этим нас не напугаешь, щас вот в консоли пакетного сервера аксаптовый отладчик запущу, включу глобальные точки останова... Ой, какой-такой CIL?..
- etc.

[Logger]

Спасибо за сравнение.
Интересно было бы теперь сравнить что стало проще и быстрее для разработки а что медленнее и сложнее (читай - дороже).

[EVGL]

Цитата:

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

Спасибо за сравнение.
Интересно было бы теперь сравнить что стало проще и быстрее для разработки а что медленнее и сложнее (читай - дороже).

Легко: дороже стало, а чтобы проще и быстрее - нет, такого не припомню.
Я бы теперь смело умножал затраты на разработку и настройку на 1,5 - 2.

[Ivanhoe]

Просьба к модераторам выделить обсуждение разработки 2012 в отдельную ветку. Там и продолжим

[oip]

Выделил в отдельную тему. Ну и заодно напомню свою прошлогоднюю запись.
axforum blogs: Небольшой опыт перевода собственного модуля AX 4.0 -> AX 2009 -> AX 2012R2

Цитата:

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

Интересно было бы теперь сравнить что стало проще и быстрее для разработки

Краткий ответ: ничего. Разве что какие-то мелочи, но на общем фоне это несущественно.

[Ivanhoe]

Добавлю еще про отчетность - Reporting services конкретно другой зверь. Про разработку для POS я вообще молчу.

[twilight]

В OLAP стало проще работать с датой, так как теперь Аксапта генерит собственные таблицы для дат (раньше использовалось стандартное измерение времени в OLAP), которые можно модифицировать как угодно по своему усмотрению.

[CDR]

По-моему, происходит некоторая подмена понятий.

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

Например:

Использование шаблонов форм, создание типичных форм сейчас стало проще и быстрее.

Использовать SysOperation, как оказалось, действительно проще и быстрее, чем RunBase. Особенно, добавив несколько своих атрибутов для стандартных задач (например, SysOperationControlAllowEditAttribute)

Написание excel-отчетов используя XmlExcelReport_RU стало в разы проще и быстрее.

Создание Date-Effective таблиц стало проще и быстрее.

Архитектура финансовых аналитик стала сложнее, но для 90% практических задач трудоемкость практически не изменилась. А если взять довольно часто встречающуюся задачу отражения какого-либо справочника системы в фин. аналитику, то сделать это стало значительно проще и быстрее.

В общем, да, очень много стало по-другому. Но это != сложно.

[EVGL]

Цитата:

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

Использование шаблонов форм, создание типичных форм сейчас стало проще и быстрее.

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

Цитата:

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

Использовать SysOperation, как оказалось, действительно проще и быстрее, чем RunBase. Особенно, добавив несколько своих атрибутов для стандартных задач (например, SysOperationControlAllowEditAttribute)

Во многом проще и определенно технологичнее, но чем-то сложнее, т.к. появляются траблы с отладкой и надо писать три класса вместо одного.

[belugin]

Цитата:

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

надо писать три класса вместо одного.

От двух (контракт, действие) до четырех (контракт, контроллер, действие, UI builder).
А почему трудоёмчее написать три класса, чем один в котором все вперемешку?

[Logger]

Цитата:

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

От двух (контракт, действие) до четырех (контракт, контроллер, действие, UI builder).
А почему трудоёмчее написать три класса, чем один в котором все вперемешку?

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

[Ivanhoe]

Цитата:

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

По-моему, происходит некоторая подмена понятий.

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

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

Цитата:

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

Использование шаблонов форм, создание типичных форм сейчас стало проще и быстрее.

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

Цитата:

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

Написание excel-отчетов используя XmlExcelReport_RU стало в разы проще и быстрее.

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

Цитата:

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

Создание Date-Effective таблиц стало проще и быстрее.

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

Цитата:

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

Архитектура финансовых аналитик стала сложнее, но для 90% практических задач трудоемкость практически не изменилась. А если взять довольно часто встречающуюся задачу отражения какого-либо справочника системы в фин. аналитику, то сделать это стало значительно проще и быстрее.

Вы уверены? А удаления, апдейты? А просто тестовые данные почистить? А разобраться с ОСВ и понять почему она тормозит? А куча таблиц и вьюх, по которым можно просто историю развития вопроса изучать. Сделали сначала "красиво", а потом - начали костыли расставлять по всей системе, ибо не работало.

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

[EVGL]

Цитата:

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

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

Недавно делал демо, в котором Blocked для номенклатуры ставился "передним числом", своего рода Product Lifecycle для бедных. Сделал вместо поля таблицу, добавил effectivity и понял, что чудес не бывает: для конкретной задачи все равно пришлось писать код и насиловать интерфейс.

Но, как минимум, теперь есть шаблон для подобных разработок, что хорошо.

[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%?

[trud]

Цитата:

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

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

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

[gl00mie]

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

[belugin]

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

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

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