редуцирующий рефакторинг

[amarao]

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

Ещё одна интересная цель для рефакторинга: уменьшать что-то. Чаще всего, люди хотят уменьшить что? Когнитивную нагрузку.

Что такое когнитивная нагрузка? Это когда приходится много помнить. Одно из решений в такой ситуации, это "квадратно-гнездовой подход", когда конкретное место в коде, пусть и простое, и даже проще чем соседи, делается сложнее ради того, чтобы быть одинаковым. Да, в конкретном месте всё просто и состоит их 5 строк вместо 20, но это ДРУГИЕ 5 строк, а рядом 199 раз по 20 одинаковых строк (однинаковой структуры), так что эти 5 простых строк, на самом деле не "5 строк вместо 20", а это "выкинуть 20-строчный паттерн из головы и разбираться с *особым случаем* из 5 новых строк". В такой сиутации рефакторинг может выглядеть странно: было просто и на 5 строк, а стало сложно и на 20, но истинная ценность в том, что раньше было 199 x один, плюс второй, а стало 200 x один, и это значительно проще.

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

Comments

[juan_gandhi]

Я думаю, это описание проблемы слишком абстрактно для меня. DRY тут не срабатывает почему-то?

Конечно, применять везде один и тот же молоток глупо. (У меня дома три молотка и киянка в хозяйстве.)

[amarao]

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

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

В программировании dry делать проще, но и там бывает весьма весело, особенно в районе всяких cargo.toml и прочих не-программистких вещах, полных бойлерплейта.

[juan_gandhi]

CI, конечно, да. Там унификация на другом уровне, похоже.

[amarao]

Вероятнее всего, это будет применимо к любому месту с loose coupling. В программировании тратятся гигантские усилия для того, чтобы с tight coupling не было больно, но это приводит к тому, что экосистема закукливается (не покрывает собой всё, отвергая всё unsound). А где-то всегда есть слой противоречий, который как-то приходится решать (не общим методом, за счёт фиксации непротиворечивых вариантов). Вот там-то копипаста расцветает, и квадратно-гнездовой подход сильно экономит ресурс мозга по сравнению с элегантным решением, особым у каждого.

... Да даже в коде это иногда проявляется. Для тестов нужно патчить/передавать через опциональный параметр, трейт, интерфейс, whatever, и вот все вынуждены его писать, потому что легче написать 30 раз одно и то же, чем один раз, который 30 разных случаев покроет.

[juan_gandhi]

Логично, конечно. Но надо различать. Одно дело каплинг внутри модуля, другое дело - между модулями. А лишние параметры, согласно книжкам по рефакторингу, нужно засовывать в передаваемый объект. В опциональные параметры я вообще не верю; опция не для вывода, а для ввода. Ну так подумать категорно, вот есть монада Option, и что представляет собой функция f:Option[T]->U? Только мешает.