Что такое грязный код

В каком движке по чище код?

Что такое грязный код? Точки, запятые невпопад рассыпаны?

100% ПС любят, когда пишут без орфографических ошибок.

Jaf4:
Что такое грязный код? Точки, запятые невпопад рассыпаны?

100% ПС любят, когда пишут без орфографических ошибок.

Грязный код? Ну например жмём на нашей страничке клавиши Ctr+U и смотрим что там. Если подключено куча CSS файлов-то это не хорошо) а если вверху сразу видно главное меню-тогда ок) это просто пример)

Кто тебе этот бред сказал?

The WishMaster вообще то это как бы общепринятое мнение. я впитал это давно. не один год назад. тупо меньше времени затрачивается на индексацию сайта) поисковику просто быстрее и удобнее индексировать сайт на котором код по чище. и это хорошо)

ну общепринятость — условная, никак не влияющая на индексацию. Есть понятие валидного кода html, так он зависит не от движка, движок лишь сервис для управления сайтом. Я видел сайты, сделанные в ворде с кодом, который легче убить и сделать новый, чем прочесть, и эти сайты вполне себе жили, индексировались без проблем.

Что такое грязный код я так и не понял, ну есть допустим несколько css.. чем это хуже одного большого файла, если несколько грузятся быстрей?

Jaf4 валидность-это тема отдельная) ессно я на сайтах которые продвигаю делаю чтобы ошибок было или 0 или совсем мало. А на счёт CSS-то тут по скорости милисекунды. этого не заметит никто. а вот то что чем меньше CSS подключено тем лучше для ПС-это тоже все так считают. или многие по крайней мере)

Чистый и безопасный код — миф или реальность?

Каждый язык программирования разработан с учетом разных операционных систем, платформ, стилей кодирования и предполагаемого использования. Обычно мы слышим о языках Python, PHP, Ruby, JavaScript, Java, C, C++ и C#, а также более современных их разновидностях, такие как Rust, Swift, Hack и многих других.

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

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

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

В таком случае важно иметь в виду, что сходу написать идеальный код невозможно. Для этого нужно потратить множество часов на обдумывание и детальное планирование. Здесь каждый для себя выбирает сам, что приоритетнее: написание чистого кода или скорость работы.

Чистый код — это объективно хороший код. Он написан максимально лаконично и элегантно, без дублирования. Он структурирован таким образом, чтобы его было легко читать как людям, так и компьютерам. Каждый может написать код, понятный компьютеру, но только хороший программист может написать код, понятный человеку.

Небрежно написанный код стоит дорого, а на его обслуживание уходит много времени и усилий. Кроме того, код более подвержен ошибкам, которые могут привести к сбою программы.

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

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

Отладка — это исправление ошибок в коде.

Тем не менее даже чистый код имеет срок годности. Программное обеспечение и вычисления существуют в быстро меняющемся ландшафте. Код, который раньше был чистым, устаревает.

Устаревший код — это код, который не поддерживается и не обновляется, но используется. Он работает или нет, при этом никто не понимает почему. Чем старше код в вашей кодовой базе, тем труднее его понимать, независимо от того, насколько хорошо он был написан.

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

• Отсутствие избыточности кода

Код должен соответствовать правилу DRY (Don’t repeat yourself с англ. — «не повторяйтесь»). Это означает, что любое изменение в одном участке не должно требовать изменений в других.

• Минимум зависимостей

Если в коде существует множество зависимостей, его сложнее поддерживать или изменять в будущем.

• Минимум расширений

В коде должно быть минимальное количество как классов (шаблонов для создания объектов, обеспечивающих начальные значения состояний), так и методов (функций или процедур, принадлежащих определенному классу или объекту.

• Функциональность и легкочитаемость кода

Код должен быть прост, удобен и понятен, чтобы любой разработчик мог его быстро прочитать. Для этого многие разработчики используют правила KISS (keep it simple and straightforward с англ. — «сохраняйте простоту») и YAGNI (You aren’t gonna need it с англ. — «вам это не понадобится»).

• Анализ кода

Используйте языковые инструменты статического анализа для проверки вашего кода.

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

• Сегодня в мире разработки функциональность и скорость перевешивают безопасность. Предприятия не могут опережать конкурентов, не создавая и не выпуская новые фичи в короткие сроки.

• Безопасность не является конкурентным отличием: потребители не думают о безопасности при использовании приложения или при покупке умного устройства, будь то умный термостат или лампочка. Вспомним инцидент из 2020, когда дрон смог взломать умные лампочки Philips Hue и вызвать вирусную реакцию.

Согласно отчету Veracode, более трех четвертей (75,8%) приложений имеют хотя бы один недостаток безопасности, а 23,7% содержат недостатки высокой степени серьезности, и исправление этих недостатков обычно занимает месяцы.

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

Современные операционные системы и приложения подключаются через интернет и регулярно обновляются. Эти обновления в большинстве случаев делаются не только для добавления дополнительных функций, но и для исправления ошибок. Обновления делают систему более устойчивой к новым вредоносным программам. Подробнее о необходимости обновлений мы писали в аналитическом обзоре.

Из-за уязвимостей в коде хакеры и совершают атаки на устройства. Так, они могут украсть информацию, вмешаться в работу устройства или удалить всю важную для вас информацию.

Список существующих уязвимостей довольно длинный, поэтому мы рассмотрим лишь некоторые из часто встречающихся, а также те, которые причиняют наибольший ущерб. Согласно исследованию одними из наиболее популярных уязвимостей являются: Information leakage (утечка информации) — 65,9%; Cross-Site Scripting (XSS, межсайтовый скриптинг) — 47,1%; SQL Injection (внедрение SQL-кода) — 27,8%.

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

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

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

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

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

• «Чистый код. Создание, анализ и рефакторинг», Роберт Мартин

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

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

• «Рефакторинг. Улучшение существующего кода», Мартин Фаулер

Эта книга стала учебником для многих разработчиков по всему миру. В ней подробно изложена идеология рефакторинга. Основу книги составляет подробный перечень более 70 методов рефакторинга, для каждого из которых описываются мотивация и техника испытанного на практике преобразования кода с примерами на Java. Рассмотренные в книге методы позволяют поэтапно модифицировать код, внося каждый раз небольшие изменения, благодаря чему снижается риск, связанный с развитием проекта.

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

• «Совершенный код» (Code Complete), Стив Макконнелл

Это высоко ценимая книга в индустрии разработки ПО. Основной посыл — «ошибки в программном обеспечении возникают из-за сложности кода». Книга была написана почти 30 лет назад, с тех пор идеи прочно вошли в сообщество разработчиков программного обеспечения.

Эта книга будет полезна разработчикам с опытом 3-5 лет. Стоит учитывать, что в некоторых местах она откровенно устарела и не всегда может быть применима к возможностям разработки небольших компаний.

Одним из недостатков является большой объем книги и то, что она, похоже, в основном ориентирована на объектно-ориентированные языки (C ++, Java) и даже более старые императивные (C, Ada и т. Д.)

• Прочитайте дополнительно о принципах YANGI, DRY, KISS и SOLID.

— ускоренные курсы программирования, курсы безопасности и учебные пособия по программированию. Для начинающих программистов этот канал предоставит множество полезных советов, практических примеров и сценариев. — самый оптимистичный программист на YouTube. Дэниел Шиффман, автор канала, помимо того, что является преподавателем в университете, создает массу отличного контента, в основном состоящего из учебных пособий и задач по программированию.

— канал содержит много уроков по CSS и JavaScript, выпуски о различных нюансах и хитростях в работе с кодом. — это коллекция видеороликов, которые научат вас всему, что нужно для работы в качестве багхантера. — образовательные видео о компьютерах и компьютерных вещах. Есть серии видеороликов, связанных с темой кибербезопасности. — видеоуроки профессионального уровня почти по всем популярным языкам программирования. Тут туториалы по JavaScript, React, C++, ML, Arduino, C#, Django и по многим другим направлениям.

— проверяет чистоту коммитов, готовность ваших проектов к выпуску и насколько хорошо ваш код соответствует цели. А если вы не попали в цель, вы сразу узнаете, что не так и как это исправить. — платформа безопасности приложений, которая автоматизирует тестирование на протяжении всего процесса непрерывной интеграции, чтобы разработчики могли быстро решать проблемы. — это инструмент статического анализа кода C/C ++, анализирующий код с целью обнаружения ошибок и с фокусом на обнаружении неопределенного поведения и опасных конструкций кода. Цель состоит в том, чтобы уменьшить количество ложных срабатываний. — инструмент автозавершения кода, основанный на искусственном интеллекте. — это средство для форматирования кода с поддержкой множества языков, которое нацелено на использование жестко заданных правил по оформлению программ. — линтер для JavaScript. Невероятно полезен, потому что JavaScript, будучи интерпретируемым языком, не имеет этапа компиляции и многие ошибки могут быть обнаружены только во время компиляции. ESLint позволяет разработчикам обнаруживать проблемы с кодом JavaScript, не выполняя его. — конфигурационный файл и набор расширений для настроек синтаксиса. Помогает поддерживать единый стиль кодирования для нескольких разработчиков, работающих над одним проектом в разных редакторах и IDE.

• Hack the Box (HTB)

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

• Академия Digital Security

Платформа от Академии Digital Security — бесплатная платформа по обучению кибербезопасности, которое построено на игровых механиках и нацелено на отработку практических навыков на реальных кейсах, развернутых на виртуальных машинах. Курсы разработаны действующими пентестерами и исследователями в области информационной безопасности.

Курс «Веб-безопасность» содержит обзор самых распространенных атак, ключевых мер защиты веб-приложений (корпоративных порталов, ДБО, систем электронной коммерции и т.д.) и методов аудита кода. С курсом «Безопасное программирование на Java» вы сможете развить навыки защиты, выполняя задания на эксплуатацию и исправление кода в приложениях, написанных на Java. При этом результаты будут видны сразу на живом приложении.

• Pentestit

На платформе Pentestit есть программы практического обучения в области информационной безопасности: Zero Security: A и Corporate Laboratories. Учебный процесс включает теоретические и практические занятия, на которых опытные инструкторы Pentestit рассказывают о характере и способах обнаружения уязвимостей.

«Zero Security: A» — это программа начального обучения тестированию на проникновение Pentestit, в рамках которой стажеры осваивают различные инструменты тестирования на проникновение и изучают основы этического взлома: от разведки и сбора информации до обеспечения безопасности в системе.

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

Одна из самых известных и популярных образовательных платформ. На сегодняшний день у них есть учебники по HTML, CSS, Sass, JavaScript, Rails, AngularJS, ReactJS, Ruby, Command Line, Git, SQL и Java.

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

Миф. Следующий вопрос.

Помню как то в одной игре писал код. Иногда редактировал код из других материалов, но там кода на 200 тысяч строчек. Из особенностей, отладчик или дебаггер перестает работать уже на 5 тысяч строк кода — просто нельзя ничего сделать, курсор зависает даже если выключить всё.

И, правишь так код, а связи между собой там еще и закодированы. И единственный способ проверить верность кода — вернуть его в игру, и запустить. Если игра выпала в главный экран, значит ошибка в коде)

Первым на помощь пришел инструмент отмена действия — благо sublime text это делать позволяяет. Скопировал момент с ошибкой, и отменяешь анализируя или проверяяя результат.

Второй вариант, уже чуть позже, когда стал заниматься этим реже — сервис сравнить 2 текста. И здесь я видел все изменения от предыдущей точки.

Писать код без ошибок — это надо иметь тягу. Когда я начал, в один момент затянуло неслабо, я 2 ночи не спал (и дня), то есть 3 суток коддинга.

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

Потом была пауза. Армия. Вернулся, думал я сис админ.
В итоге, в свободное время стал писать игры в браузере для себя.
Позже занялся рекламой, так как всё так же сис-админил.

И только в 2017 году обнаружил, что все эти навыки ценны. Но я всё это делал для себя) Так что, кто то занимается для себя, а кто то ради другой цели, поэтому и есть всегда эта проблема "а почему код грязный?".

It’s okay to write dirty code

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

Я чувствую то же самое. И стараюсь делать мой код максимально чистым.

Но эта попытка писать чистый код на самом деле тормозит большинство из нас. Мы учимся медленнее. Мы делаем меньше. И в результате мы вносим меньший вклад в этот мир.

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

Когда писать грязный код

Есть несколько случаев, когда можно написать грязный код:

1. Когда вы в тупике
2. Когда вы хотите написать хороший код
3. Когда вы хотите сделать что-то быстро

Второй пункт звучит противоречиво, да? Мы доберемся до этого. Обещаю.

Пишите грязный код, когда вы в тупике

Когда вы в тупике, любой прогресс лучше, чем отсутствие прогресса. Это относится ко всему в жизни, даже к кодингу.

Например, я обычно испытываю трудности, когда пытаюсь писать статьи. Я чувствую себя некомфортно, потому что подвергаю себя цензуре. Эти мысли пришли мне в голову, когда я писал эту статью:

1. Эта идея недостаточно хороша
2. Я не должен писать так
3. Что если кто-то увидит эту статью и решит, что я паршивый разработчик?

Написание грязного кода в равной степени страшно, потому что мы, разработчики, гордимся написанием хорошего и чистого кода. Мы носим это как знак чести. Если мы не пишем чистый код, мы паршивые разработчики.

Мы тупим, потому что сосредоточены на попытках писать чистый код. Наши идеи не текут.

Думайте о мыслях как о воде в кране.

1. Хорошие идеи, хорошая работа, хорошее написание, хороший код и т.д. — это горячая вода.
2. Плохие идеи, плохой код, плохое написание, плохая работа — это холодная вода.

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

Попробуйте включить кран, вставив в него большой палец. Что происходит? Вода застревает. Вы не дадите ни одной из ваших мыслей вытечь.

Если вы хотите сделать что-то стоящее, вам нужно перестать подвергать себя цензуре. Это запустит процесс создания. Это позволит воде течь.

Затем, когда вы включите кран, холодная вода неизменно потечет первой. Неважно, как давно вы включили нагреватель. Это потому, что холодная вода уже готова вытечь. Горячая вода пойдет только после того, как холодная вода закончится.

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

1. Вы не приходите на работу с хорошими идеями.
2. Вы не пялитесь на экран с надеждой, что умеете кодить.

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

Догадываетесь как я пришел к этой аналогии холодной/горячей воды?

Я начал писать эту статью со слов «Я цензурирую себя прямо сейчас …». Посмотрите, что вы сейчас читаете. Вы даже не осилили половину, и вы хотите читать дальше. Да? 🙂

Пишите грязный код, когда вы хотите написать хороший код

Как вы можете писать грязный код, чтобы писать хороший код? Это звучит противоречиво.

Хороший код происходит от плохого кода. Так же, как хорошее письмо происходит от плохого письма.

Вы можете высказать свои мысли (без редактуры) в своем блоге. Это просто. Но это будет плохая писанина. Она будет содержать всякую не относящуюся к делу информацию.

Хорошее письмо происходит от очистки плохого письма. Это называется редактированием. Именно здесь мы режем и сжигаем все, что не помогает нам донести сообщение, которое мы хотим донести.

Хороший код тоже происходит от редактирования. За исключением того, что мы называем этот процесс рефакторингом: изменением кода так, чтобы написанное не влияло на его поведение.

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

Этот процесс занимает время. Это требует терпения.

Когда вы хотите сделать что-то быстро.

Разработчики имеют привычку добавлять функционал, который не нужен, в нашем коде. Например:

1. Мы помещаем код в функции, когда нам это не нужно.
2. Пишем используя ООП, ФП или другие парадигмы, когда в этом нет необходимости.
3. Мы используем map / filter / reduce , когда проще написать цикл for

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

Когда мы что-то делаем, то часто добавляем больше сложностей, чем нужно. Например, когда я делал таймер обратного отсчета для страницы продаж Learn JavaScript, я добавил поддержку часовых поясов для всех часовых поясов в мире… хотя мне был нужен только PST.

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

В начале нормально писать плохой код. Это мешает вам писать что-то слишком навороченное и помогает делать вещи быстрее.

Как писать хороший код (последовательно и быстро)

По сути, процесс написания хорошего кода сводится к:

1. Написанию плохого кода
2. Отверганию самоцензуры во время написания
3. Рефакторингу, когда вы закончили писать плохой код

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

Сворачиваемся

Если вы хотите писать хороший код, мы должны сначала написать плохой код. Пусть паршивость изольется из тебя и что-то хорошее последует за ней.

Это рискованно и страшно. Но это то, что мы должны сделать.

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

Вот что улучшит положение дел, когда вы впервые напишите дерьмовый код. ��.

Что такое рефакторинг кода?

Рефакторинг — это контролируемый процесс улучшения кода, без изменения его функциональности.

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

Рефакторинг — важный этап в процессе разработки любого программного обеспечения. Этот процесс рассматривается как неявный компонент гибкой разработки, где от разработчиков ожидается, что они будут постоянно улучшать качество кода. Другой случай, когда требуется рефакторинг, — требования к программному обеспечению обновляются, а разработчикам необходимо адаптировать систему под эти требования.

Необходимость рефакторинга

Грязный код

Цель рефакторинга кода — превратить грязный код в чистый и снизить общий технический долг проекта.

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

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

Некоторые типы грязного кода включают:

• громоздкие методы или классы, которые сложны для манипуляций;
• неполное или неправильное применение принципов объектно-ориентированного программирования;

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

Грязный код с запахом

Определить необходимость рефакторинга можно на основе запахов кода. Запахи кода — индикаторы проблем, на которые нужно обращать внимание при рефакторинге. Их легко найти и исправить, однако иногда они предвещают глубинные проблемы с кодом.

Авторы книги «Рефакторинг» Мартин Фаулер и Кент Бек дают следующие варианты запахов кода:

• Повторяющийся код

Как следует из названия, это тот случай, когда вы оставляете один и тот же фрагмент кода в нескольких местах. Этот недочет можно исправить, извлекая код и превращая его в метод, а затем вызывая этот метод вместо копирования и вставки кода. Такое решение известно как Extract Method (метод извлечения).

• Длинный метод

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

• Большой класс

Этот запах нарушает принцип единой ответственности (SRP); букву «S» в принципах SOLID. Этот принцип гласит, что у каждого класса должна быть только одна причина для изменения, что означает, что у него должна быть только одна ответственность. А когда у нас большой класс, это означает, что у него больше одной ответственности. Такого быть не должно, потому что из-за этого цель класса неясна. Чтобы следовать SRP, мы используем класс Extract, где один класс играет роль двух классов, или Extract Subclass, где у класса есть функции, которые используются только в некоторых экземплярах.

Когда делать рефакторинг

• Правило 3 ударов

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