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

[dech]

Цитата:

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

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

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

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

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

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

[ax_mct]

Цитата:

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

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

Действительно уже многое сказали. Mazzy вообще матом ругался, он тогда еще в MS не работал, себя не сдерживал.

Я бы выделил именно экономическую составляющую:

Цитата:

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

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

Вот на этот вопрос

Цитата:

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

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

.

Я бы ответил так:
"отрицательный экономический эффект"

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

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

[ax_mct]

Цитата:

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

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

Цитата:

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

Я бы ответил так:
"отрицательный экономический эффект"

Программизм - это когда мы хотим сделать лучше для кода, а не для людей.

оверинжиниринг - это когда сложность не упрощает.

Как независимый критерий - экономическая эффективность.

[ALES]

Цитата:

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

Есть еще что сказать про Оver-engineering в Аксапте?

Замечательный "новый поиск" в литспейджах, который никак из них убрать никаким "программизмом" теперь невозможно
Чудесные "новые связи", которые никто в МС "не захотел" по кнопочке "выбор" в диалогах "оценить" с точки зрения пользователей (конечно они будут по внутренним номерам записей в таблицах, что-то себе отфильтровать)
Волшебная "нормализация" справочника номенклатур, которая совсем "чуть чуть" не упирается в собственные рекомендации по "превышен размер буфера"
"Структура импорта и экспорта данных" ... тут лучше промолчу
"Контроль доступа" ... тут три раза промолчу

[ax_mct]

Цитата:

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

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

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

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

[ALES]

Цитата:

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

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

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

[ALES]

Цитата:

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

====================
3.Сценарии работы.
Уж не знаю к счастью или к сожалению, но в МС сейчас одержимы идеей "пользовательских сценариев". грубо говоря, некто продумывает "как будут работать пользователи" и это становится священным писанием, которое нельзя изменить.
Причем ладно бы нельзя было бы сократить. Но и расширить тоже нельзя.

А вот с этого места поподробней..
Неужели уже при нынешнем поколении ожидания от системы у "продавцов", "заказчиков", "внедренцев" и "пользователей" совпадут? Произойдет ли качественный прорыв от "официального" распространения информации на уровне "чтобы включить фичу системы Х , вот в той форме включите опцию Y" (и "неофициального" понимания "для чего фича, как с ней работать", проектного опыта и желания им поделиться у "тренеров"\"внедренцев") до "в нашей системе принимать товар на конкретный склад надо так, инвентаризацию проводить на нем этак и одномоментно это делать нельзя, а с опцией Z так и вообще склад работать не будет" ? Или традиционно это все на уровне "тайных знаний" планируется оставить?

[macklakov]

Цитата:

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

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

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

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

[TasmanianDevil]

Цитата:

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

Чудесные "новые связи", которые никто в МС "не захотел" по кнопочке "выбор" в диалогах "оценить" с точки зрения пользователей (конечно они будут по внутренним номерам записей в таблицах, что-то себе отфильтровать)

При наличии привязки фильтруемого поля к EDT, унаследованному от RecId и ссылающемуся на определенную таблицу, кто запрещает переопределить tooltipField() для поля значения ограничения в целях расшифровки (по значениям группы полей autolookup или autoindentification в целевой таблице) выбранных значений ограничения?

P.S. В скрине родной production на 2009-й, но там та же "петрушка" - расшифровка выбранных значений ограничения по RecID-образным ссылкам.

[ALES]

Цитата:

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

кто запрещает переопределить ...в целях расшифровки

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

[TasmanianDevil]

Цитата:

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

да да очередной "программизм"
Пользователь не хочет ничего "расшифровывать", пользователь хочет сразу видеть понятную ему информацию

Перевязать контрол значения ограничения на Edit-метод, работающий с полем значения ограничения и возвращающий то, что потребно мятущейся пользовательской душонке, но сохраняющий то, что потребно системе.
Вдогонку для ограничений по полям-ссылкам с RecId'шными EDT одну динамическую лукап-форму возможностью множественного выбора (в нее при запуске передавать хранимое значение ограничения для первичной инициализации пометок уже выбранного).

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

[mazzy]

Цитата:

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

Модель это скорее некая папка - она не создает пространства имен. Имена в разных моделях не могут пересекаться.

Модуль, это сборка. А пространство имен глобальное, общее, одно.

Тут у меня такое соображение. По мотивам выступления Макса Белугина.

Может разница в восприятии сложности диктуется namespace'ами?

У кого есть 2012, могут попробовать набрать что-нибудь например из nameSpace System. См. скриншоты.

В неймспейсах каждый список относительно небольшой.
И особой разницы между методами или классами нет.

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

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

[ax_mct]

Цитата:

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

Может разница в восприятии сложности диктуется namespace'ами?

Это попытка нахождения ответа на вопрос "почему".
Почему программист со стороны приносит свое - это понятно.
А вот "зачем" ему это позволяют и есть вопрос.

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

Цитата:

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

Вот это образчик чистейшего программизма. Т.е. если бы хотели с помощью Office Add-In и своего монопольного права на систему уничтожить зависимых конкурентов, это понятно. Но в данном случае партнеру урон был нанесен непреднамеренно. Просто их в универе учили что база должна быть нормализована, вот они и нормализовали. Консультанты-перебежчики из GP сказали что их клиент захочет увидеть аналитики через черточку, вот и получили.

[mazzy]

Цитата:

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

Первый - зачем вообще трогать то что работает?

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

Изменяют для расширения функционала.
Причем очень много функционала не видно в россии. Очень много функционала для других стран.

Цитата:

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

Не могут же кротам давать карт-бланш, это безумие так делать.

почему кротам?
а кому, как не разработчикам давать карт-бланш на изменение кода? кто еще то?

[ax_mct]

Цитата:

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

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

Изменяют для расширения функционала.
Причем очень много функционала не видно в россии. Очень много функционала для других стран.


почему кротам?
а кому, как не разработчикам давать карт-бланш на изменение кода? кто еще то?

Изнутри должно быть виднее, но со стороны кажется что все совершенно наоборот.

Левой рукой "системные классы" меняются не ради функционала, а ради неких "общепринятых принципов", делая код более абстрактным чтобы он был более абстрактным.

В то же время правой рукой добавляется фунционал вертикальных решений с таким качеством кода или дизайном что зубы сводит. Это не только ритэйл, но и TAM, PDC в R3.

То есть "улучшение кода" и "добавление функциональности" - это два разных параллельных процесса. Улучшение не приносит функциональности, а новая функциональность приносит плохой код.

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

Тут ведь вопрос в том, нас покрыло облаками и прочим нас не радующим. А есть ли здесь умысел бизнеса или это результат неуемного технарского зуда? Мне все больше кажется что это революционное бешенство низов. Потому как с точки зрения бизнесмышления это все не обьяснить.
А фанатизмом толпы - объяснимо.

[ALES]

Цитата:

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

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

Очень даже объяснить.. уже выросло n-е поколение, которое невозможно "оторвать от айфончега" и возможность "монетизировать и контролировать во всех смыслах "широкие массы" на уровне "матки-облака" это вам не какие-то там "штучные лицензии" юр. лицам предлагать по доброй воле продлить Времена когда ITшники "основатели" писали "методологии" и прикладной код "для себя" канули в небытиё и "бешенство низов" основанное на изучении "в школе", что, допустим, "ООП хорошо, а goto плохо" и подпитанное "в институте" "модными технологиями" вполне в тренде глобальной наживы
Да и все "модные технологии" еще и ресурсоемки обычно, что подталкивает тележку гонки вооружений "современным железом" и ослик дальше бежит "за морковкой" по кругу "надувая" акции IT индустрии
ps: коллеги, делаем ставки на "увидим ли мы "сценарии работы от MS" или и так всем все понятно?

[mazzy]

Цитата:

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

ps: коллеги, делаем ставки на "увидим ли мы "сценарии работы от MS" или и так всем все понятно?

видим же. но не все.
на LCS есть бизнес-процессы. они же сценарии.

[EVGL]

Цитата:

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

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

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