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

[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).
вводятся новые инструменты-фреймворки. пусть они все замечательные.
но старые то не выводятся.

[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.

[skuull]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

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

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

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

[belugin]

Цитата:

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

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

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

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

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

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

[dech]

Цитата:

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

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

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

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

[fed]

Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions.
Во первых - из за того что там очень высокий уровень абстракции, большая часть диагностики сводиться к сообщению "У нас тут какая-то фигня". После этого приходится тратить где-нить от часа до трех времени, чтобы протрассироваться и понять - где-же именно и какую настройку консультанты неправильно сделали. Просто благодаря могучим программистским механизмам, место возникновения ошибки отделено от его причины изрядным количеством вложеных вызовов,классов-фабрик, классов сохранения состояния, классов перехода состоянияи и тд и тп. Поэтому в момент обнаружения ошибки, выдать понятную диагностику просто невозможно. Проверку параметров в унаследованный от Дамгаарда код прогрессоры добавить не догадались.
Аналогично - процентов 85 эскалированных в Микрософт ошибок, приходилось на те самые замечательные распределения и сабледжер. При этом чтобы воспроизвести ошибки в стандарте и понять условия их возникновения, приходится тратить достаточно заметное время на трассированние исходного кода.
При этом, как я много раз уже писал, subledgers/distributions - это вообще абсурд, не связанный с экономической реальностью. Новая аналитика и ГК - конечно полезна в определенном числе случаев, но с другой стороны - в 98% случаев и старой ГК (как в 2009) хватало. (В том числе для вполне себе крупных внедрений enterprise уровня).

Наконец - хочу ввести критерий ovengineering: Это, как несложно было догадаться, отрицательный экономический эффект от изучения новой технологии. Вот я на эту борьбу с ГК и распределениями потратил, в общей сложности, порядка 4 недель жизни.
Во первых - далеко не все это время было billable. Клиенты как-то не очень рвутся оплачивать то, что с их точки зрения является ошибкой (не важно - нашей в настройках, или Микрософтовской - в коде).
Во вторых - эти знания мне вряд ли пригодятся для каких-то других задач, кроме собственно воспроизведения ошибок MS и поиска ошибок консов. (А это, как я уже заметил, не очень выгодные в финансовом плане и не очень интересные в профессиональном плане задачи). Я точно не буду создавать свой собственный вид source document и вряд ли я буду переписывать разноску в ГК.
Так что для меня изучение нового замечательного, богатого на новые программистские технологии модуля дало в целом негативный экономический эффект. Я потратил изрядное время на получение знаний сомнительной полезности и применимости.

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

[Vadik]

Цитата:

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

Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions

Ну а я тогда свою копеечку добавлю с бюджетированием. Там правда скорее не over-engineering, а просто уродский дизайн. Куча логики на вызывающих друг друга хранимых процедурах на T-SQL. Часть параметров с которыми эти SP вызываются (BudgetCheckGroup) - живут в рамках сессии и даже перехватив "падающий" вызов - оттрассировать его нельзя (это свежесозданные RecId которые при ошибке откатятся с транзакцией). Зашитый в код applock, из-за которого все проверки выполняются строго последовательно. Решил ты в одной компании проверить по бюджету журнал строк так на 10000 - все приложение встало колом. Ну не прелесть ли?

[Raven Melancholic]

Цитата:

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

Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions.

Я раньше, когда новички обращались с просьбой подсказать где лучше посмотреть реализацию разноски в ГК данных, введенных пользователями, отсылал к текстовой накладной (накладной с произвольным текстом). Типа там все просто и понятно.
Изучая DAX2012 решил последовать своему же совету. Сказать, что был удивлен это упростить мою реакцию - жена много новых слов узнала.

[Pustik]

Цитата:

Сообщение от Raven Melancholic

Я раньше, когда новички обращались с просьбой подсказать где лучше посмотреть реализацию разноски в ГК данных, введенных пользователями, отсылал к текстовой накладной (накладной с произвольным текстом). Типа там все просто и понятно.
Изучая DAX2012 решил последовать своему же совету. Сказать, что был удивлен это упростить мою реакцию - жена много новых слов узнала.

Да уж, сказать что просто немножко изменилось - ничего не сказать.

И у меня вопрос ЗАЧЕМ? Я пойму если объяснения будут адекватные. Типа стало быстрее, проще, ну или на худой конец все движется вперед - стоять на месте нельзя. Но только двигаться вперед можно и с учетом того , что было раньше сделано, а не по принципу "врач сказал резать, значит резать"

[fed]

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

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

[macklakov]

Цитата:

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

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

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

[skuull]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

Оффтоп.

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

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

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

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

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

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

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

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

[fed]

Цитата:

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

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

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

[ax_mct]

d

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

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