Эта статья уже давно находится в моем списке дел.
Но кажется, только сегодня у меня хватило сил и времени воплотить это в жизнь.
Совпадение или нет, но я нахожусь в том же кафе, где недавно опубликовал свою первую статью.
Наверное, они что-то подмешивают в напитки, которые здесь подают. Так? Бородатый, хороший совет — следовать передовому опыту? Мы слышим о них постоянно.
Мы даже дали им короткие прозвища, например DRY или KISS, и автоматически использовали их в технических разговорах.
Мы фанатично следуем концепциям, и если кто-то случайно хочет или просто по незнанию не следует им, мы выливаем на них ведра грязной критики.
Мы пленники этих убеждений и отказываемся отвернуться от них в нужный момент. Конечно, я не имею в виду, что такие принципы, как DRY, плохи.
Это определенно не так.
Я просто думаю, что это все зависит от ситуации .
Сильно.
Что касается конкретно DRY, то это приводит к логическому выводу: «На самом деле, я тот, кто иногда склоняет других к дублированию, а не к абстракции».
Да, вы правильно прочитали.
Дублирование кода (также известное как копирование) может быть полезной практикой.
Особенно, когда абстракция, заменяющая повторяющиеся части кода, причиняет боль при попытке ее понять.
Как распределяется время программиста? Когда я рассказываю людям, чем зарабатываю на жизнь, они все думают, что я странный, что я стучу за клавиатурой по десять часов в день или больше.
Хотя я не уверен, что со мной все в порядке, я уверен, что не пишу код десять часов подряд. Дело в том, что мы, программисты, тратим гораздо больше времени на чтение кода , а не его написание.
Я не уверен, сталкивались ли вы когда-нибудь с подобной информацией раньше, но исследования и Роберт С.
Мартин утверждают, что существует некая пропорция для этого вида деятельности.
И я, например, вижу потрясающую разницу.
Оказывается, на каждый час написания кода приходится десять часов чтение кода (своего или чужого).
Это чрезвычайно важно.
Усилия, которые мы вкладываем в повседневную работу, тратятся в основном на чтение.
Конечно, чтения кода недостаточно.
Нужно больше этого понимать .
Это означает, что мы должны сделать все возможное, чтобы создать ясный, краткий и легко читаемый код. Это принесет пользу всем, включая нас самих в будущем.
Имейте это в виду, потому что мы вернемся к этой идее позже.
Примечание о DRY Для тех, кто не знаком с термином СУХОЙ, это означает — не повторяйся (Не повторяйтесь).
Этот принцип программирования или лучшая практика, если хотите, предполагает создание абстракций поверх каждого повторяющегося фрагмента кода.
DRY имеет много преимуществ.
Во-первых, абстракции говорят, что если в будущем потребуются изменения, то вам придется иметь дело с ними в одном месте — в самой абстракции.
Вбирая в себя функционал другого модуля, чьего-то API и т.п.
вас волнует только то, как выглядит интерфейс (или абстракция).
Вас не волнует базовая реализация.
Таким образом, шаблоны проектирования программного обеспечения, такие как шаблон интерфейса, упрощают рефакторинг реализации, не вмешиваясь в абстракцию, которую используют другие.
Так что абстракции — это хорошо, и DRY того стоит. Тогда почему я настаиваю на копировании кода в некоторых сценариях? Ну просто потому что.
Цена абстракций За каждую абстракцию приходится платить.
Затраты не всегда могут быть оценены сразу.
Но со временем они появляются.
Абстракции содержат дополнительный уровень метаданных.
Метаданные, существование которых вам в принципе может быть неясно (особенно если вы их не писали).
Каждая новая порция информации увеличивает когнитивную нагрузку на мозг.
И, как следствие, время, которое вы потратите на чтение такого фрагмента кода, увеличивается.
Глубокая кроличья нора Проблема с DRY и фанатичным поклонением этому принципу не заметна в небольших проектах.
Но это заметно у средних и крупных.
В таких проектах очень редко бывает только одна абстракция на копию.
Потому что по мере развития проекта и появления новых требований старый код всегда нуждается в корректировке.
Представьте себе этот сценарий.
Вы присоединяетесь к новому проекту и впервые просматриваете код. Как только вы привыкнете к тому, как все устроено, и поймете, как все работает, вы начнете внедрять новые опции, менять старые и так далее.
Вы меняете существующий код и абстракции.
Вы всего этого не писали, но это есть.
И, скорее всего, для этого есть очень веская причина.
Как я сказал Сэнди Мец :
Уже написанный код имеет мощный авторитет. Само его существование свидетельствует о его правильности и необходимости.От этого не хочется к нему прикасаться.
Теперь новая функция определенно может использовать ту хорошую абстракцию, которая уже существует. Но, как оказалось, с абстракцией нужно немного поработать.
Он не был разработан для этого конкретного пользовательского сценария.
Если бы вы только могли это немного изменить.
Или, может быть, написать новую абстракцию поверх существующей, которая инкапсулирует дополнительную повторяемую логику, а? Да, кажется, это правильное решение! Вот что значит СУХОЙ.
Совершенно ясно, как мы можем довести это безумие до абсолютной крайности.
Крайности, где все заключено в абстракциях.
А те, в свою очередь, окутаны более сложными абстракциями.
И так до бесконечности.
В таких случаях абстракция теряет свою ценность.
Оно существует благодаря убеждениям, которым мы слепо следуем.
И это делает абстракцию неверной.
Оно существует только потому, что у нас есть возможность его создать.
Как уже упоминалось, абстракции создают когнитивную нагрузку на мозг.
Мы почти всегда расплачиваемся препятствиями и временем, необходимым для расшифровки (помните, мы тратим больше времени на чтение кода, чем на его написание).
Но неверная абстракция еще хуже, чем просто абстракция.
Потому что неправильные абстракции не только бьют вас по яйцам, но и заставляют громко смеяться.СУХОЙ или не СУХОЙ Так когда же инкапсулировать повторяющийся код, а когда нет? Ответ по сути прост. Но с практической точки зрения это не совсем так.
Но это тоже приходит с опытом.
Всегда абстрагируйтесь, если только абстракция не будет стоить вам больше, чем дублированный код.То есть, если другой участник проекта часами пытается понять написанную вами абстракцию, то, вероятно, вы делаете что-то не так.
Не создавайте абстракций только потому, что у вас есть на это возможность.
Предскажите, будет ли в этой конкретной части больше повторяющегося кода или нет, и примите соответствующее решение.
Иногда дублирование менее трудоемко, чем следование дереву вложенных вызовов различных методов, отслеживание передаваемых параметров и возможных побочных эффектов и т. д. Последняя мысль в защиту себя Надеюсь, эта статья не будет кричать «к черту эту СУХУЮ и прочую хрень!» Я абсолютно уверен, что это хороший принцип программирования.
Но все же я призываю вас не следовать этому слепо.
Поместите все, что вы узнаете, в контекст и всегда подвергайте сомнению обоснованность своих идей и действий.
Это единственный разумный путь повышения профессионализма.
(Перевод Наталья Басс ) Теги: #сухой #дублирование кода #практика программирования #программирование #дизайн и рефакторинг #Промышленное программирование
-
Мне Все Еще Нужно Разослать Приглашения!
19 Oct, 24 -
Спросите Итана №68: Выбор Карьеры Астронома
19 Oct, 24 -
Хабрастатьи О Жизненном Цикле
19 Oct, 24 -
Yandex.ee: Эстонский Клон Яндекса
19 Oct, 24 -
Плюсы: Джемперы :)
19 Oct, 24
