Прощай, X++

[belugin]

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

Принципы придуманы для денег. Например, чтобы легче было менять и переходить на следующие версии.

Вот я к примеру бизнесмен. DAX внедрили, все работает как я и просил, проблем нет. Убедите меня перейти на новую версию и оплачивать поддержку всю дорогу.

Цитата:

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

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

Значит будем привязывать к гриду таблицу. У нас задача построить расово чистую систему из одних классов или решить проблему размазывания логики по разным местам?

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

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

Затем смотрим какие методы мы можем перекрывать у таблицы. Их там штук 25, но нам хватит важнейших: insert, update, delete, renamePrimaryKey, initValue, validateField, modifiedField, validateWrite

Перекрываем их. Внутри создаем экземпляр прокси-класса и к примеру для update() до и после super прописываем экземпляр.beforeUpdate(this) и afterUpdate(this). Обрамляем все это дело транзакцией.

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

До кучи можно еще озадачиться написанием методов set и get (ну или parm), которые будут транслировать переменные прокси-класса в поля таблицы.
А потом использовать только их для чтения или записи.

Правда в таблице останутся определения индексов, связей и deleteactions.
Но по крайней мере код наследовать уже можно.

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

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

С кодом на формах поступаем похожим образом.

[belugin]

Цитата:

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

Вот я к примеру бизнесмен. DAX внедрили, все работает как я и просил, проблем нет. Убедите меня перейти на новую версию и оплачивать поддержку всю дорогу.

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

[belugin]

Цитата:

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

Значит будем привязывать к гриду таблицу. Делаем эти прокси-классы для шапки и для строк, делаем класс Журнал ГК, который будет использовать экземпляры этих прокси-классов.

- абзац посвящен описанию структурного дублирования таблицы и поведенческого morphX
- при каждом добавлении поля прижется дублировать эти parmМетоды
- в языке нет никакой конструкции для "стараться не лазить" (нельзя сделать private таблицу) то есть с неизбежностью будут лазить
- форма уже лазит (то есть модификация типа "вынесли поле описание в отдельный справочник" требует изменения всех форм и отчетов)
- для каждой новой таблицы всю эту историю повторять и поддерживать

Я сомневаюсь, что на практике вы так делаете

[Napalm]

Цитата:

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

Я сомневаюсь, что на практике вы так делаете

А в AX 2012 Майкрософт попытался сделать. Получилось на мой взгляд плохо.

Цитата:

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

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

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

Да, в новой версии новые фичи. Но их необходимость для бизнеса нужно еще обосновать (как-то жили же люди раньше). Эта необходимость должна превышать риск получения детских болезней новой версии, включая внезапную неработоспособность проверенных и активно используемых фич.
Ну вот нет у меня программистов, использую стандарт, все хорошо, опа новая версия, ура ура. И вдруг тут больше не работает коррекция входящего НДС, тут себестоимость при пересчете стала считаться как-то странно и т.д. и т.п.
И что мне делать? Ждите хот фикс. Спасибо.

Свои программисты появляются не от хорошей жизни.

Изменения в законодательстве? Это вот так к примеру?
Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ )

Исправления ошибок?
Хотфиксы обычно исправляют несколько известных ошибок и вносят несколько неизвестных

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

Но все равно, самые быстрые и дешевые изменения - это отсутствие изменений.

Цитата:

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

Я сомневаюсь, что на практике вы так делаете

Не делаем. Проще использовать систему способом, предусмотренным ее создателями.

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

[belugin]

Цитата:

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

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

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

BTW:
- "Как правильно разрабатывать API с поддержкой обратной совместимости. Семинар в Яндексе": http://habrahabr.ru/company/yandex/blog/237459/
- http://semver.org/

[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)

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

+1024. Набор компромиссов. И облегчить жизнь хочется и даже возможно. Но не счет того чтобы вместо 3 строчек написать одну, а за счет использования OOП и технологичного дизайна классов.

Но тема в части "куда идет программирование в AX" не раскрыта.
Элементарный вопрос - Прощай "старое" программирование и Здравствуй что?
Если сейчас это X++/MorthX и желательно .NET/VS а также SSRS/ Enterprise Portal(ASP.NET) то что нас ждет в следующей версии?

Будет ли генератор кода HTML5 и JavaScripts? А если будет то насколько полноценный?

Что будет основным и рекомендуемым языком для AX2015 - X++ в VS или C#?

[perestoronin]

Цитата:

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

Свои программисты появляются не от хорошей жизни.

Изменения в законодательстве? Это вот так к примеру?

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

Но все равно, самые быстрые и дешевые изменения - это отсутствие изменений.

Как же не любят владельцы бИЗнеса программистов. Владельцы своего дела более благосклонны к своим работникам.

Производители как раз и косячат, причем в ядре системы, а программисты клиента потом с "радостью" находят самостоятельно решения как обойти болезни системы.

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

Цитата:

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

И облегчить жизнь хочется и даже возможно. Но не счет того чтобы вместо 3 строчек написать одну, а за счет использования OOП и технологичного дизайна классов.

Что будет основным и рекомендуемым языком для AX2015 - X++ в VS или C#?

А может появится система иная, на иных принципах?
X++ без его подтягивания к современным реалиям будет якорем тормозящим прогресс. C# это всего лишь Visual Basic в новой упаковке (грубо но вместе с тем достаточно справедливо, иначе бы не потребовалось прикручивать к нему надстройки типа LINQ).

Код в современной системе разработки приложений не просто должен быть из меньшего количества строк, но и эти оставшиеся строки должны быть заметно короче прежних строк каждой в отдельности, математически понятны при беглом просмотре и даже более - должна появиться возможность автоматической верификации самих алгоритмов описываемых кодом. Таковы требования к совершенному языку программирования. Пока только лишь языки ФП с известными допущениями удовлетворяют этому условию. А для информационных систем лишь один язык мне известен - Scala, но проблема в том, что и у этого языка есть болезнь с детства - он вырос как и X++ на Java, и мало того требует наличия и работает на инфраструктуре JRE (видимо для сохранения совместимости с имеющимися системами написанными на Java).

[ax_mct]

Прогресс... Совершённый язык...

Я в упор не вижу недостатков X++.
Так же как и не вижу недостатков в Visual Basic, Java, C, C++, C# на которых я работал коммерчески.

Вот Assembler меня доставал, копать землю иголкой мне не понравилось.

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

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