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

[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 сказали что их клиент захочет увидеть аналитики через черточку, вот и получили.