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

[DAX.Company]

Цитата:

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

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

Помню продавать начали 2012. Первый вопрос у заказчика - а в чем плюс для нас. Ну там краснея объясняешь мол Product Management стал вот такой... оптимальный. Ну AIF там... 7ая версия вовсе как я понимаю не продавалась. Но МС мало видимо. Такое впечатление, что в компании реально программисты рулят. А не экономисты

[dech]

Цитата:

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

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

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

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

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

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

[gl00mie]

Цитата:

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

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

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

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

[macklakov]

Цитата:

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

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

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

[belugin]

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

[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 и вряд ли я буду переписывать разноску в ГК.
Так что для меня изучение нового замечательного, богатого на новые программистские технологии модуля дало в целом негативный экономический эффект. Я потратил изрядное время на получение знаний сомнительной полезности и применимости.

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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

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

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

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

[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" или и так всем все понятно?

[belugin]

Цитата:

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

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

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

Кошелек Миллера - чтобы чем-то комфортно оперировать надо иметь это в количестве 7+-2.

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

PHP код:

PS E:\RainMain\Source\AppIL\Metadata\ApplicationSuite> ls -Recurse -Include *.xml |  measure

Count    : 78843 


Это количество объектов в ApplicationSuite чтобы их равномерно разбить на кусочки по 8 надо

[Math]::Log(78843, 8)

5.42223168398599 уровня. НАД уже существующими объектами приложения.

Но существующие объекты тоже достаточно жирные. Если посчитать строчки кода, то:

PS E:\RainMain\Source\AppIL\Metadata\ApplicationSuite> ls -Recurse -Include *.xml | %{ (gc $_.FullName).Length }|  measure -sum | % sum
24284376

PS E:\RainMain\Source\AppIL\Metadata\ApplicationSuite> [Math]::Log(24284376, 8)
8.17784169341017

Цитата:

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

Это называется Single Responsibility Principle

Цитата:

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

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

То есть у нас есть объекты приложения, модели, модули, причем отличить внутренне от внешнего можно только на уровне объектов приложения (да и то не всех). У модулей есть ключевое слово internal, но оно не работало для нас, например год назад полностью - не поддерживалось в VS и не было InternalsVisibleTo (что надо для юниттестов).

Под классами есть методы, функции (которые не рекомендуется использовать).

То есть нужно ~9 уровней а есть пять, причем, последние два воявились в 2012 и 7 и внутренности нельзя спрятать выше уровня класса.

На уровне модуля хотя бы контроллируются зависимости и их нецикличность.

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

[mazzy]

Цитата:

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

Кошелек Миллера - чтобы чем-то комфортно оперировать надо иметь это в количестве 7+-2.

угу-угу. и я в эту сторону говорю.

Цитата:

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

Это количество объектов в ApplicationSuite чтобы их равномерно разбить на кусочки по 8 надо

макс, ты сейчас продемонстрировал блестящий программистских подход.
равномерно(!) разбивать на кусочки по 8(!) все(!) объекты аксапты никто не просил.
убежден, что из всех читателей только у тебя такая мысль возникла ))))

как только появляется слово "все" - жди логической ошибки.

Цитата:

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

Если посчитать строчки кода, то:

жжошь!

Цитата:

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

Это называется Single Responsibility Principle

спасибо )
SOLID - не священная книга.
Эти принципы имеют свои области применения и имеют случаи, когда их не рекомендуется применять.

Кроме того есть паттерн Фасад https://en.wikipedia.org/wiki/Facade_pattern
и много других.

собственно вопрос этой темы: почему один принцип, не слишком свойственный старой аксапте, упорно применяется в последних версиях.

Цитата:

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

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

и суффиксы. и соглашения по наименованию объектов.
и вообще много чего было придумано.

Цитата:

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

То есть у нас есть объекты приложения, модели, модули, причем отличить внутренне от внешнего можно только на уровне объектов приложения (да и то не всех).

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

Цитата:

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

То есть нужно ~9 уровней а есть...

Кому нужно, Макс?
Кому? И зачем?
Какие свойства возникнут в системе после того, как эти уровни появятся, а какие свойства пропадут?

Цитата:

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

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

Наверное...

[belugin]

Цитата:

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

макс, ты сейчас продемонстрировал блестящий программистских подход.
равномерно(!) разбивать на кусочки по 8(!) все(!) объекты аксапты никто не просил.
убежден, что из всех читателей только у тебя такая мысль возникла ))))

как только появляется слово "все" - жди логической ошибки.

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

Цитата:

жжошь!

Можно развернуто.
У тебя есть какая-то другая метрика для оценки коричества информации в коде?

Цитата:

спасибо )
SOLID - не священная книга.
Эти принципы имеют свои области применения и имеют случаи, когда их не рекомендуется применять.

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

Цитата:

и суффиксы. и соглашения по наименованию объектов.
и вообще много чего было придумано.

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

Цитата:

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

При чем тут это?

Цитата:

Кому нужно, Макс?
Кому? И зачем?
Какие свойства возникнут в системе после того, как эти уровни появятся, а какие свойства пропадут?

См рассуждения выше.

[mazzy]

Цитата:

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

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

хм... логично.

Цитата:

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

Можно развернуто.
У тебя есть какая-то другая метрика для оценки коричества информации в коде?

о... вот ты озадачил. не думал в этом направлении
а зачем такая метрика?

Цитата:

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

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

а... ты об этом.
знаю-знаю. но специально стараюсь не использовать терминологию в ВОПРОСАХ.
выбор терминологии отвечающим позволяет многое узнать о его ходе мысли.

вот я спросил про "ездач", а ты ответил одним из принципов в SOLID.
а почему именно SOLID? почему не другие шаблоны и паттерны?

почему спрашиваю? а потому что основным инструментом SOLID является рефакторинг кода. SOLID - это шаблон agile разработки.

но:
1. майерософт выпущенный в релизе Аксапты код не рефакторит по соображениям совместимости. )))
2. с точки зрения не-МС-программистов, набор классов в Аксапте является библиотекой. agile не очень подходит для разработки библиотек )))

==================
и вообще, если человек задает вопросы - это не значит что он не знает ответа.
это значит, что он хочет узнать мнение другого человека.
)

Цитата:

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

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

т.е. отсутствие инструментария...
и в самом деле, причем тут это?

[macklakov]

Цитата:

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

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

Ну по этому вопросу, как раз, разночтений нет. Не встречал еще человека который считает что сваливать все объекты в одну кучу AOT, да еще и в одно пространство имен, это хорошее решение. Это как раз особенность AX по которой мало кто скучать будет.

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

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