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

[skuull]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

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

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

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

[macklakov]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

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

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

[dech]

Цитата:

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

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

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

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

[belugin]

Цитата:

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

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

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

[fed]

Конечно же, 40-50 клиентов - это эспертная оценка. Вполне возможно что я малость неправ, и на самом деле - правильная цифра 25-30 (или наоборот - 50-60). Вопрос в том, что в любом случае - для одного клиента писать юнит-тесты невыгодно. Наверное уже раза 2-3 обсудили на этом форуме, что главная проблема разработки юнит-тестов в аксапте в том, что покрывать придется не только свой код, но и те места в микрософтовском коде, которые могут быть сломаны доработкой.
Если когда-нибудь микрософт опубликует свои собственные юнит-тесты,автоматизированное тестирование партнерских доработок станет выгодным и для меньшего числа клиентов (типа для 5-7). Но я очень сомневаюсь,что в случае разработки для одного клиента, автоматизированное тестирование когда-нибудь станет экономически оправданым. Всегда стоит помнить что стоимость предотвращения ошибки должна быть ниже чем стоимость исправления ее последствий. При этом в случае одного клиента, в 95% (или даже в 99%) случаев проще просто установить доработку в реальное боевое приложение и просто посмотреть что там реальные пользователи выкопают. Ну то есть - конечно консультанты и ключевые пользователи должны какие-то типовые сценарии потестить, но все равно - сложные случаи выловятся только во время боевой эксплуатации.

К слову сказать - первые 5 лет моей аксаптерской карьеры, я работал с версиями 2.1-3.0, которые тестировались в ручную. Там были баги в ядре. Там было много ошибок в российской локализации.В западной бизнес-логике, я за 5 лет столкнулся не более чем с тремя ошибками. В DAX2012, которая реально внедрялась 4 года, я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS.

[skuull]

Цитата:

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

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

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

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

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

[macklakov]

Цитата:

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

я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS.

А кто сказал что юнит тесты имеют хоть какое-то представление о бизнес-функциональности?
Account structures работают? Работают! Default dimensions работают? Работают! Пользователь создал заказ, одобрил, скомплектовал, отгрузил, выписывает инвойс. Ошибка валидации. К кому притензии?
Как в той миниатюре Райкина. К рукаву претензии есть? Нет притензий, рукав отлично пошит. Пришит рукав качественно? Да, не оторвешь даже если захочешь. Так что вам не нравится?

[fed]

Цитата:

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

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

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

Насколько я помню, это глубоко частный, спефицический случай, связанных с поведением внешнего оптимизатора (который в виде .net assembly поставляется, без исходных текстов). Но поскольку почти на всех внедрениях есть хоть какое-то призводство, приходится галочку везде отключать.
P.S. Официальное описание проблемы.

[mazzy]

Цитата:

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

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

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

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

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

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

[skuull]

Цитата:

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

Конечно же, 40-50 клиентов - это эспертная оценка.

А кто этот эксперт ? Хотелось бы узнать как проводилась оценка.
В этой теме это оффтоп, но может кому-то будет интересно почему в ISV некоторые пишут тесты, а некоторые нет.

[mazzy]

Цитата:

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

В этой теме это оффтоп, но может кому-то будет интересно почему в ISV некоторые пишут тесты, а некоторые нет.

Оффтоп.

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

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

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

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

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

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

==============
решить задачу "сделать так, чтобы люди писали тесты" очень просто. для этого не нужно изобретать Систему Воспитания.
для этого нужно предоставить доступ к тестам, которые есть.

Например, так как это делается для любого нормального проекта на gitHub.

[fed]

Цитата:

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

А кто этот эксперт ? Хотелось бы узнать как проводилась оценка.
В этой теме это оффтоп, но может кому-то будет интересно почему в ISV некоторые пишут тесты, а некоторые нет.

Гм - экспертная оценка, это оценка эксперта. Если оценка получена с помощью какой-то методики, то методика описывается. Если оценка получена просто на основании личного опыта эксперта - то это называется "expert judgment". Я привел свою собственную оценку.Ты тоже можешь свою экспертную оценку привести. Или можешь свою методику расчета окупаемости автоматического тестирования предложить.
А ответ на твой вопрос - достаточно прост: Если ISV разрабатывает add-on типа печати баркодов, хранения электронного архива или чего-то подобного, то точек пересечения с базовым функционалом не так уж много. В этом случае, есть шансы разработать автоматические тесты с более или менее разумными затратами на это (и есть шансы что разработка тестов окупится при меньшем количестве клиентов - типа 15-20-25). Если же ISV разрабатывает отраслевое вертикальное решение, то во первых, точек интеграции будет слишком много чтобы можно было бы покрыть тестами весь стандартный функционал, который может сломаться; Во вторых - в большинстве случаев, такие вертикальные решения собираются пост-фактум, просто добавлением в базовую ветку проектного функционала, разработанного под конкретного клиента. И как мы уже обсудили, при разработке под конкретного клиента, писать автоматизированные тесты просто не выгодно.
И к слову сказать - я вообще считаю что в Аксапте рынка вертикальных решений нет. В 99% случаев, смысл вертикального решения состоит в том чтобы продать консалтинг от их авторов. Я пока только одно отчуждаемое вертикальное решение видел, которое реально можно внедрить не эскалируя 85% проблем его авторам. Остальные вертикальные решения либо вообще в принципе не продаются другим партнерам, либо продаются, но при этом другой партнер реально только базовую настройку делает и пользователей учит (а реальное проектирование решения все равно остается разработчикам вертикального решения)..

[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Сники валить на другую систему. Типа "у нас гавно, а вот там еще хуже".
фиг с ними, с сапами, давай в своей системе разбираться/прибираться.

[ax_mct]

d

Цитата:

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

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

Цитата:

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

*Adapter - чем плох? Название говорящее.
...

Цитата:

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

В западной бизнес-логике, я за 5 лет столкнулся не более чем с тремя ошибками. В DAX2012, которая реально внедрялась 4 года, я столкнулся эдак с 20-25 багами в бизнес-функциональности. И этом при том что она-то как раз активно автоматически тестировалась в MS.

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

Все технические изменения сделанные программистами и для программистов - программизм который чаще всего оverengineering.

Как грамотно замечено Fed, критерий - отрицательный экономический эффект.
У меня у одного чувство что меня обворовали?

[DAX.Company]

Цитата:

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

У меня у одного чувство что меня обворовали?

Помню продавать начали 2012. Первый вопрос у заказчика - а в чем плюс для нас. Ну там краснея объясняешь мол Product Management стал вот такой... оптимальный. Ну AIF там... 7ая версия вовсе как я понимаю не продавалась. Но МС мало видимо. Такое впечатление, что в компании реально программисты рулят. А не экономисты

[belugin]

SysOperation уже обсуждали здесь Microsoft Dynamics AX 2012 White Paper: Introduction to the SysOperation Framework