Что такое грязный код
Перейти к содержимому

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

  • автор:

Чистый код

Рефакторинг — это, в первую очередь, превращение грязного кода в чистый.

Чистый код проходит все тесты

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

Чистый код очевиден для других программистов

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

Чистый код не содержит дублирования

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

Чистый код содержит минимум классов и других движущихся частей

Чем меньше кода, тем меньше его нужно держать в голове. Чем меньше кода, тем меньше вероятность его сломать.

Чистый код легче и дешевле поддерживать!

Refactoring.Guru

  • Премиум контент
    • Книга о паттернах
    • Курс по рефакторингу
    • Введение в рефакторинг
      • Чистый код
      • Технический долг
      • Когда рефакторить
      • Как рефакторить
      • Раздувальщики
        • Длинный метод
        • Большой класс
        • Одержимость элементарными типами
        • Длинный список параметров
        • Группы данных
        • Операторы switch
        • Временное поле
        • Отказ от наследства
        • Альтернативные классы с разными интерфейсами
        • Расходящиеся модификации
        • Стрельба дробью
        • Параллельные иерархии наследования
        • Комментарии
        • Дублирование кода
        • Ленивый класс
        • Класс данных
        • Мёртвый код
        • Теоретическая общность
        • Завистливые функции
        • Неуместная близость
        • Цепочка вызовов
        • Посредник
        • Неполнота библиотечного класса
        • Составление методов
          • Извлечение метода
          • Встраивание метода
          • Извлечение переменной
          • Встраивание переменной
          • Замена переменной вызовом метода
          • Расщепление переменной
          • Удаление присваиваний параметрам
          • Замена метода объектом методов
          • Замена алгоритма
          • Перемещение метода
          • Перемещение поля
          • Извлечение класса
          • Встраивание класса
          • Сокрытие делегирования
          • Удаление посредника
          • Введение внешнего метода
          • Введение локального расширения
          • Самоинкапсуляция поля
          • Замена простого поля объектом
          • Замена значения ссылкой
          • Замена ссылки значением
          • Замена поля-массива объектом
          • Дублирование видимых данных
          • Замена однонаправленной связи двунаправленной
          • Замена двунаправленной связи однонаправленной
          • Замена магического числа символьной константой
          • Инкапсуляция поля
          • Инкапсуляция коллекции
          • Замена кодирования типа классом
          • Замена кодирования типа подклассами
          • Замена кодирования типа состоянием/стратегией
          • Замена подкласса полями
          • Разбиение условного оператора
          • Объединение условных операторов
          • Объединение дублирующихся фрагментов в условных операторах
          • Удаление управляющего флага
          • Замена вложенных условных операторов граничным оператором
          • Замена условного оператора полиморфизмом
          • Введение Null-объекта
          • Введение проверки утверждения
          • Переименование метода
          • Добавление параметра
          • Удаление параметра
          • Разделение запроса и модификатора
          • Параметризация метода
          • Замена параметра набором специализированных методов
          • Передача всего объекта
          • Замена параметра вызовом метода
          • Замена параметров объектом
          • Удаление сеттера
          • Сокрытие метода
          • Замена конструктора фабричным методом
          • Замена кода ошибки исключением
          • Замена исключения проверкой условия
          • Подъём поля
          • Подъём метода
          • Подъём тела конструктора
          • Спуск метода
          • Спуск поля
          • Извлечение подкласса
          • Извлечение суперкласса
          • Извлечение интерфейса
          • Свёртывание иерархии
          • Создание шаблонного метода
          • Замена наследования делегированием
          • Замена делегирования наследованием
          • Введение в паттерны
            • Что такое Паттерн?
            • История паттернов
            • Зачем знать паттерны?
            • Критика паттернов
            • Классификация паттернов
            • Фабричный метод
            • Абстрактная фабрика
            • Строитель
            • Прототип
            • Одиночка
            • Адаптер
            • Мост
            • Компоновщик
            • Декоратор
            • Фасад
            • Легковес
            • Заместитель
            • Цепочка обязанностей
            • Команда
            • Итератор
            • Посредник
            • Снимок
            • Наблюдатель
            • Состояние
            • Стратегия
            • Шаблонный метод
            • Посетитель
            • C#
            • C++
            • Go
            • Java
            • PHP
            • Python
            • Ruby
            • Rust
            • Swift
            • TypeScript

            Рефакторинг

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

            Грязный код

            Грязный код

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

            Чистый код

            Чистый код

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

            Процесс рефакторинга

            Процесс рефакторинга

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

            Запахи кода

            Запахи кода

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

            Техники рефакторинга

            Техники рефакторинга

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

            Премиум Онлайн Курс

            Курс рефакторинга

            21 запах кода, 66 рефакторингов
            Живые примеры на Java/C#/PHP
            Никаких лимитов по времени

            Refactoring.Guru

            • Премиум контент
              • Книга о паттернах
              • Курс по рефакторингу
              • Введение в рефакторинг
                • Чистый код
                • Технический долг
                • Когда рефакторить
                • Как рефакторить
                • Раздувальщики
                  • Длинный метод
                  • Большой класс
                  • Одержимость элементарными типами
                  • Длинный список параметров
                  • Группы данных
                  • Операторы switch
                  • Временное поле
                  • Отказ от наследства
                  • Альтернативные классы с разными интерфейсами
                  • Расходящиеся модификации
                  • Стрельба дробью
                  • Параллельные иерархии наследования
                  • Комментарии
                  • Дублирование кода
                  • Ленивый класс
                  • Класс данных
                  • Мёртвый код
                  • Теоретическая общность
                  • Завистливые функции
                  • Неуместная близость
                  • Цепочка вызовов
                  • Посредник
                  • Неполнота библиотечного класса
                  • Составление методов
                    • Извлечение метода
                    • Встраивание метода
                    • Извлечение переменной
                    • Встраивание переменной
                    • Замена переменной вызовом метода
                    • Расщепление переменной
                    • Удаление присваиваний параметрам
                    • Замена метода объектом методов
                    • Замена алгоритма
                    • Перемещение метода
                    • Перемещение поля
                    • Извлечение класса
                    • Встраивание класса
                    • Сокрытие делегирования
                    • Удаление посредника
                    • Введение внешнего метода
                    • Введение локального расширения
                    • Самоинкапсуляция поля
                    • Замена простого поля объектом
                    • Замена значения ссылкой
                    • Замена ссылки значением
                    • Замена поля-массива объектом
                    • Дублирование видимых данных
                    • Замена однонаправленной связи двунаправленной
                    • Замена двунаправленной связи однонаправленной
                    • Замена магического числа символьной константой
                    • Инкапсуляция поля
                    • Инкапсуляция коллекции
                    • Замена кодирования типа классом
                    • Замена кодирования типа подклассами
                    • Замена кодирования типа состоянием/стратегией
                    • Замена подкласса полями
                    • Разбиение условного оператора
                    • Объединение условных операторов
                    • Объединение дублирующихся фрагментов в условных операторах
                    • Удаление управляющего флага
                    • Замена вложенных условных операторов граничным оператором
                    • Замена условного оператора полиморфизмом
                    • Введение Null-объекта
                    • Введение проверки утверждения
                    • Переименование метода
                    • Добавление параметра
                    • Удаление параметра
                    • Разделение запроса и модификатора
                    • Параметризация метода
                    • Замена параметра набором специализированных методов
                    • Передача всего объекта
                    • Замена параметра вызовом метода
                    • Замена параметров объектом
                    • Удаление сеттера
                    • Сокрытие метода
                    • Замена конструктора фабричным методом
                    • Замена кода ошибки исключением
                    • Замена исключения проверкой условия
                    • Подъём поля
                    • Подъём метода
                    • Подъём тела конструктора
                    • Спуск метода
                    • Спуск поля
                    • Извлечение подкласса
                    • Извлечение суперкласса
                    • Извлечение интерфейса
                    • Свёртывание иерархии
                    • Создание шаблонного метода
                    • Замена наследования делегированием
                    • Замена делегирования наследованием
                    • Введение в паттерны
                      • Что такое Паттерн?
                      • История паттернов
                      • Зачем знать паттерны?
                      • Критика паттернов
                      • Классификация паттернов
                      • Фабричный метод
                      • Абстрактная фабрика
                      • Строитель
                      • Прототип
                      • Одиночка
                      • Адаптер
                      • Мост
                      • Компоновщик
                      • Декоратор
                      • Фасад
                      • Легковес
                      • Заместитель
                      • Цепочка обязанностей
                      • Команда
                      • Итератор
                      • Посредник
                      • Снимок
                      • Наблюдатель
                      • Состояние
                      • Стратегия
                      • Шаблонный метод
                      • Посетитель
                      • C#
                      • C++
                      • Go
                      • Java
                      • PHP
                      • Python
                      • Ruby
                      • Rust
                      • Swift
                      • TypeScript

                      Грязный, чистый, устремлённый

                      Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

                      Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?

                      Давайте сначала разберёмся с определениями.

                      Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.

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

                      Эта аналогия не вполне корректна (как и большинство аналогий), но примерно передаёт ощущения, возникающие при работе с кодом. Неважно – чужим ли, своим ли, написанном пару месяцев назад и уже прочно забытым. Код либо нравится, либо нет. Он либо красив, чист и приятен – либо волосат, уродлив и дурно пахнет.

                      И, конечно же, у каждого есть свои критерии «красоты кода». Свой, так сказать, вкус.

                      Но, тем не менее, есть какие-то общие точки, о которых если и спорят, то вяло и соглашательски. Не о сути, а об обрамлении.
                      Давайте попробуем их перечислить.

                      Легко читается и понимается Запутан, неочевиден, трудно понимаем
                      Легко поддаётся изменениям Закостенел в своих внутренних связях; изменить что-либо стоит неимоверных усилий и жертв
                      Может быть расширен, либо встроен куда-нибудь в виде отдельного модуля Для расширения требует переписывания, для встраивания – обёрток
                      Поддаётся автоматизированному тестированию Может быть протестирован, лишь как «чёрный ящик»

                      Конечно, можно начать спор о «читабельности» или «понимабельности» кода. Это совсем не формализованные термины.

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

                      А желательно – основательно поковырять ООП и стараться инкапсулировать логику в отдельных классах, чтобы не приходилось напрягать головной мозг ни разбором огромных «портянок» кода на десятки экранов, ни запутанными связями процедур и функций, которые к тому же (omg) оперируют кучей глобальных переменных.

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

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

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

                      Чистый

                      Теперь давайте всё-таки попробуем разобраться – зачем же он вообще нужен, этот чистый код? И так ли уж плох код грязный и волосатый?

                      Ну, для начала нужно сказать: it depends.
                      Бывают моменты, когда написать «быстро и грязно» куда важнее, чем «долго и чисто». Хотя нужно отметить, что «грязно» далеко не всегда означает «быстро». Бывает, что ровно наоборот.

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

                      Например

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

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

                      То есть утилиту эту в идеале используют один-два раза, после чего выкинут. Чистота кода здесь совершенно не важна.

                      Другой пример

                      Сервер иногда падает, почему – никто не знает. Анализатор логов позволил понять, что падение вызывается большим количеством однотипных запросов, приходящих с вполне определёнными значениями параметров, и эту ситуацию необходимо срочно воспроизвести.
                      Нужно написать небольшую утилитку, которая будет в точности воспроизводить это поведение.

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

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

                      Это ненамного замедлит разработку утилиты «здесь и сейчас» — зато, когда вновь встанет вопрос о воспроизведении последовательности запросов на сервер – утилита будет тут как тут и потребует минимального допиливания; а главное – минимального времени на вспоминание, что там к чему.

                      Третий пример

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

                      Казалось бы – модуль изолирован, интерфейсы взаимодействия с другими модулями определены. «Кручу-верчу, говнокод писать хочу». Но тут возникает серьёзное «НО».

                      Что будет с этим модулем через полгода? Год? Потребует ли он поддержки? Изменения? Расширения функционала? Возможно, в итоге разовьётся в отдельный продукт?
                      Если хотя бы на один вопрос можно дать хотя бы ответ «вероятно» — то говнокодить, увы и ах, строго не рекомендуется.

                      Но это не весь список вопросов. А кто будет работать с этим модулем через два-три года? Тот, кто его писал, или кто-то другой?

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

                      Если же работать с этим кодом будет сам разработчик – то тем более. Да он через полгода уже не будет помнить: что, где и как работает! Ему придётся разбираться в этом коде так, как будто код совершенно чужой. Не враг же он самому себе?

                      Четвёртый пример

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

                      С одной стороны – code and forget, можно писать что угодно и как угодно, лишь бы работало.

                      С другой стороны – а что, если этот заказчик через месяц вернётся и попросит за дополнительные деньги что-то добавить или переделать? Будем плакать, колоться, но жевать кактус? Откажемся от заказа?

                      А что, если он обратится к другому разработчику (компании), получит негативный feedback о качестве исполнения проекта, и больше никогда не вернётся к «злым говнокодерам», да ещё своим друзьям отсоветует?

                      Я уже не говорю о таких вещах, как качество кармы и память потомков.

                      Пятый пример

                      Самый жёсткий случай абсолютного недопущения говнокодирования.
                      Мне сложно даже представить себе какие-либо аргументы в пользу осознанного выбора плохого кода в случае командной разработки.

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

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

                      А тестирование? Сопровождение? Расширение функционала??

                      Я мог бы написать ещё пару хулительных абзацев – но нет. Не могу.
                      Клавиатура выпадает из ослабевших пальцев при мысли о том, сколько вреда может принести говнокод в команде…
                      Это ужасно… ужасно…

                      Устремлённый

                      Итак, мы примерно понимаем, что такое грязный код и чем он плох. Мы всё ещё не вполне понимаем, что такое чистый код, но ощущаем его необходимость.
                      Почему же он всегда есть, этот грязный код, почему он всегда присутствует и портит жизнь всем – в том числе и своим авторам?

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

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

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

                      И при этом, в идеале, он всегда ощущает, что его код всё ещё недостаточно хорош, что ему ещё далеко до совершенства. И пусть его сегодняшний «говнокод» на голову выше самого лучшего, что он писал два-три года назад – всё равно есть куда расти.

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

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

                      1) Хорошо работающая голова (поэтому у нас всегда есть задачки на логику)
                      2) Высокий уровень самокритичности (поэтому всегда есть задачки на написание кода и поиск ошибок в нём)
                      3) Интерес к программированию (важен в меньшей степени, задачками не определяется в принципе)

                      То есть понятно, что если голова работает плохо – то разработчиком не станешь при всём желании и старании. Однако, если она даже золотая и светится от разумности – это ещё далеко не гарантия.

                      Частенько бывает, что молодой специалист, видя, как легко ему всё даётся (особенно – в сравнении с большинством своих одногруппников, сокурсников, просто ровесников) начинает искренне считать, что круче бывают только яйца.
                      И, хотя наверняка к этому есть некоторые основания, но ЧСВ зашкаливает настолько, что в итоге в один прекрасный момент он просто перестаёт развиваться, считая, что «я и так умный, а кто пытается это оспорить – тот дундук».

                      И хорошо, если при этом у него остаётся живой, острый интерес к своей работе. Если он продолжает читать статьи и книги «потому, что интересно». Тогда у него остаётся небольшой шанс не застыть, а продолжать развиваться.

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

                      Начинает чаще выполнять задачи «строго по спецификации», желательно – уже знакомые задачи, из знакомых сфер. Меньше уделять внимания новым языкам, платформам, концепциям.

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

                      Но так и не достигает вершины своего изначального потенциала.

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

                      Ах, как прекрасна эта картина – так и хочется смахнуть несуществующую слезу! Как прекрасен он, этот устремлённый в бесконечность молодой человек, своим духовным порывом приподнимающий самые небеса, в которые нацелен его всепроникающий взгляд!

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

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

                      И остаться внизу, с щемящей радостью наблюдая, как пронизывают они пространство и время в своём стремлении.

                      И знать, что хотя бы немного, хотя бы чуть-чуть – помог, поддержал, а не стоял в стороне, застывший в своём упоении собственной важностью, не бросал презрительных взглядов – «пхе… молодёжь..»

                      • чистый код
                      • говнокод
                      • самосовершенствование
                      • обучение программированию

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


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

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

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

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


                      Грязный код


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

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

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

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

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

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


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

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


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


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


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

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

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


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

                      • Делайте рефакторинг, когда добавляете новую функцию
                      • Делайте рефакторинг, если требуется исправить ошибку
                      • Делайте рефакторинг при разборе кода

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *