Прощай, X++

[belugin]

Цитата:

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

Такова суть AX - заплатки и обновления. Куча. Смена языка ничего не изменит.
И строгие пространства имен и прочее ни на что не повлияют в этом плане.

Аргументируйте.
Как вы считаете каковы причины того, что мы можем практически безболезненно перейти на новую версию Windows и при этом обновление версии AX является "проектом".

Цитата:

Это всего лишь гаечный ключ к монстру

Это не гаечный ключ а способ описания реализации.

Цитата:

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

Почему вы так считаете?

[ax_mct]

Цитата:

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

Аргументируйте.
Как вы считаете каковы причины того, что мы можем практически безболезненно перейти на новую версию Windows и при этом обновление версии AX является "проектом".

Если у нас есть приложение в Windows которые использует WinAPI напрямую или определенную версию библиотеки (неважно MFC это или .NET Framework) то переход на новую версию Windows может быть безболезненным для данного приложения.

Если у нас есть Add-In или Add-On к MS Word (Excel, Project) например версии 2007 то поддержка следующих версий тоже будет требовать как минимум "проекта".

Наше программирование в AX практически всегда является "Add-In" или "Add-On" поверх прикладного кода который может меняться.

Цитата:

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

Это не гаечный ключ а способ описания реализации.

АХ для меня такой большой угловатый механизм, комбайн функционала. Нелепый такой но полезный монстр.
Среда разработки и язык программирования это всего лишь гаечный ключ к монстру. Инструмент, не более того.

"Картостроение" и "паковка" применительно к АХ это прежде всего функционал. А маленькие радости и горести программистов в мире строчек кода это извращения узкого круга гиков.
Вот объясните бизнесу как вам хорошо от того что вы можете вместо трех строчек кода написать одну и от этого просто оргазмируете. Или даже то что айяяй - один и тот же код в десяти местах вместо одного.

Цитата:

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

Почему вы так считаете?

С приходом AX 2012 и множества полезностей разработка стала только дороже и дольше. Цена за интеграцию c VS, модели, компиляцию и более сложный фунционал. Это не плохо, это просто более дорогой ремонт более сложного механизма.
В соседней теме звучало мнение о субьективных 30%-40% относительно к старым версиям AX:

Впечатления от работы с MSDAX 2012

[belugin]

Цитата:

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

Если у нас есть Add-In или Add-On к MS Word (Excel, Project) например версии 2007 то поддержка следующих версий тоже будет требовать как минимум "проекта".

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

Цитата:

Наше программирование в AX практически всегда является "Add-In" или "Add-On" поверх прикладного кода который может меняться.

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

Цитата:

Вот объясните бизнесу как вам хорошо от того что вы можете вместо трех строчек кода написать одну и от этого просто оргазмируете. Или даже то что айяяй - один и тот же код в десяти местах вместо одного.

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

Цитата:

Цена за интеграцию c VS, модели, компиляцию и более сложный фунционал.

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

Как по вашему, что из перечисленного внесло наибольший вклад в усложнение разработки?

[ax_mct]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

Вы не поверите, но у WinApi за фасадом тоже кое-что меняется. Разумеется, для более мелкого рынка в backwards compatibility вкладывают меньше (у джоэла была история о том, что для поддержки Sim City эмулировали баг)

Цитата:

Так как чаще всего то что мы имеем в AOT это не "интерфейс", это внутренности сложного существа где все слишком переплетено. Начнем отделять один орган - порвем другие.

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

Цитата:

Меняется функциональность - меняется все. Это оправданно.

Знаком ли вам open closed principle проектирования?

Цитата:

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

То есть вы считаете что то, что вы называете "красотой кода" никак не связано с количеством ошибок и временем разработки?

Цитата:

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

Вот вам пример про хорошо спроектированную программу. Редактор кода внутри AX2012 - это компонент Visual Studio. Разработчики VS не знали, что редактор планируют вставить куда-то еще и никак не дорабатывали его для Ax2012. Но кусок одной программы оказалось можно вставить в другую программу, при помощи расширений обучить возможностям другого языка и теперь, если вам нужно подсветку парных скобочек или свертывание и развертывание тела if - вы можете просто взять готовое расширение (по ссылке фактически скомпилированные стандартные примеры для VS SDK).

- эти расширения практически не надо тестировать для работы в AX
- разработчики VS знают, что они могут менять без нарушения работы расширений
- вам не надо изучать реализацию редактора VS, а только его интерфейс чтобы его расширить

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

[RVS]

Цитата:

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

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

Можно, ессно.. а оно НАДО?

Больно смотреть на то, как из нормального продукта (Аксы) делают.. полуфабрикат под свой вкус.

ЗЫ : на вкус и на цвет все фломастеры - разные )

[belugin]

Цитата:

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

Можно, ессно.. а оно НАДО?

Что именно оно? Отделять интерфейс от реализации?

Цитата:

Больно смотреть на то, как из нормального продукта (Аксы) делают.. полуфабрикат под свой вкус.

ЗЫ : на вкус и на цвет все фломастеры - разные )

Тут вопрос не вкуса а вполне конкретных потребительских свойств.

[ax_mct]

Цитата:

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

...
Я не говорю, что для прикладного кода можно достигнуть совершенно такой же легкости и обратной совместимости, но думаю, можно существенно продвинуться относительно текущего состояния.
…
Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек
…
Почему нельзя использовать те же принципы (...прекрасные детальки Tables, Forms, Maps…) для прикладного кода?
…
Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор
…
Наличие отделения интерфейса от реализации позволит сделать изменения более быстрыми и дешевыми

С точки зрения клиента это жалобы кочегара на пароходе. Который хочет чтобы лопата была удобнее, топка пониже и уголь лежал так чтобы его было удобнее бросать.

С точки зрения программиста это нереально (или нереально дорого) отделить интерфейс от реализации для прикладной логики в AX. Дорого и неоправданно.

Цитата:

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

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

Это возможно из-за "зафиксированного" расположения внутренних органов вместе с их одинаковыми функциями.
Прикладной же код АХ это метаморф с постоянным изменением места внутренних органов и даже их функций.

Цитата:

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

Знаком ли вам open closed principle проектирования?

Сlasses, modules and functions should be open for extension but closed for modifications.
Невозможно для прикладного кода AX. Это смерть для нее.

Цитата:

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

То есть вы считаете что то, что вы называете "красотой кода" никак не связано с количеством ошибок и временем разработки?

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

AX это вещь для потребителя. Программист AX не является ее потребителем а просто обслуживающий персонал.

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

[belugin]

Цитата:

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

С точки зрения программиста это нереально (или нереально дорого) отделить интерфейс от реализации для прикладной логики в AX. Дорого и неоправданно.

Он уже отделен в какой-то мере (посмотреть слова "интерфейс" и "реализация" в словаре, применить к любому классу прикладной логики AX)

Цитата:

Представьте что вы заказываете себе строительство дома. И вам чихать на стандарты строителей

Мне кажется опять не очень удачная метафора: во-первых, это топик для строителей, во-вторых, мне не чихать, построили дом в соответствии со стандартами или нет; в третьих вам не чихать, так как вы это продолжаете обсуждать

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

Цитата:

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

Аргументируйте.
Как вы считаете каковы причины того, что мы можем практически безболезненно перейти на новую версию Windows и при этом обновление версии AX является "проектом"

Потому что Windows - продукт коробочный, сценарии его использования и интерфейсы с другими программными продуктами заранее известны его разработчикам (а точнее ими же и диктуются).
DAX же как правило используется как конструктор "собери сам".

Если Windows выпускали бы как такой же конструктор и конечный продукт формировался для каждого клиента индивидуально, переход на новую версию был бы сопряжен с теми же трудностями.

Примеры для AX 3 - 4- 2009:
1) Внедренцы DAX внедрили стандарт. Они будут переходить более менее безболезненно на новые версии, правда пользователей придется переучивать согласно новым тренингам и надеяться, что новые уникальные индексы уживутся со старыми данными.

2) Внедренцы DAX полностью проигнорировали стандартное приложение и запилили рядом свое с домино и медведями. Они на новые версии DAX будут переходить вообще без проблем.

[belugin]

Цитата:

Сообщение от Кирилл

Потому что Windows - продукт коробочный, сценарии его использования и интерфейсы с другими программными продуктами заранее известны его разработчикам (а точнее ими же и диктуются).
DAX же как правило используется как конструктор "собери сам".

Если Windows выпускали бы как такой же конструктор и конечный продукт формировался для каждого клиента индивидуально, переход на новую версию был бы сопряжен с теми же трудностями.

Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек. Например Visual Studio Shell - это конструктор.

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

[dech]

Цитата:

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

Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек. Например Visual Studio Shell - это конструктор.

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

Именно Reflection делает АХ пластилином, в остальном, простите, не соглашусь. Если представлять все четко, то и код будет четким. Если мысли плавают, то и код будет не то чтобы "пластилиновым", а скорее требующим исправлений. И тестировать такой код не так-то просто, т.к. не ожидаешь где может вылезти баг.
Лично для меня на 1 месте UnitTest, на 2-м рефакторинг со всеми БП... Без модульных тестов рефакторинг если и возможен, то нет уверенности в том, что вы ничего не сломаете. И все, никакого пластилина. Пользовательский тест обычно всегда после этого срабатывает.

[belugin]

Цитата:

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

Именно Reflection делает АХ пластилином, в остальном, простите, не соглашусь.

Я имел ввиду что принято менять объекты вместо того, чтобы их расширять.

Цитата:

Лично для меня на 1 месте UnitTest, на 2-м рефакторинг со всеми БП... Без модульных тестов рефакторинг если и возможен, то нет уверенности в том, что вы ничего не сломаете.

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

Те юниты которые есть часто не соответствуют понятиям предметной области или реализуют их неустойчивыми интерфейсами.

Например нет такой сущности как "Журнал ГК" - его логика реализована в форме, таблицах, LedgerJournalEngine и прочем. Причем то, что реализовано в форме не имеет нормального программного интерфейса.

Цитата:

И все, никакого пластилина. Пользовательский тест обычно всегда после этого срабатывает.

Не могли бы вы написать про то, какие вы тесты обычно пишете на примере какой-нибудь из конкретных разработок?

Цитата:

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

Например нет такой сущности как "Журнал ГК" - его логика реализована в форме, таблицах, LedgerJournalEngine и прочем. Причем то, что реализовано в форме не имеет нормального программного интерфейса.

Это был выбор самих разработчиков стандарта, а не диктат языка программирования или архитектуры системы. При желании можно реализовать сущность "Журнал ГК" в полном соответствии с вашими требованиями и на X++.
Перенести всю логику из таблиц и форм, в классы, оставив там только вызовы соответствующих методов этих классов.

[belugin]

Цитата:

Сообщение от Кирилл

Это был выбор самих разработчиков стандарта, а не диктат языка программирования или архитектуры системы. При желании можно реализовать сущность "Журнал ГК" в полном соответствии с вашими требованиями и на X++.

На текущем X++ и MorphX это нельзя сделать. Например, ничего кроме таблиц и view нельзя привязать к гриду.

Цитата:

Перенести всю логику из таблиц и форм, в классы, оставив там только вызовы соответствующих методов этих классов.

Сами вызовы тоже есть атрибуты сущности. Попробуйте например сделать такую форму и класс, чтобы переход с хранения AccountNum на LedgerDimension был прозрачен для использующего кода.

Цитата:

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

Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек. Например Visual Studio Shell - это конструктор.

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

В противопоставлении легкости накатывания новой версии Windows "проекту перевнедрения" DAX суть в том, что код Windows недоступен клиенту для доработки.

В примере Visual Studio Shell - это продукт, потребителем которого является программист, который всю логику потом и запиливает, но потом не может продать конечный продукт никому кроме себя.
Это аналог использования DAX исключительно как средства разработки, в DAX тоже есть прекрасные детальки Tables, Forms, Maps и т.д.

[belugin]

Цитата:

Сообщение от Кирилл

В противопоставлении легкости накатывания новой версии Windows "проекту перевнедрения" DAX суть в том, что код Windows недоступен клиенту для доработки.

Linux, Eclipse доступен клиенту для доработки - многие ли пользуются этим по сравнению с теми, кто используют публичные интерфейсы?

Цитата:

Это аналог использования DAX исключительно как средства разработки, в DAX тоже есть прекрасные детальки Tables, Forms, Maps и т.д.

Почему нельзя использовать те же принципы для прикладного кода?

Цитата:

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

Linux, Eclipse доступен клиенту для доработки - многие ли пользуются этим по сравнению с теми, кто используют публичные интерфейсы?

А многие пользуются коробочными учетными системами по сравнению с теми, кто использует допиливаемые учетные системы?

Все есть яд и и все есть лекарство, вопрос в дозах и условиях применения.

Цитата:

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

Почему нельзя использовать те же принципы для прикладного кода?

Разные потребители.
Прекрасными детальками пользуется программист. Он мыслит категориями "могу".
Деталька предоставляет такие-то сервисы и накладывает такие-то ограничения и область применения. В итоге программист использует детальку только так, как это задумал ее автор, либо не использует.

Потребителем прикладного решения является заказчик. Он мыслит категориями "хочу" и может захотеть что-либо, находящееся вне области применения, заданной нашей прекрасной системой без пластилина.
И тут перед программистом встает дилемма. Либо отказаться от денег, либо от принципов

Учетные системы их разработчиками задуманы как способ рубки бабла, а не абстрактная "вещь в себе", так что от денег отказываться никто не будет.

[belugin]

Цитата:

Сообщение от Кирилл

Разные потребители.
Прекрасными детальками пользуется программист. Он мыслит категориями "могу".
Деталька предоставляет такие-то сервисы и накладывает такие-то ограничения и область применения. В итоге программист использует детальку только так, как это задумал ее автор, либо не использует.

В любом случае детальками пользуется программист (и в коробочном и в пластилиновом).

Цитата:

Потребителем прикладного решения является заказчик. Он мыслит категориями "хочу" и может захотеть что-либо, находящееся вне области применения, заданной нашей прекрасной системой без пластилина.
И тут перед программистом встает дилемма. Либо отказаться от денег, либо от принципов

Принципы придуманы для денег. Например, чтобы легче было менять и переходить на следующие версии. Сейчас X++ содержит очень мало возможностей, чтобы разработчики стандартного формально объяснить "если не будешь это менять, в следующей версии код продолжить работать, а если поменяешь, то я не ручаюсь". В результате программист не может сказать заказчику "Подумайте, я могу это сделать, но при переходе на следующую версию будет геморрой - стоит ли оно того" так как геморрой будет в любом случае потому, что интерфейс не отделен от реализации и нет достаточных способов не меняющего расширения.

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

Цитата:

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

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

Можно все перевести на полиморфизм, но это будет другой продукт.
И язык тут вторичен. В том же X++ есть удачные примеры типа RunBaseBatch или SalesFormLetter