Прощай, X++

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

[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

[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

[ax_mct]

Цитата:

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

Нет стандартов в C#, есть рекомендации. И если наименование свойств как интерфейса важны то с локальными переменными все работают как бог на душу положит.
Программисты из других систем в X++ пишут не
InventTable inventTable;
а
InventTable tblInvent;
InventTable table;
InventTable _invent;
и так далее. То есть они просто не следуют уставу монастыря в которой пришли.
Или еще того хуже следуют примерам из MSDN
http://msdn.microsoft.com/en-us/library/jj677293.aspx
Loan lTbl;
Person pTbl;

delete_from lTbl;
delete_from pTbl;

У меня лично иногда это вызывает некоторое раздражение при том что с C# у меня уже лет 11 как все хорошо.
А подобный кодинг я вижу все чаще и чаще когда опытные программисты но из других систем начинают работать с AX.
Иногда даже почти родное m_* для членов класса встретишь.

И дело конечно же не в C#, а в самих программистах. Лично я на каждом языке (С, C++, VB, Java, C#, X++) всегда программировал так как принято в данном языке.

Но я вижу что подобных поводов для раздражения относительно кода будет все больше и больше из-за "доступности" AX для большего числа программистов.
Так как для меня определенно что все эти изменения не для удобства специалистов по AX а для маркетинговой привлекательности и декларируемого доступа более "дешевых" программистов с опытом не в MorthX а в Visual Studio.

Как понимаю спрос на "архитекторов" резко возрастет так как все будут думать что в Visual Studio и на C# могут программировать многие деревни в Индии и надо только найти создателя технических спецификаций и будет всем экономия денег (Смайлик я поставил, смайлик!)

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

Нет стандартов в C#, есть рекомендации.

Как, впрочем и в X++.

Цитата:

InventTable tblInvent;

Тяжелое наследие венгерской нотации. Пришло из C

Цитата:

InventTable table;

В коротких методах - более менее, если в нем нет ничего кроме "invent" но лучше inventTable.

Цитата:

InventTable _invent;

На это даже есть автоматическая проверка, насколько я помню.

Цитата:

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

Как вы думаете, почему эти имена прошли code review?
Если бы code review делался автоматически прямо по мере набора кода больше или меньше шансов было получить такие имена?

[ax_mct]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[ax_mct]

Цитата:

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

...
На это даже есть автоматическая проверка, насколько я помню.
...
Как вы думаете, почему эти имена прошли code review?
Если бы code review делался автоматически прямо по мере набора кода больше или меньше шансов было получить такие имена?

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

Code review эти имена не проходят. Его практически просто нигде нет. Некому и незачем. Лично я устал на каждом новом проекте об этом говорить. Бесполезно.

И да такая автоматическая проверка только и спасет. Но это надо чтобы хоть один такой перфекционист оказался в начале проекта. Дело ведь не только в опытности но и в менталитете.

[ax_mct]

Для AX 2015 я бы еще добавил коэффициента подорожания разработки
Если условно для AX2012 это 30%-40% то для AX 2015 я бы оценил как 60%-80% как минимум так как танцы с бубном только увеличатся.

Прощай старый X++, здравствуй XXX+

Цитата:

Сообщение от AP-1055D

А какая есть информация о формах? Интерфейс будет на HTML5 + js + CSS 3.0? То есть X++ подружат с HTML?

Неплохое обсуждение здесь
The Death of Reason: #wpc13 Dynamics AX Roadmap
The Death of Reason: #wpc13 Dynamics AX Roadmap

http://axhelper.blogspot.co.uk/2013_12_01_archive.html

Цитата:

The first elements of ‘Rainier’ are expected to be available in Q4 CY2014 with key investments
areas including:

 Next Generation User Experience - a context-sensitive Windows 8 experience based on
HTML5 client technology
 Cloud Delivered – with a focus on enabling a “what you need, when you need it” approach
via Windows Azure and/or Windows Server
 Best in class lifecycle management – regardless of deployment choice from on-premise,
hybrid to full cloud
With ‘Rainier’ we will continue to deliver the most intuitive and simple solution for your
customer interactions, your people and your business by innovating and building out the
functionality footprint across retail, distribution, manufacturing, services and public sector.

Features (в таком виде во многих блогах но источника я не нашел)

a. Cloud Based Solutions
b. Platform independence - Browser enabled clients
c. AD Federation and more integration with Azure
d. More investments on Visual Studio (Development Environment will be VS)
e. Application Development targetting any OS through Rainier
f. No longer need to invest on Sharepoint hosting as Enterprise portal will be eliminated
g. 3 key pillars - New client, Cloud Readiness, New Development Stack
h. No RPC based communication (Atleast, now it's assured that the event logs won't get full by RPC errors which was the case with AX 2009)
i. Programming language will still be X++ but everything will be .net compiled
j. Capability to expose updatable views using OData
k. HTML 5 based Web Client so more faster and richer experience

Statement of Direction Product strategy and roadmap for Microsoft Dynamics AX Date: July 2013
http://www.mwdata.dk/media/52698/mbs...07_24_2013.pdf

P.S. Mazzy уже приводил эти фичи здесь
daxdilip: Some info on Microsoft Dynamics AX 2014/2015 Next Major Release codenamed "Rainier" or "Rainer"
daxdilip: Some info on Microsoft Dynamics AX 2014/2015 Next Major Release codenamed "Rainier" or "Rainer"

Цитата:

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

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

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

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

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

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

[lvan]

подобный потс говорит многое о внедренцах во Владимире =)

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

Можно анализировать только новые ошибки.

Цитата:

И да такая автоматическая проверка только и спасет. Но это надо чтобы хоть один такой перфекционист оказался в начале проекта.

Если бы у вас был инструмент типа Resharper, могли бы переименовать не нравящиеся вам переменные прям по ходу дела.

[belugin]

Цитата:

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

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

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

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

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

[dech]

Цитата:

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

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

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

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

[RVS]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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