Я был вдохновлен написать это после того, как прочитал отличный пост в блоге о DRY: https://gordonc.bearblog.dev/dry-most-over-rated-programming-principle/

Когда я начал свою карьеру, я довольно быстро узнал о DRY. В кодовой базе, над которой я работал, было очень мало тестов и много дублированных бизнес-правил, которые не должны были дублироваться, так что принцип имел смысл. Однако кодовая база также имела массу повторного использования, что было еще более проблематичным. Такие вещи, как повторное использование представления для разных потоков и навигация в потоке, означали, что некоторые данные застряли в представлении, потому что нужно было обработать так много условий. Со временем возникли различия, и линия за строкой они превратились в пять взглядов, действующих как один.

На этом этапе моей карьеры коллеги использовали инструмент под названием JRebel, и нередко можно было услышать о его использовании на форумах и конференциях. Предпосылка заключалась в том, что он перезагружал код Java в работающую JVM, например. медленные веб-серверы не нужно было перезапускать, чтобы отразить изменения, внесенные в код. Я так и не стал его использовать, а позже я изучил TDD и потом редко запускал веб-сервер. Оглядываясь назад, DRY и JRebel подходили и приносили пользу в тех же условиях «устаревшего кода». Один большой неуклюжий веб-сервер без тестов мог бы разобраться в JRebel и DRY. Я имею в виду, что, вероятно, копирование кода было бы лучше, если бы там не было тестов. Наш менталитет, однако, заключался в том, чтобы сделать монстра кода как можно меньше, а DRY означало, что вы можете изменить условие в одном месте, протестировать его вручную в графическом интерфейсе и чувствовать себя нормально. С скопированной логикой вам пришлось бы иногда менять так много несвязанных мест и, возможно, даже не знать, как выполнить ручной тест.

Энди Хант и Дэйв Томас определили DRY в 1999 году в своей книге The Pragmatic Programmer. И когда я некоторое время назад слушал выступление Дэйва Томаса на ютубе, он сказал в своем выступлении, что в основном не тестирует. Прямая ссылка на цитату: 18:00. Теперь он добился большего, чем я когда-либо буду в этой отрасли, и разговоры тоже отличные. Тем не менее, это заставляет меня еще больше задуматься о том, что тесты — это прямое средство, позволяющее чувствовать себя свободно, чтобы повторять себя. Недостаток, с которым вы иногда сталкиваетесь при повторах, заключается в том, что повторяющиеся строки требуют одинакового обновления в коде. Это может немного раздражать, если это нужно обнаружить путем поиска в кодовой базе. Но функция, которая стоит на своих собственных ногах и дает вам знать, если вы сломали ее из-за неудачных тестов, сводит на нет большую часть этого недостатка. Так что на самом деле, для меня DRY слишком часто используется между функциями, и разработчики забывают, что рефакторинг, избавляющий от дублирования, часто не так сложен, как рефакторинг, избавляющий от связанности.

Кроме того, теперь я активно избегаю библиотек и фреймворков, которые предлагают абстракции, которые предлагают разработчикам выражать вещи с помощью единых монолитных истин. Одной из таких библиотек является hibernate. Раньше, когда JRebel и DRY сосуществовали в кодовой базе, вы также часто встречали там спящий режим. Hibernate — неплохой инструмент для сохранения данных, поскольку часто требуется представить строку с классом для упрощения записи. Но DRY и монолитные ORM-представления, последовавшие за выборками, нанесли практически непоправимый ущерб кодовым базам, над которыми я работал. Поэтому, если бы я мог выбрать одно место, которое должно напрямую избегать DRY, это было бы когда дело доходит до доступа к данным. Лично я давно оставил спящий режим, JRebel в пыли вместе с этими неуклюжими веб-серверами. Я думаю, что многие разработчики были бы поражены тем, как легко можно рассуждать о доступе к данным, когда вам не нужно думать об ORM. Вы можете просто заниматься своими делами и тратить свое время на размышления о стоимости этого доступа.

Я закончу этот пост хорошим поводом для размышлений о Dry DRY. Тестовые классы не должны бездумно копировать использование нестабильного конструктора для зависимости, которая вообще не принадлежит функции. Если эту зависимость нельзя реорганизовать или лучше содержать, то доступ к этой зависимости, вероятно, следует осуществлять с помощью СУХОЙ абстракции. Хотя было странно писать об этом… Но в выступлении, на которое я ссылался ранее, Дэйв Томас говорил именно об этом, что не существует универсальной передовой практики. У DRY тоже бывают моменты под солнцем, или, как выразился Оби-Ван: Только ситх имеет дело с абсолютами.