Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 21

tl:dr все хорошо в меру.
Всего голосов 10: ↑9 и ↓1+8

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

Всего голосов 2: ↑2 и ↓0+2

Непонятно, что, чем и в чём измеряли, но в целом, фраза хорошая, жизненная.

Комментарий пока не оценивали0

Эта фраза хорша в меру.

Всего голосов 4: ↑4 и ↓0+4
этот комментарий подходит к любому комментарию :)
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь

тут проблема не в лишнем количестве абстракций, а в неправильном выборе абстракций

Всего голосов 2: ↑2 и ↓0+2

DRY "не работает", потому что мы не умеем прогнозировать какие абстракции нам нужны в будущем.
Решение: прогнозировать, какие абстракции нам в будущем не нужны и отказываться от "лишних".
Что-то типа постановления московского бургомистра, согласно которому о пожаре надо было сообщать за три часа до возгорания.

Всего голосов 2: ↑2 и ↓0+2
Основной посыл статьи: DRY использовать нехорошо, т.к. в процессе можно нечаянно породить кривую абстракцию.
Так ее и без DRY сочинить можно — было бы желание. Рецепт тут прост: не порождайте кривые абстракции, блин!

ИМХО, если у разработчика достаточно квалификации, чтобы аргументировать, почему вот здесь дублирование кода лучше — вероятно, ему просто лень, ибо той же самой квалификации должно хватить на грамотное изменение без Copy-Paste существующего кода.
Всего голосов 4: ↑4 и ↓0+4

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


Основной посыл статьи такойже как в The Wrong Abstraction — Sandi Metz:


duplication is far cheaper than the wrong abstraction
Всего голосов 1: ↑1 и ↓0+1
Я не обвиняю, мне просто интересно, как подсчитать, что Copy-Paste дешевле, даже учитывая соотношение read/write кода как 10/1.

С одной стороны, вы пишите новый код, который так же надо будет часто читать. Т.е. увеличиваете трудозатраты.

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

Далее, если согласиться с принципом Single Responsibility, значит признать, что уже в исходном коде есть проблемы, поскольку функциональную часть одной сущности потребовалось продублировать в другой. Следовательно, бояться появления кривых абстракций поздно — они уже есть — надо их признавать и побеждать.
Всего голосов 2: ↑2 и ↓0+2

В моём понимании, тут нужно двигаться от понятия "неверная абстракция". Как правило, с большей или меньшей вероятностью, можно предположить как будет развиваться код: будет он расходится или будет изменятся синхронно. В первом случае, как нетрудно догадаться, делать абстракцию будет излишним, во втором, напротив, необходимо её сделать.


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


Объясняется это тем, что ввести абстракцию будет дешевле, чем убрать ту, которая не заработала.


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

Комментарий пока не оценивали0
А вот с моим опытом почему-то оно согласуется плохо, особенно, когда есть несколько разработчиков над одной активно меняющейся кодовой базой. В этом случае ненулевая вероятность, что они:

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

2. Завяжутся на задублированный код, поэтому рефакторинг уже будет затрагивать не только первоначальные 2 копии, но и другие 100500 новых мест. Опять же лишняя работа.
Всего голосов 2: ↑2 и ↓0+2

Ну, опыт у всех разный, тут уж ничего не попишешь. Отсюда, собственно, и разнообразие подходов, и споры об их достоинствах.

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Как раз недавно продублировал пару методов, чтобы во-первых не городить ещё один класс (в родительский их поместить было бы совсем неправильно), а во-вторых сами классы стали быстрее читаться. Они маленькие и методы в них короткие. Конечно из названий понятно что они делают, но не понятно, например, что они лезут в базу и не кешируют результат, а значит ответственность кешировать ли его (и как) лежит на пользовательском коде. Разумеется можно было бы инкапсулировать кеширование минимум двумя способами (по аргументу или создав обёртки/дочерние классы), но это во-первых ограничивало бы применение кое-каких оптимизаций, а во-вторых маскировало бы «цену обращения» и кто-нибудь обязательно бы начал использовать всё это неправильно, сильно повредив производительности, как уже бывало.
Это я к тому, что действительно нужно искать компромисс между множеством характеристик, нельзя делать из одной главную в ущерб остальным (например отсутствие дублирований превыше всего). А если где-то что-то было корректно тогда, когда оно было сделано, это не значит, что так будет всегда и не исключено, что вышеописанный пример когда-нибудь не потребует ввести эти абстракции и убрать дублирование. Но это же будет уже другая ситуация, возможность которой учтена и это не займёт много времени.
Всего голосов 1: ↑1 и ↓0+1

А разве нельзя писать код так, чтобы потраченное время и объём прочитанного кода был минимальным для принятия каких либо обоснованных решений?
Может этим, специфическими дизайном, отличаются какие то языки программирования, основанные на этих принципах, важных в коммерческом программировании где времени — всегда мало?

Комментарий пока не оценивали0
Увлекаясь DRY-ем можно достигнуть предела «совершенства» в виде классов с методами с кучей if или switch/case логики и безумным числом параметров, заполнение которых опционально.

Правильно было сказано, что всё хорошо в меру.

Идеальный код, это код в котором легко можно найти и исправить любую ошибку. Это совокупность приципов KISS и DRY. Т.е. код должен быть написан максимально просто и прямолинейно и в то же время, чтобы исправление пришлось делать только в одном месте в коде.

Многие опытные разработчики пытаются сделать «красиво» и это приводит к тому, что их код с трудом может понять даже другой senior. Если вы хотите проверить, хороший ли ваш код — покажите его Junior-у и посмотрите насколько быстро он в коде разберётся.
Всего голосов 2: ↑2 и ↓0+2
Увлекаясь DRY-ем можно достигнуть предела «совершенства» в виде классов с методами с кучей if или switch/case логики и безумным числом параметров, заполнение которых опционально.

Стратегию и замену условной логики полиморфизмом уже отменили?

Комментарий пока не оценивали0
Конечно нет. Это отличные решения для избавления от проблемы.
Но часто в реальной жизни новая логика дописывается к уже существующей и часто нет возможности провести глобальный рефакторинг для добавления новой абстракции или внедрение паттерна (той же Стратегии к примеру). Конечно в идеальном сценарии ничего рефакторить не прийдётся, т.к. этот случай должен быть предусмотрен архитектурой, но мир не идеален…
С другой стороны не будете же вы добавлять «Стратегию» на каждый создаваемый вами класс?!
Комментарий пока не оценивали0

А зачем глобальный рефакторинг?
Рефакторинг делается ровно такой, чтобы модификации сводились к дописыванию кода.
Стратегия чаще всего реализуется банальным делегатом (или функцией высшего порядка).
Использование паттерна — это не мегастройка, а чистка зубов.

Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Изменить настройки темы

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr