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

[ax_mct]

Цитата:

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

не, не делимся на два.
или распределяемся по спектру, согласно критериям лучшести )))

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

Обозначим две стороны.
Старые пердуны которые не понимают зачем в Аксапте нужно общепринятое искусство программирования и другие, те кто прочитал "Искусcтво программирования Кнута" до конца.

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

Спектр спектром, но есть четкий водораздел - отношение к тому что есть оver-engineering кода в AX.
Для меня это любой код который я не понимаю в течение трех секунд и любой дизайн который мне интуитивно непонятен как программисту Аксапты. "Зубная боль... Зачем" (с)

Более того если увижу 2000 строк в одном месте - ругаться не буду. Да, это under-engineering но на практике это может быть и дешевле чем оver-engineering когда этот код разбит на пол-сотни классов обслуживающих не бизнес-логику, а междусобойчик паттернов кодирования.

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

Цитата:

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

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