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

[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 лет