Прощай, X++

[Logger]

Цитата:

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

Ну насколько помню, там breakpoint не на что поставить. И рекурсии на каждом шагу. А еще возможность написать всю программу в одну строку. Ну и конечно же ФП чемпион по возможностям мета-программирования.
Лучше такой инструмент в руки прикладных аксапщиков не давать. Я бы и контейнеры с макросами убрал бы от шаловливых ручек подальше.

Вот-вот !
Нужно думать еще о том какого уровня спецы будут потом систему поддерживать.
Спички детям не игрушка.

[ax_mct]

Цитата:

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

Вот-вот !
Нужно думать еще о том какого уровня спецы будут потом систему поддерживать.
Спички детям не игрушка.

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

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

И бог с ним с X++, какая разница на чем программировать. Но если вдруг это приведет к тому что в AX будут программировать junior .NET программисты без опыта в AX то мне жалко и клиентов и систему. Не в синтаксисе дело.

[dech]

Цитата:

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

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

Простите, но если вы даже на Х++ будете писать "код с душком", коллеги вас когда-нибудь побьют.

[ax_mct]

Цитата:

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

Простите, но если вы даже на Х++ будете писать "код с душком", коллеги вас когда-нибудь побьют.

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

Душок, не душок, но если нет ошибок Best Practices - значит код допустимый.
Я не про свой код, а про свое отношение к нему.

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

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

P.S. Вот что сразу вымораживает так это использование СиШарпного стиля в X++. Прежде всего наименование переменных. Вот это я считаю проблемой и в С# и в X++ когда каждый программист со своим стилем.

[belugin]

Цитата:

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

P.S. Вот что сразу вымораживает так это использование СиШарпного стиля в X++. Прежде всего наименование переменных.

Это что, например? InventoryTable вместо InventTable?

Цитата:

Вот это я считаю проблемой и в С# и в X++ когда каждый программист со своим стилем.

Меня раздражает в стандартах аксапты кое что. Например, названия фабричных методов: newName это не "создать имя" а "создать нечто по имени" и т.д.

[ax_mct]

InventTable it; и похожее. Короткие и очень короткие наименования переменных это стиль многих СиШарпных и прочих программистов. Когда кода много это выглядит кошмарно.
То есть основная проблема для текущего момента это столкновение стилей программирования, на мой взгляд.

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

[belugin]

Цитата:

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

InventTable it; и похожее. Короткие и очень короткие наименования переменных это стиль многих СиШарпных и прочих программистов.

Вот стандарт наименования для C#


√ DO choose easily readable identifier names.

For example, a property named HorizontalAlignment is more English-readable than AlignmentHorizontal.

√ DO favor readability over brevity.

The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).


Скорее наоборот в Ax принято CustVendPurchSalesInvoiceDP а в C# это было бы

CustomerOrVendorPuschaseOrSalesInvoiceDataProvider

[belugin]

Цитата:

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

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

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

Эти вещи характерны тем, что имеют отложенный эффект ( См. понятие "технический долг". )

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

"Красота" описывается в конкретных терминах (например SOLID) нарушение каждого из которых приводит к образованию технического долга.

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

Например простейшие рефакторинги из Resharper (типа переименование переменной, выделить метод), которые этот инструмент делает быстро и гарантированно безопасно, в X++ часто дороги и рискованны, поэтому от них часто отказываются.

Сам язык X++ не позволяет создавать неймспейсы и иметь внутренние классы и т.д. в результате много модификаций сводится к изменению существущего кода, а не к его расширению к тому же пропадает формальное разделение на модули и интерфейс модулей становится непонятным (нельзя сказать "пользуйтесь вот этими классами, а эти - детали реализации").

и т.д.

В результате система превращается в одну большую кучу, которая доступна лишь только инкрементальному пониманию большими усилиями - разработчик разбирается с одним небольшим кусочком, а потом делает исходя из этого модификацию увеличивая объем кучи.

[ax_mct]

Цитата:

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

В результате система превращается в одну большую кучу, которая доступна лишь только инкрементальному пониманию большими усилиями - разработчик разбирается с одним небольшим кусочком, а потом делает исходя из этого модификацию увеличивая объем кучи.

Такова суть AX - заплатки и обновления. Куча. Смена языка ничего не изменит. И строгие пространства имен и прочее ни на что не повлияют в этом плане. Это всего лишь гаечный ключ к монстру Как я понимаю смена языка и среды разработки только увеличивает время разработки. И все. Зато хорошо звучит то что можно найти больше программистов и слепить еще большего монстра

[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?) можно не пользоваться. Функционал не является средством разработки.

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

Цитата:

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

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

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