Прощай, X++

[ax_mct]

Цитата:

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

Я не писал аддонов, но по опыту работы со скриптами не заметил никкакой обратной несовместимости - что там требуется кроме перебития номера версии в референсах? Тут говорял что аддины обратно совместимы.

Это как "повезет" или как о совместимости "позаботятся".
Пойнт в том что использовать вызовы "системного" кода такого как WinAPI или популярные стандартные библиотеки - это одно (основываться на текущем фундаменте или на старом фундамента который оставили для совместимости),
а ссылаться на прикладной слой (который меняется) это как на живом существе мансарду строить.
Вы можете сделать в AX свой независимый модуль который будет использовать только свои собственные обьекты AOT (классы, таблицы и прочее) и все может быть хорошо.
Но как только вы используете или ссылаетесь на "не свое" - оно может и более того должно меняться со временем. Это нормально.
Так как чаще всего то что мы имеем в AOT это не "интерфейс", это внутренности сложного существа где все слишком переплетено. Начнем отделять один орган - порвем другие.
Для работы со сторонними системами совместимость интерфейсов (данных, программного) необходима, но для внутренней работы AX это делать нельзя - живой и сложный организм помрет от такой целесообразности.

Цитата:

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

Почему интерфейс обязан меняться при этих изменениях?

Меняется функциональность - меняется все. Это оправданно. А то наш глаз который мы пристроили на лоб может оказаться совсем на другом месте просто потому что тело перевернули.

Цитата:

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

Меньше строчек надо поддерживать. Меньше возможности внести ошибку.

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

Цитата:

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

Еще забыли SSRS.
Интеграцией с VS, моделями, компиляцией (в IL?) можно не пользоваться. Функционал не является средством разработки.
Как по вашему, что из перечисленного внесло наибольший вклад в усложнение разработки?

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

Думаю что все понемногу внесло в усложнение разработки. Так как не одна составляющая усложнилась а почти все. И в каждом конкретном случае это по разному.