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

[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 можно и чисто настройками. Но в целом поддерживаю: сделано так запутано, что лезть просто туда страшно. Страшнее даже, чем делать миграцию данных по фиксированной цене : ) Одно спасает - стандартный контракт, где настройки прав доступа отданы на откуп клиенту.