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

[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, критерий - отрицательный экономический эффект.
У меня у одного чувство что меня обворовали?

[DAX.Company]

Цитата:

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

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

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

[dech]

Цитата:

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

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

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

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

Поясните, мне пожалуйста смысл слов программизм и оверинжиниринг. Я не совсем улавливаю суть. С моей точки зрения это чересчур хитрые решения и излишняя сложность. Так или не так?

Напишу свое мнение по вопросу тестирования. Тесты нужны, чтобы как минимум понимать логику разработчиков. Даже названия классов и методов не особо отражают их деятельность. Ладно хоть туториалы есть, как работать с каким-либо фреймворком, да и то не каждым. Соответственно, программисту АХ2012 и выше стало уже не так легко работать. Хоть сам садись и пиши документацию по классам. Поэтому, очень жаль, что МС не поставляет дополнительно тестирующий код.
Всегда придерживался двух приоритетов: Краткость и Простота.
Это подразумевает проведение рефакторинга. А сам по себе рефакторинг подразумевает наличие хотя бы минимального набора юнит-тестов.
Бывает, что при работе с отчетами/формами юнит-тесты не помогают. В таких случаях конечно можно обойтись без тестов.
Сдавать работу конечно приходится без них, т.к. руководство не особо жалует "напрасную" трату времени. Однако, ты становишься уверен в своем коде.
Что касается разбиения кода, я только за. Хотя бы начинаешь въезжать, не запуская дебаггер. Вывод такой: если большую часть времени мы работаем с дебаггером, значит код написан довольно скверно. В большинстве случаев тесты замещают работу с дебаггером, увеличивают объем кода, но вместе с тем уменьшают затрачиваемое время на отладку, т.к. многое становится ясно на этапе утверждений.

[macklakov]

Цитата:

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

Поясните, мне пожалуйста смысл слов программизм

Объясню на примере. Security. С точки зрения программистов все очень изящно и гибко. Роли, привелегии, хочешь из AOT делай, хочешь через формы. Можешь делать под себя, а можешь взять "коробочные", которые еще и обновляться будут, по мере развития функционала. Круто?
А что имеем в реальности? В реальности консалтер на форме отрадактировал роль и привелегии, а это поменяло код в AOT. Это значит что изменения должны идти через deployment process. Когда у тебя в процесс вовлечено минимум 3 стороны, это организационно бывает не так просто и не быстро. И даже технически один AOS будет знать об изменениях, а другой нет.
Админы от такой красивой 3-х уровневой архитектуры впадают в ступор. Вот есть задача, закрыть одному отделу доступ к одной форме. Как это сделать? Начать с того, что privileges надо найти. Как это сделать? Через AOT или через Security Development Tool. Но тут такая незадача, SDT не помнимает что privileges была disabled. Т.е. на нее полагаться нельзя. Надо таки лезть в AOT и проходить по всем privileges, смотреть их свойства, смотреть свойства duties и даже roles. А потом все это аккуратно копировать, изменять только то что нужно и переназначать пользователей на новые роли.
А так, архитектруно, все красиво. Я думаю что команда дизайнившая Security гордилась своим творением. И, кстати, не помню чтобы эта часть хоть когда-то глючила. Т.е. технически безупречно, а функционально бессмыслено. Вот это и есть программизм.
P.S. В искусстве такое, кстати, тоже часто происходит, произведение требует невероятной виртуозности от исполнителя, а слушать невозможно.

[EVGL]

Цитата:

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

В реальности консалтер на форме отрадактировал роль и привелегии, а это поменяло код в AOT.

В AX7 можно и чисто настройками. Но в целом поддерживаю: сделано так запутано, что лезть просто туда страшно. Страшнее даже, чем делать миграцию данных по фиксированной цене : ) Одно спасает - стандартный контракт, где настройки прав доступа отданы на откуп клиенту.

[gl00mie]

Цитата:

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

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

В случае реализации и запуска отдельно взятого проекта внедрения - может и так, в случае долговременной поддержки и развития решения на отдельно взятом проекте - это имеет смысл, по-моему. При длительном развитии решения на отдельно взятом проекте можно запросто очередной модифой сломать то, что худо-бедно работало долгие годы. Наличие некой страховочной сетки в виде регрессионных тестов, покрывающих важный и/или сложный функционал, позволяет спокойнее и проще менять существующий код.
При первоначальном внедрении или построении ISV-решения трудно выделить такой наиболее важный и/или сложный функционал либо точки сопряжения со стандартом - их слишком много. При длительной же поддержке и развитии на отдельно взятом проекте они сами собой выкристаллизовываются в ходе решения наиболее проблемных или часто повторяющихся запросов в поддержку.

PS. Как отметил fed, возможно, на покрытие тестами может влиять и то, работаешь ли ты за оклад либо на почасовой ставке

[ax_mct]

Цитата:

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

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

Экосистема Аксапты основывалась на проектах внедрений где покрытие тестами - неуместно.
Если из-за необходимости покрытия тестами и соответствующих этому технических изменениях мы сливаем эту экосистему то не сильно много этих потенциальных отдельно взятых проектов.

Если же речь о разработке у вендора и что ему так удобнее и выгоднее, то количество багов и hotfixes, обновлений (не только в AX) заставляет сомневаться в эффективности и полезности автоматического тестирования как минимум в GUI приложениях.

[ALES]

Цитата:

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

на отдельно взятом проекте можно запросто очередной модифой сломать

И это все легко и просто оценивается "ценой простоя" каждой конкретной работающей системы. Ошибки будут всегда независимо от того, осознает ли ЛПР что +100500й раз весь процесс "вручную" прогонят столь же тщательно и внимательно, как "до запуска"

[macklakov]

Цитата:

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

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

Это мелочь. Хочешь узнать что такое быть обворованным через over engineering? Посмотри на вот этих ребят: https://www.globalsoftwareinc.com/ex...ft-dynamics-ax. Была отличная интеграция AX с Excel. Настолько хорошая, что в здешнем регионе стала практически стандартом. Но! В 2012-й структуру данных сильно улучшили и теперь накатить журнал через Atlas стало очень сложно. При этом есть Office Add-In "из коробки" который все еще сильно хуже, но это уже не имеет значения. Оба инструмента невозможно использовать.
Вот это образчик чистейшего программизма. Т.е. если бы хотели с помощью Office Add-In и своего монопольного права на систему уничтожить зависимых конкурентов, это понятно. Но в данном случае партнеру урон был нанесен непреднамеренно. Просто их в универе учили что база должна быть нормализована, вот они и нормализовали. Консультанты-перебежчики из GP сказали что их клиент захочет увидеть аналитики через черточку, вот и получили.