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

[macklakov]

Цитата:

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

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

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

[Ace of Database]

Цитата:

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

Все конечно довольны, но радость недолго длится. Некоторые ошибки вылезают только лет через 5-7.

Люди радовались целых 5-7 лет

[belugin]

Цитата:

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

Оverengineering возможно потому что салон автомобиля перепутали с двигателем.

Код-это не салон и не двигатель, это чертежи и документы по которым компилятор и установщик строит салон и двигатель.

Соответственно примерно по таким же законам надо работать.

Какой документ лучше, вот такой?

Цитата:

• У лисы длинный хвост.
• У бобра длинный хвост.
• Кенгуру имеет длинный хвост.
• Такой же хвост и у собаки.

Или вот такой:

Цитата:

У этих животных хвосты длинные

• Лиса
• Бобер
• Кенгуру
• Cобака.

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

Если надо поддерживать всех животных (допустим добавить, что хвост покрыт шерстью), то изменение требует анализа всех вариантов.

Если нас волнует только кенгуру нам проще найти поиском ее и уточнить какой хвост у него.

Могут быть промежуточные варианты - например нас волнуют все, кроме кенгуру.

Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции
- у операций бывают параметры
- если не сказано обратного, то надо :
- загрузить параметры из SYsLastValue
- спросить параметры согласно типам
- сохранить их в SysLastValue
- выполнить операцию

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

Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder.

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

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

То есть надо каждый раз повторять:
метод main, диалог (создания и получения), сохранение и восстановление и работу с версиями (все же аккуратно поддерживают восстановление из старых версий в unpack, да?). Я вот конкретно иногда забывал добавить строчку в getFromDialog или копировал но не правил и от этого были ошибки.

P.S. Это тут было?
https://www.youtube.com/watch?v=GRr4xeMn1uU

[Bobkov]

Цитата:

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

Какой документ лучше, вот такой?
Или вот такой:
Однозначного ответа нет.

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

Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные".

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

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

IMHO, конечно

[trud]

Цитата:

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

Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции
- у операций бывают параметры
- если не сказано обратного, то надо :
- загрузить параметры из SYsLastValue
- спросить параметры согласно типам
- сохранить их в SysLastValue
- выполнить операцию

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

Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder.

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

[macklakov]

хотя, кого я обманываю? Если даже флагманский продукт, основа основ, Windows, которой уже 30 лет, к пользователю повернута самым неприглядным местом. Вот только что пытался пароль поменять. Она мне говорит что пароль несоответствует критериям. А что за критерии не говорит. Более того, критериям, он, как выясняется, соответствовал, это что-то в AD перклинило, когда мне пытались к Office365 доступ дать. Нет, админы криворукие, конечно, но это не операционка, а гребаный стыд. Unit tests, автоматизированное тестирование... А в Excel, банальном Excel, глючит буффер обмена!
При этом сайт какого нибудь стартапа, запиленный на коленке студентом, детально объясняет что он от меня хочет. Уже лет 10-15 как. А великая и могучая винда не соизволит опуститься до такой банальности. Эта контора это филиал ада на земле, ставящая своей целью причинить пользователям, клиентам, специалистам и даже своим сотрудникам, максимальные страдания. Ни с чем не сравнимый experience.
Если хватает смелости уйти в PHP, беги! Беги и не оглядывайся. Здесь ад.

[ax_mct]

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

Да, тот же settleNow() примерно такой длины, но я не уверен что от деления этой логики на множество методов, или не дай бой иерархии классов, станет легче. Скорее всего будет шило на мыло.

Проблема то именно в фанатичном использовании ООП вообще и не свойственного для Аксапты ООП в частности.
Вот это нетерпимость к "неправильному" коду и есть одна из причин over-engineering.
Если код делает то что от него требуется, включая возможность его поддержки и расширения, то он не может быть неправильным. При условии конечно соблюдения Best Practices для АХ, но никак не "общепринятого программирования".

Уважай культуру места где находишься вот и все. Если 2000 строк в данной культуре - ОК, и более того работает и работает, то не трогай. Не считай себя более одаренным чем те программисты которые подняли этот продукт.
Уважай то что работает какое бы грязное оно не было. Рабочее оно как раз всегда грязное.

[macklakov]

Цитата:

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

тот же settleNow() примерно такой длины

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

[Ace of Database]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

[macklakov]

Цитата:

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

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

Самому не стыдно? Твой код приходится менять. Почему сразу не продумал все варианты? Ведь у тебя же есть иерархия. Мог бы объявить объект класса-родителя, инициировать конкретного наследника через factory, исходя из параметров. Ну и потом почему поленился, нормально, через SysOperation, делать? Ведь это гораздо более универсальный механизм чем jobs.

Цитата:

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

Я не против дублирования в принципе, просто оно должно быть обосновано.

А я не против "серьезных" программстских подходов. Паттерны, абстракции, обощения и т.д. Просто оно должно быть обосновано

[belugin]

Цитата:

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

Почему сразу не продумал все варианты?

Тут другое интересно, почему вообще возникла задача сделать одно и то же в двух модулях, между которыми нет НИЧЕГО общего. То есть у кастомера и вендора общего не больше чем у кастомера и пирожка с капустой

[ax_mct]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

CustVend иерархия это хороший пример теория vs практика.
Обоюдоострый топор - прекрасная идея, но нам им лес валить.

Действительно если бы вместо settleNow() было два метода было бы легче.
И то что было бы повторение кода в этих двух методах - и слава яйцам в разных корзинах.

А главное мое "салон vs двигатель" слишком лиричное, а твое Это учетная система, она должна отражать реальность - понятнее.

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

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

[trud]

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

[belugin]

Цитата:

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

ну вот допустим есть у вас Tutorial_RunbaseBatch

Хорошо, какие же именно усилия требуются для того. чтобы сделать то же самое для SysOperation?

[trud]

Цитата:

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

Хорошо, какие же именно усилия требуются для того. чтобы сделать то же самое для SysOperation?

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

[dech]

Между таблицами клиента и поставщика много общего, соответственно очень много одинаковой логики и она дублируется. Чтобы избежать дублирования, изобрели Maps. Всю общую логику переместили в CustVend*. Очень элегантное решение, кстати.

[macklakov]

Цитата:

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

Между таблицами клиента и поставщика много общего, соответственно очень много одинаковой логики и она дублируется. Чтобы избежать дублирования, изобрели Maps. Всю общую логику переместили в CustVend*. Очень элегантное решение, кстати.

Элегантное, спору нет. Правда как не настраивай потом долго пользователей дрессироваться приходится что:"вот здесь пока прижимаешь, там тянешь, а вот ты в это время смотри чтобы оттуда не лезло". Но инженерно красиво. Гордость за систему. У других пара функций и все. А у нас наследование!

[mazzy]

Мдя... это уже перебор.

[ax_mct]

Цитата:

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

Мдя... это уже перебор.

Ну а как иначе сказать? Это не ругательство а наглядный пример так как с телом человека все знакомы. Рот - получаем еду, "зеркальный рот" - выводим. То же что и с Accounts "In" и "Out".
Масса общего если задуматься.

Ну и от лица той инопланетной жабы могу сказать что обьединение не с потолка взято, а из природы.
Вторичноротые.
https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%83%D1%81
У кишечнополостных и у плоских червей анальное отверстие отсутствует, у вторичноротых животных анальное отверстие развивается на месте первичного зародышевого рта.

По моему прекрасный пример абсурда моделирования когда мы не хотим дублировать код. Функция "Сжать" должна быть членом класса Отверстие. И так далее.

[mazzy]

Цитата:

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

По моему прекрасный пример

нет. как раз наоборот.
поинтересуйтесь, поизучайте.

например, https://www.youtube.com/watch?v=X6-DKuwHyjY
а также Висцеральная теория сна https://www.youtube.com/watch?v=2c7G_ml791w
и другие примеры оверинжиниринга в эволюции

только, пожалуйста, общие обсуждение оверинжиниринга - в специальную ветку
Оver-engineering - "зачем так сложно?" - Мортира Карл

ax_mct, давайте я сделаю предупреждение еще раз.
будете гадить в этой ветке, буду банить.

здесь тема про Аксапту
Оver-engineering - "зачем так сложно?"