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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

Проект Green, как обьединение купленных ERP в одну на базе .NET, мной воспринимался как создание компонентов-кирпичиков из которых программисты могут очень эффективно строить бизнес-приложения чтобы удовлетворять потребности бизнеса.

Разница в восприятии не в условиях,а в результатах труда. Мой результат труда - удовлетворить потребности бизнеса клиента. Не код сам по себе, а результат его выполнения. Абстракции и улучшение - для меня это термины бизнес-процессов, не кода. Мне все равно какой код, хоть 2000 строк. Я прикладной программист.

Код АX - это прикладной код. Системному программированию там делать нечего.
Есть kernel, вот и улучшайте сборщик мусора.

Оverengineering возможно потому что салон автомобиля перепутали с двигателем.

[dech]

Цитата:

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

Разница в восприятии не в условиях,а в результатах труда. Мой результат труда - удовлетворить потребности бизнеса клиента. Не код сам по себе, а результат его выполнения. Абстракции и улучшение - для меня это термины бизнес-процессов, не кода. Мне все равно какой код, хоть 2000 строк. Я прикладной программист.

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

Для меня мало закончить задачу. Я всегда стараюсь сделать рефакторинг кода в тех классах, которые правлю. Если предстоит скопировать логику класса под какие-то свои цели, я смотрю как можно обобщить её, чтобы не было тупого дублирования. Возникает иерархия классов, происходит выделение общих методов в родительский класс. Дальше эту структуру становится намного легче использовать, добавляя туда полезный код. Естественно, я не делаю такого со стандартом, больше всего ошибок и проблем возникает с кодом компаний, внедряющих собственные решения. Если делается под заказ, то вся работа происходит в сжатые сроки, тут и автотесты писать некогда и рефакторинг проводить времени нет. Скорость без качества. Все конечно довольны, но радость недолго длится. Некоторые ошибки вылезают только лет через 5-7.

Пример: Решили сделать загрузку данных батчем и раскидать в журналы по разным компаниям. Делали через changeCompany и runAs. А потом клиент удивляется, куда пропадает часть данных? Смотрим, вроде нормально, правильно... закоммитили транзакцию, блок смены компании закрыли. Только дальше в этом же методе идёт (внимание) удаление связанных данных, которое происходит уже в текущей компании. После этого я нахожу еще кучу классов, которые делают то же самое. Продублировали без зазрения совести. И никто не удосужился протестировать. Скопипастили и всё, мы - молодцы!

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

P.S. ax_mct, я заранее извиняюсь, т.к. не знаю насколько вы хороший и компетентный разработчик. Но ваш подход в целом мне не нравится.

[ax_mct]

Цитата:

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

...
изменять функционал и добавлять новый все-таки с умом надо. Требовать хороших удобных инструментов любой может. А вот создавать иерархии наследования, выделять интерфейсы, оптимизировать запросы к БД, ускорять работу форм и отчетов не всякому под силу. Многие не задумываясь дублируют метод, или того хуже класс, набитый под завязку этим самым г*. Меняют 2 строчки и довольны.

Для меня мало закончить задачу. Я всегда стараюсь сделать рефакторинг кода в тех классах, которые правлю. Если предстоит скопировать логику класса под какие-то свои цели, я смотрю как можно обобщить её, чтобы не было тупого дублирования. Возникает иерархия классов, происходит выделение общих методов в родительский класс. Дальше эту структуру становится намного легче использовать, добавляя туда полезный код. Естественно, я не делаю такого со стандартом
...
Пример: Решили сделать загрузку данных батчем и раскидать в журналы по разным компаниям. Делали через changeCompany и runAs. А потом клиент удивляется, куда пропадает часть данных? Смотрим, вроде нормально, правильно... закоммитили транзакцию, блок смены компании закрыли. Только дальше в этом же методе идёт (внимание) удаление связанных данных, которое происходит уже в текущей компании. После этого я нахожу еще кучу классов, которые делают то же самое. Продублировали без зазрения совести. И никто не удосужился протестировать. Скопипастили и всё, мы - молодцы!
...

Только счас вчитался, как то мозг сразу не осознал.
Коллега, вы крайне опасный романтик программирования.

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

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

Из-за страха/неприятия перед дублированием кода создавать иерархии наследования, выделять интерфейсы, выделять общие методы в родительский класс -
это как ни парадоксально звучит и есть overengineering.

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

И как правильно подметил Bobkov, повтор кода - может быть необходим для обеспечения независимости кода. Всегда есть аспекты тестирования, деплоймента, одновременной работы, сырость требований и прочее помимо чистого искуства. Ремесленные аспекты.

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

[macklakov]

Цитата:

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

Требовать хороших удобных инструментов любой может. А вот создавать иерархии наследования, выделять интерфейсы, оптимизировать запросы к БД, ускорять работу форм и отчетов не всякому под силу. Многие не задумываясь дублируют метод, или того хуже класс, набитый под завязку этим самым г*.

Сделать наследование таблиц еще сложнее. Требуется и талант и образование и опыт большой. А вот сделать интеграцию с банком конкретным, особых талантов и знаний не надо. Надо просто упереться и сделать. При этом интеграция со всеми существующими банками "из коробки" рынку нужна, а вот наследование таблиц под большим вопросам. Но почему-то вместо интеграции у нас наследование таблиц.
Ах, да! О чем это я! Нам же дали замечательную универсальную интеграцию с банками! Недоделанный SSIS. Тоже непростая техническая задачка, я вам скажу. Типа от нормального банка мы получим файл, для которого квалифицированный девелопер легко подправит XSLT и мы получим желанную интеграцию. Только вот бизнес, заразы такие, когда выбирают банк, почему-то не спрашивают, какому стандарту следуют их файлы, они смотрят на выбор и стоимость финансовых инструментов. И бизнес приходит в некоторую оторопь, когда оказывается что в каком нибудь копеешном бухгалтерском пакете все эти банки уже есть. А вот в AX партнер либо продает дополнительный пакет интеграции, нормально поддерживать который у них нет ресурсов, либо лихорадочно ищет человека, который знает и X++ и XSLT и еще в состоянии разобраться с дикими форматами банковских файлов.

[Ace of Database]

Цитата:

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

Все конечно довольны, но радость недолго длится. Некоторые ошибки вылезают только лет через 5-7.

Люди радовались целых 5-7 лет

[belugin]

Цитата:

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

Оverengineering возможно потому что салон автомобиля перепутали с двигателем.

Код-это не салон и не двигатель, это чертежи и документы по которым компилятор и установщик строит салон и двигатель.

Соответственно примерно по таким же законам надо работать.

Какой документ лучше, вот такой?

Цитата:

• У лисы длинный хвост.
• У бобра длинный хвост.
• Кенгуру имеет длинный хвост.
• Такой же хвост и у собаки.

Или вот такой:

Цитата:

У этих животных хвосты длинные

• Лиса
• Бобер
• Кенгуру
• Cобака.

Однозначного ответа нет. Весь список целиком проще понять во втором случае. Внести изменения касающееся только бобра проще в первом случае.

Если надо поддерживать всех животных (допустим добавить, что хвост покрыт шерстью), то изменение требует анализа всех вариантов.

Если нас волнует только кенгуру нам проще найти поиском ее и уточнить какой хвост у него.

Могут быть промежуточные варианты - например нас волнуют все, кроме кенгуру.

Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции
- у операций бывают параметры
- если не сказано обратного, то надо :
- загрузить параметры из SYsLastValue
- спросить параметры согласно типам
- сохранить их в SysLastValue
- выполнить операцию

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

Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder.

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

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

То есть надо каждый раз повторять:
метод main, диалог (создания и получения), сохранение и восстановление и работу с версиями (все же аккуратно поддерживают восстановление из старых версий в unpack, да?). Я вот конкретно иногда забывал добавить строчку в getFromDialog или копировал но не правил и от этого были ошибки.

P.S. Это тут было?
https://www.youtube.com/watch?v=GRr4xeMn1uU

[Bobkov]

Цитата:

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

Какой документ лучше, вот такой?
Или вот такой:
Однозначного ответа нет.

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

Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные".

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

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

IMHO, конечно

[belugin]

Цитата:

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

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

Я совершенно согласен с этим, есть еще факторы.

Цитата:

Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные".

Если есть возможность вносить исключения и уточнения, то может быть и первый более понятен. (Документах часто ичспользуют такие штуки, в SysOperation можно добавить кастомную обработку на диалог, вызов или упаковку)

Мне кажется тут первый список понятнее - ясно кто подчиняется общему умолчанию а кто нет.

У этих животных хвосты длинные:
- Лиса
- Бобер
- Кенгуру (кроме австралийских короткохвостых)
- Собака

- У лисы длинный хвост.
- У бобра недлинный хвост.
- Кенгуру имеет длинный хвост (кроме австралийских короткохвостых).
- Такой же хвост и у собаки.

Цитата:

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

Еще один аспект - это насколько легко перейти от одного варианта к другому. В случае документа, для возникновения дублирования, достаточно просто провести замену начала строки в куске на общую фразу. Обратное преобразование почти никогда нельзя сделать автоматически - формы могут отличаться при том же содержании.

В случае кода, мы можем тоже провести замену, или воспользоваться каким-нибудь инструментом для рефакторинга (рефакторинги начинающиеся с inline)

Цитата:

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

Есть coupling и cohesion - если изменения надо как правило делать в двух местах сразу, иначе это будет ошибкой, то это не повышает надежности.

Я не против дублирования в принципе, просто оно должно быть обосновано.

[trud]

Цитата:

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

Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции
- у операций бывают параметры
- если не сказано обратного, то надо :
- загрузить параметры из SYsLastValue
- спросить параметры согласно типам
- сохранить их в SysLastValue
- выполнить операцию

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

Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder.

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

[belugin]

Цитата:

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

SysOperation(где та-же видимость и метки задаются атрибутами) такая "простая" с виду модификация потребует кучу усилий

Не могли бы вы рассказать, что вы пытались можифицировать и какую именно кучу усилий это потребовало?