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

[trud]

Цитата:

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

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

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

[Ace of Database]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

[ax_mct]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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

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

[skuull]

Цитата:

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

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

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

Можете сформулировать критерий сложности? Потому что из ваших постов я понял его так: "Все что я не понимаю за 2 минуты - overengeneering". Людям пожилого возраста тяжело пользоваться мобильным телефоном, но это же не значит что мобильный телефон - overengeneering ?

[ax_mct]

Цитата:

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

...
Можете сформулировать критерий сложности? Потому что из ваших постов я понял его так: "Все что я не понимаю за 2 минуты - overengeneering". Людям пожилого возраста тяжело пользоваться мобильным телефоном, но это же не значит что мобильный телефон - overengeneering ?

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

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

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

Критерии сложности такие же как и в механической инженерии.
Принцип KISS. Простота как условие популярности и выживания.

Привлекательность для реального мира ещё конечно.
Но в нем всегда привлекательно то что просто и элегантно.