Оver-engineering - "зачем так сложно?"

[belugin]

Цитата:

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

Моя категоричность она для чистоты лечения

Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.

Цитата:

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое
решение.

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

[mazzy]

Цитата:

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

ax_mct, в отдельной ветке, пожалуйста.

[belugin]

Цитата:

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

Интересно. Но если я не ошибаюсь, в аксапте такое не прокатывает. По ссылке речь об отладке в VS в специальном режиме.

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

[fed]

Цитата:

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

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

Не знаю как в последних CU, но по крайней мере до CU9 включительно, она намертво ломала сводное планирование и ресурсное планирование производственных заказов. В общем - в production ее точно лучше не включать....

[ax_mct]

Цитата:

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

Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

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

Инструментарий для кодирования лучше/хуже, способ программирования лучше/хуже - это диагноз.
Аксапта это продукт для кого?
Я не ностальгирую по Аксапте, я сожалею о безумстве которое в головах.

[Ace of Database]

Правильно ли я понимаю, что чтобы решить эту задачу, надо просто скопировать имеющуюся форму в новую, и в новой форме начинать колбасить?
добавить readonly датасорс на форму, для фильтрования
Если я понимаю правильно, то это тоже подход. Тогда АХ7 еще можно переварить. Главное, наработать последовательность рутинных операций, с помощью которых можно быстро удовлетворять клиента.
Тогда АХ7 уже не такая непонятная становится. Просто внешние обработки в ней хранятся не в файлах, как в 1С, а в AOT, вперемешку со стандартными объектами.

[Logger]

Баааалин.
Докатились.
Теперь злостный копипаст у нас признается нормальным способом.

[trud]

Цитата:

Сообщение от Ace of Database

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

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

[belugin]

Цитата:

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

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

Вы же сами рассуждаете о том, что способ программирования худше или лучше

[Ace of Database]

Цитата:

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

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

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

[trud]

Сделать как раньше, кастомизацией - закроют то только через год, да и то это только в планах
опционально написать о проблеме в микрософт

[Ace of Database]

Спасибо, trud!
Я просто пытаюсь разобраться. Обычно у любого продукта есть нить, ухватившись за которую можно начать работать. В любом продукте есть какой-то свой шаблон действий, главное его понять. Еще ни разу не встречал "Сферического коня".

[ax_mct]

Цитата:

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

Ритейл в акс7 построен на хранимых процедурах.
Не приведи господь.

Это понятно что хранимые процедуры сложно/непривычно поддерживать.
Но парадокс то и в том что шли, шли и пришли к тому же решению которого могло быть достаточно и в 3.0.

Цитата:

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

Вы же сами рассуждаете о том, что способ программирования худше или лучше

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

Цитата:

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

Баааалин.
Докатились.
Теперь злостный копипаст у нас признается нормальным способом.

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

Цитата:

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

не надо, пожалуйста.
открывайте балаган в курилке в новой ветке.

Да какой там балаган. Это о вполне реальной нашей болезни. Жертвой который и пала Аксапта.

[belugin]

Цитата:

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

Это понятно что хранимые процедуры сложно/непривычно поддерживать.
Но парадокс то и в том что шли, шли и пришли к тому же решению которого могло быть достаточно и в 3.0.

Что? Журналы ГК до сих пор разносятся через LedgerVoucher.

Цитата:

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

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

[belugin]

Цитата:

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

Не знаю как в последних CU, но по крайней мере до CU9 включительно, она намертво ломала сводное планирование и ресурсное планирование производственных заказов. В общем - в production ее точно лучше не включать....

Вообще, интересно, это свойство конерктной реализации или хотсваппинга в дотнете в вообще, как это делают в других продуктах на дотнете и нет ли проблем со стабильностью у хотсваппинга на оришинальной X++ машине.

(Как не смутно помнится, надо было очень аккуратно перекомпилировать наследников, если как-то не до конца это сделаешь, то будут странные ошибки или тихо данные возьмутся из другого поля)

[ax_mct]

Цитата:

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

Что? Журналы ГК до сих пор разносятся через LedgerVoucher.

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

Как должна решаться недостаточно быстрая разноска? Через хранимые процедуры.
Правильно через неплохое ОOП, LedgerVoucher* ? Да, правильно. Потому и медленно.

Цитата:

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

...люди читают поперек и уходят с мыслью "АХ неоч, ничо низя сделать, го в PHP" и несут ее гордо по всему форуму.

Выдернул из контекста с соседней темы чтобы ответить здесь по теме. Сделать можно что-угодно так или иначе. Вопрос то в том "зачем так сложно?". Это не уникальные грабли развития AX, все те же проблемы во всем программистском мире включая PHP.

Цитата:

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

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

В том то и беда что у типичного программиста шизофрения. Вторая личность - "правильность", c которой он постоянно дискутирует. Здравый смысл при этом молчит. А вот откуда этот программизм берется и в нас живет - вопрос интересный.

Проблема в том что большинство в упор не видит программизма и что есть оverengineering.
LedgerVoucher* - вполне может быть тем самым оverengineering.
А нежелание писать с использованием хранимых процедур - программизмом.

[belugin]

Цитата:

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

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

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

К решению чего?

[Pustik]

Цитата:

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

Баааалин.
Докатились.
Теперь злостный копипаст у нас признается нормальным способом.

Люди, никогда не признаю правильной стратегию копипастить. Честно , зло берет.

[ax_mct]

Цитата:

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

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

К решению чего?

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

Парадокс в том что
идя по пути совершенствования средств программирования и инструментария в AX
(по крайней мере течение вещей именно так представляется собирательному образу большинства программистов AX),
программисту AX легче не стало.

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

А если таки про сборщик мусора в 3.0 и устарелость виртуальной машины X++ - то при наличии таких проблем надо решать именно и только их. Все лишнее - программизм

[ax_mct]

Цитата:

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

Люди, никогда не признаю правильной стратегию копипастить. Честно , зло берет.

Если это не от безвыходности как workaround, когда ты вынужден,
а для реального облегчения жизни как hint, когда это твой выстраданный выбор,
то достаточно часто имеет смысл.

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

Но вот если от самого такого решения физически плохо и мутит, несмотря на его здравость - это программизм