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

[skuull]

Цитата:

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

Программисту? Старым, после многих лет работы с этими классами - сплошная радость. Новым, быть они хоть трижды Java программистами - легче и проще это не делает. А типичные на клиенте - вообще не в состоянии понять.

Спорное утверждение, глядя лишь на название классов(*Create, *Post, *Print) уже понятно что они делают и где нужно дописать свой код.
Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось

[mazzy]

Цитата:

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

глядя лишь на название классов(*Create, *Post, *Print) уже понятно что они делают и где нужно дописать свой код.

в теории конечно да.
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители.

тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных... а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...

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

[belugin]

Цитата:

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

в теории конечно да.
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители.

*Adapter - чем плох? Название говорящее.
*Handler - это действительно непонятно.
*Helper, *Util - лучше класть в тот класс, в котором, собственно, предмет обработки, но если класс чужой а твои методы для него очень специфичны либо это не класс, а интерфейс, то чем плохо положить в *Util? Только надо выбрать один из этьи суффиксов, что в MS не сделано, к сожалению.

Цитата:

тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных...

Печать тоже не печатает, а иногда выводит для предварительного просмотра. Возможно стоило назвать Output, например.

Цитата:

а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...

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

В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation теперь есть API - то есть если надо его встроить в свой процесс, можно взять и вызвать метод, заполнив контракт, а не вытягивать наружу параметры модифицируя существующий класс

[mazzy]

Цитата:

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

В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation...

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

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

с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности.

и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.

[belugin]

Цитата:

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

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

Она не гарантируется. Реально никто не заморачивается тем, чтобы сделать API на все.

Цитата:

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

Надо знать оба, да. Что такое "знать как их заставить работать совместно"?

В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе:

- Как использовать бизнеслогику одного из другого надо разбираться с каждым классом (у SysOP есть API который называется стандартно и представляет просто метод с параметром)

- UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог)

- Только pack можно использовать из другого pack (с runbase надо разбираться - они паковку не вынесли отдельно)

Цитата:

с появлением SysOperation и без рефакторинга старого кода сложность не уменьшилась.
а возможные преимущества от SysOperatin не перекрывают недостатков от появившейся сложности.

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

Цитата:

и так во многих местах аксапты за редким исключением типа (subledger, dimension).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.

Мне кажется для живой системы это нормально - не все переводится единомоментно - это постепенный процесс, python 2.5 -> 2.6 -> 3.0 я уже упоминал, в SAP говорят про три механизма для всего: то, что было давно и оставлено для совместимости, то, что используют все сейчас, то, что новое клёвое, но пока мало кто использует.

[mazzy]

Цитата:

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

Реально никто не заморачивается тем, чтобы сделать API на все.

1. не надо демагогии и слова ВСЕ ))) речь идет о SysOperation, которая должна заменить RunBase.
2. "Реально никто [в МС] не заморачивается" - это и есть причина Оver-engineering с точки зрения остальных разработчиков.

Тут, наверное, мне стоит объяснить остальным участникам,
что фраза Макса "не заморачивается [API]" вовсе не говорит о том, что разработчики в МС не заморачиваются ничем.
В МС самая замороченная процедура приемки кода изо всех что я видел. Поэтому заморачиваться разработчику в МС приходится очень много чем.

Просто критерии важности в МС сильно отличаются от критериев важности на проектах заказчиков и партнеров. Следовательно заморачиваются в МС очень другими вещами, чем на проектах (собственно об этом я и говорил выше).

Цитата:

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

Надо знать оба, да. Что такое "знать как их заставить работать совместно"?

В случае RunBase нет почти никакого общего способа заставить работать два RunBase вместе:

запустить через MenuFunction или любым другим способом.
пример - хелперы в процедуре закрытия склада.

Цитата:

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

- Как использовать бизнеслогику одного из другого надо разбираться с каждым классом

вообще говоря, нет. см. MenuFunction.

Цитата:

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

- UI совместно не используешь (несколько контрактов SysOP можно скомбинировать в один диалог)

э-э-э...
можно я не буду дальше комментировать?

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

Цитата:

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

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

я предполагаю о чем ты.
но для определенности, можешь привести пример?

Цитата:

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

в SAP говорят про три механизма

Ой, все! вот только не надо как 1Сники валить на другую систему. Типа "у нас гавно, а вот там еще хуже".
фиг с ними, с сапами, давай в своей системе разбираться/прибираться.

[fed]

Цитата:

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

Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось

А ты попробуй продать реальному клиенту идею авоматизированного тестирования, покрытия кода тестами и тд и тп. Когда он узнает сколько это будет стоить,сразу
наступит ясность почему именно "не сложилось".
Вообще - автоматизированное тестирование окупает себя только на тиражируемом софте. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.
Только вот я пока не видел вертикальных решений аксаптовских с таким количеством клиентов (гм - может быть у add-ons типа Bartender или Formpipe Lasertnet есть такое количество клиентов). По крайней мере на обычных внедренческих проектах, с разработкой под конкретного клиента, разработка тест-скриптов не окупается.

[Vadik]

Цитата:

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

.. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно

Это палка о двух концах. Да, найти незастолбленную нишу на 50+ клиентов - непросто. Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Цитата:

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

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

[ax_mct]

Цитата:

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

Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования
количество багов и последующих hotfixes стало меньше? Так сказать экономический эффект интересен.

Мне почему-то не кажется что в AX2012 или Operations стало меньше hotfixes по сравнению с к примеру 3.0. По моему как пользователи работали beta-тестерами так и работают.

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

[Vadik]

Цитата:

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

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования количество багов и последующих hotfixes стало меньше?

Для 1611 на сегодня - чуть менее 600 X++ хотфиксов. Много это или мало ? Я не знаю, немало это точно, пускай половина и для проектов \ expense management \ GER которые мы пока не сильно (вернее практически никак) не используем. А сколько у Вас хотфиксов доступных, но не установленных - знаете ? У нас - вот столько (снимок с продуктива, там взяли небольшую паузу пока готовились на 1611 перескакивать, вот и поднакопилось). А сколько будет стоить их поставить, возьметесь посчитать? Предвосхищая реплики "да кому они нужны эти ваши хотфиксы" - нужны. У меня в этом году уже двум клиентам в Европе в связи с налоговыми заморочками вынь да выложь надо ставить хотфиксы для 2012 и 2009 которые за собой по древней традиции пол-аксапты тянут. При текущем уровне закастомизированности там одного code merge недели на две, я уж молчу про тестирование. И да - разработку придется остановить или вести параллельно в другом приложении и потом снова мерджить

Цитата:

Так сказать экономический эффект интересен

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы

[macklakov]

Цитата:

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

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили

Ок. Может усложнение исходников и оправданно. Если учесть что MS реально со всей дури впрягся за "вылизывание" стандарта, то вроде как традиционная "доработка напильником" на местах уходит в прошлое. Остаются только разработчики "вертикальных" решений. А им может и стоит задумываться над тем, как изолировать свое решение от стандарта.
Но, есть другой немаловажный момент. Данные! Вот уж что порублено на фарш, та это данные. В результате "программизма", размер таблиц стал чудовищным. При этом несмотря на невероятные усилия по оптимизации, включая переписывание кусков на хранимках, все равно есть места где откровенно подтормаживает. Но главное даже не в этом. Главное что данные нечитаемые. А это приводит к жутким проблемам с BI. Жутким проблемам с миграцией. Жутким проблемам с нарушением целостности.
В результате применения таких "правильных и прогрессивных" паттернов и нормализации, AX превратилась в систему, у которой очень большие проблемы с построением отчетности.

[skuull]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

Для 1611 на сегодня - чуть менее 600 X++ хотфиксов.
...
В D365O если разработка по уму организована - это в большинстве случаев..
...
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы

Цитата:

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

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

То есть есть мнение что - в некоторых случаях "усложнения" оправданны
так как это может приводить к

- можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O)
- легче покрыть автоматическими тестами

Корректно выдернул из контекста?

[skuull]

Цитата:

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

То есть есть мнение что - в некоторых случаях "усложнения" оправданны
так как это может приводить к

- можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O)
- легче покрыть автоматическими тестами

Корректно выдернул из контекста?

Не все так однозначно.
Я сейчас наверно повторю сказанное ранее, но разбиение 1 класса на 3 есть усложнение для тех кто не понимает MVC и облегчение для тех кто понимает. Плюсы тут уже перечислили.
Как по мне, FormLetter стал легче для понимания и использования, а вот Subledger нет.

[belugin]

Цитата:

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

Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.

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

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

Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test.

А еще тесты надо уметь готовить, а то получается дополнительная боль

[dech]

Цитата:

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

Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test.

А еще тесты надо уметь готовить, а то получается дополнительная боль

Юнит-тесты доступны начиная аж с 4 версии аксапты. Давно пора было их использовать.
Если вы не про Селениум, конечно.

[belugin]

Цитата:

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

Юнит-тесты доступны начиная аж с 4 версии аксапты. Давно пора было их использовать.
Если вы не про Селениум, конечно.

Доступен фреймфорк а не сами готовые микрософтовские тесты.