Чистый код
Рефакторинг — это, в первую очередь, превращение грязного кода в чистый.
Чистый код проходит все тесты
Если программа проходит только 95% тестов, значит где-то у вас завелся грязный код. Если у вас вообще нет тестов, вы не проходите этот пункт автоматически.
Чистый код очевиден для других программистов
И я не говорю о каких-то супер сложных алгоритмах. Плохое именование переменных, раздутые классы и методы — всё это размывает очевидность кода.
Чистый код не содержит дублирования
Если приходится изменять участок кода с дублированием, нужно будет не забыть внести эти же изменения и в других местах, где код повторяется.
Чистый код содержит минимум классов и других движущихся частей
Чем меньше кода, тем меньше его нужно держать в голове. Чем меньше кода, тем меньше вероятность его сломать.
Чистый код легче и дешевле поддерживать!
- Премиум контент
- Книга о паттернах
- Курс по рефакторингу
- Введение в рефакторинг
- Чистый код
- Технический долг
- Когда рефакторить
- Как рефакторить
- Раздувальщики
- Длинный метод
- Большой класс
- Одержимость элементарными типами
- Длинный список параметров
- Группы данных
- Операторы switch
- Временное поле
- Отказ от наследства
- Альтернативные классы с разными интерфейсами
- Расходящиеся модификации
- Стрельба дробью
- Параллельные иерархии наследования
- Комментарии
- Дублирование кода
- Ленивый класс
- Класс данных
- Мёртвый код
- Теоретическая общность
- Завистливые функции
- Неуместная близость
- Цепочка вызовов
- Посредник
- Неполнота библиотечного класса
- Составление методов
- Извлечение метода
- Встраивание метода
- Извлечение переменной
- Встраивание переменной
- Замена переменной вызовом метода
- Расщепление переменной
- Удаление присваиваний параметрам
- Замена метода объектом методов
- Замена алгоритма
- Перемещение метода
- Перемещение поля
- Извлечение класса
- Встраивание класса
- Сокрытие делегирования
- Удаление посредника
- Введение внешнего метода
- Введение локального расширения
- Самоинкапсуляция поля
- Замена простого поля объектом
- Замена значения ссылкой
- Замена ссылки значением
- Замена поля-массива объектом
- Дублирование видимых данных
- Замена однонаправленной связи двунаправленной
- Замена двунаправленной связи однонаправленной
- Замена магического числа символьной константой
- Инкапсуляция поля
- Инкапсуляция коллекции
- Замена кодирования типа классом
- Замена кодирования типа подклассами
- Замена кодирования типа состоянием/стратегией
- Замена подкласса полями
- Разбиение условного оператора
- Объединение условных операторов
- Объединение дублирующихся фрагментов в условных операторах
- Удаление управляющего флага
- Замена вложенных условных операторов граничным оператором
- Замена условного оператора полиморфизмом
- Введение Null-объекта
- Введение проверки утверждения
- Переименование метода
- Добавление параметра
- Удаление параметра
- Разделение запроса и модификатора
- Параметризация метода
- Замена параметра набором специализированных методов
- Передача всего объекта
- Замена параметра вызовом метода
- Замена параметров объектом
- Удаление сеттера
- Сокрытие метода
- Замена конструктора фабричным методом
- Замена кода ошибки исключением
- Замена исключения проверкой условия
- Подъём поля
- Подъём метода
- Подъём тела конструктора
- Спуск метода
- Спуск поля
- Извлечение подкласса
- Извлечение суперкласса
- Извлечение интерфейса
- Свёртывание иерархии
- Создание шаблонного метода
- Замена наследования делегированием
- Замена делегирования наследованием
- Введение в паттерны
- Что такое Паттерн?
- История паттернов
- Зачем знать паттерны?
- Критика паттернов
- Классификация паттернов
- Фабричный метод
- Абстрактная фабрика
- Строитель
- Прототип
- Одиночка
- Адаптер
- Мост
- Компоновщик
- Декоратор
- Фасад
- Легковес
- Заместитель
- Цепочка обязанностей
- Команда
- Итератор
- Посредник
- Снимок
- Наблюдатель
- Состояние
- Стратегия
- Шаблонный метод
- Посетитель
- C#
- C++
- Go
- Java
- PHP
- Python
- Ruby
- Rust
- Swift
- TypeScript
Зачем писать чистый код, если мои программы работают?
Этот вопрос возник в моей голове уже через несколько месяцев работы на проекте. Очень часто, когда я заканчивал работу над очередным таском и отправлял пул реквест на проверку, я получал серию комментариев касательно моего кода. Несмотря на то, что задача была выполнена и все тесты светились зеленым, мои изменения все равно отклонялись. Комментарии обычно были следующими: метод выглядит слишком большим, переменные не достаточно описывают свое назначение, а вот этот код лучше вынести в отдельный класс и т.д. Это вызывало злость и обиду: “Я же выполнил задачу, все работает и компилятор не жалуется, в чем проблема?”.
Будучи студентом университета, я не очень заморачивался над тем, чтобы “вылизывать” свои программы. Большим успехом было уже то, что мой код просто компилировался, поэтому как только я добивался нужного вывода на экране, я с удовольствием оформлял лабораторную работу и получал положительную оценку. После стольких страданий над задачей мне и в голову не приходило пересмотреть свое решение и попытаться его как-то улучшить. И, конечно же, в то время я и понятия не имел о том, что такое рефакторинг.
На мой взгляд, с этой проблемой сталкивается большинство студентов, которые из года в год пишут код ради получения оценок. Иногда среди них проскакивают гики, которые получают удовольствие от написания программ и стараются совершенствовать свой код с каждым днем. Но даже они, из-за отсутствия заинтересованных наставников или просто постороннего взгляда, упускают очень много деталей. В итоге очень часто начинающие разработчики испытывают чувство несправедливости, когда их начинают ругать за те вещи, которые не имеют прямого отношения к задачам, над которыми они работают. Так ради чего устраивают весь этот блейм и почему просто работающего кода не достаточно?
Когда я пришел на свой первый проект, я думал, что знаю технологию достаточно хорошо, чтобы приносить пользу. Я ошибался. С первых же дней я был окружен сильными разработчиками, которые не давали расслабиться ни на минуту. Приходилось переписывать один и тот же кусок кода по несколько раз, прежде чем он попадал в основную ветку. Проанализировав основные причины, почему мой код не принимают, и пообщавшись с членами команды, я выявил для себя три самых главных постулата, почему чистый код важен:
Когда вы пишете программу, которая должна прожить дольше одной демонстрации, есть стопроцентная вероятность, что туда нужно будет внести изменения. И если программа написана плохо, то кроме вас в ней никто не сможет разобраться. Более того, даже вы через месяц уже забудете, что означают все эти символы, и почему функция для получения данных одновременно выполняет апдейт. Читабельность — самый главный критерий, который сейчас ставится перед разработчиком. Представьте, если бы описание задачи было написано одновременно на разных языках, разными шрифтами, с сокращениями, сленгом, а также захватывало часть другой задачи. Разработчик даже не стал бы открывать такой таск. То же самое касается и кода. Если после просмотра его хочется сразу закрыть и выбросить, то такой проект будет сложно поддерживать. Очень часто для того, чтобы добавить фичу в уже работающий код, его переписывают с нуля, потому что любое изменение может все сломать.
И снова про изменения. Практически невозможно с первого раза написать систему, которая бы выполняла все требования заказчика. Постоянно добавляются новые возможности, находятся баги, изменяется внешний вид. Также можно заметить, что одни версии приложения добавляют новые фичи, а другие — удаляют старые. И представьте, какие трудности могут возникнуть у разработчиков, если удаление кнопки на странице ломает авторизацию. Поэтому умение разбивать программу на слои и изолировать фичи друг от друга можно практически считать искусством.
- Код — самая достоверная документация
Этот пункт косвенно связан с пунктом про читабельность. Для описания любой более или менее сложной компьютерной системы, помимо кода, используется еще ряд документов: диаграммы, блок-схемы, task-board, bugtracker и даже комментарии в коде. Но каждый из этих документов является второстепенным по отношению к коду. И только код однозначно и достоверно описывает, как работает ваша система. Поэтому для того, чтобы видеть цельную картинку “из первых рук”, код должен быть самодокументируемым, а остальные файлы служат для его более удобной визуализации.
В итоге фокус при написании программы смещается от работающего кода к легко изменяемому коду. Чистый гибкий код становится основной целью каждого разработчика. Это тот универсальный скилл, который можно переиспользовать от проекта к проекту и который не зависит от предметной области. Более того, если посмотреть внимательно на основные паттерны, практики и гайдлайны, то они не привязаны даже к языку программирования. Если уметь ими правильно пользоваться, то можно создавать отличные продукты независимо от платформы и технологии.
Я несколько раз использовал понятие “чистый код”, но так и не показал, как он выглядит. На самом деле нет строгого определения, что является “чистым”. Проведем следующую аналогию. Что отличает хороший ресторан от забегаловки в переходе? Скорее всего, это качество продуктов, чистая посуда, стерильная кухня, высокие требованию к обслуживающему персоналу, красивый интерьер и культурная публика. Этот список можно продолжать, но даже сейчас заметно, что есть ряд характеристик, которые дают понять, получите вы удовольствие или нет. И даже если вам не нравится определенная кухня или очень высокие цены, вы все равно отдадите предпочтение ресторану перед забегаловкой. То же касается и кода. Несмотря на то, что каждый разработчик видит идеальный код по-своему, все же есть некоторый набор практик, которые однозначно отделяют плохой код от хорошего:
- Правильные имена переменных, функций, параметров: переменная должна однозначно описывать свою роль.
- Короткие лаконичные функции, которые выполняют только одну задачу: следует отделять функции для чтения данных от функций для изменения и стараться их не смешивать.
- Отсутствие дублирования кода: следуйте принципу Don’t Repeat Yourself, а именно старайтесь выносить код в отдельные блоки (функции), которые в дальнейшем можно будет переиспользовать.
- Использование библиотечных функций вместо написания своих: не изобретайте велосипед, используйте чужие наработки. Скорее всего, они гораздо лучше протестированы и покрывают разные критические ситуации. Плюс, вам не нужно тратить время на написание кода и его отладку.
- Использование декларативного стиля вместо императивного: код должен говорить, что он делает, а не как он это делает.
Конечно же, это не полный список требований к чистому коду. Гораздо больше практик вы можете найти в таких книгах, как Refaсtoring 1, 2, Code Complete и Clean Code. Но даже на основе этих пяти пунктов вы можете оценить свой код — является ли он “чистым”.
Это однозначно очень непростая задача — взглянуть на свой код “со стороны”. Для этого не достаточно только знаний, нужна еще определенная практика и критическое мышление. После того, как вы прочли теорию, вам необходимо:
- Посмотреть на свои предыдущие наработки (это могут быть пробные проекты, учебные задачи или лабораторные работы) и исправить все проблемы, которые получится найти. Поскольку их может быть очень много, такая монотонная работа позволит вам запомнить основные ошибки и не допускать их в дальнейшем.
- Попросить своего друга найти как можно больше проблем в вашем коде. Скорее всего, не придется его долго упрашивать. Будет лучше, если вы попросите нескольких человек посмотреть ваш код и составить список ошибок. Так вы получите более объективную оценку и большее количество проблемных мест. Этот процесс называется code review. Его используют в повседневной жизни разработчики, чтобы уже на начальных этапах (сразу после написания кода) выявить как можно больше слабых мест и исправить их до того, как код пойдет в релиз.
- Если вы уже достаточно хорошо “почистили” свои программы, можно попробовать показать их более широкому кругу программистов. Я очень часто люблю копаться в чужих наработках, изучать стиль других разработчиков, анализировать, что я пишу не так. Для этого я использую разные ресурсы, но я бы хотел выделить парочку:
- Github открывает доступ к коду программистов со всего мира практически на всех языках программирования. Я как C# разработчик часто смотрю, как устроены те или иные библиотеки от Microsoft и других крупных компаний. Это позволяет лучше ориентироваться в том, как выполняется программа и как устроены алгоритмы “под капотом”.
- Codewars дает вам возможность решать задачи, придуманные другими людьми. Задачи устроены таким образом, что решение “в лоб” не всегда работает, и нужно посмотреть на проблему под другим углом. В таком режиме очень удобно совершенствовать навыки владения языком, который вы уже знаете, или изучать новый. В качестве бонуса ваше решение могут оценить другие программисты, а вы можете посмотреть на чужие решения. Сайт делит код на очень умный и изощренный, а также изящный и лаконичный.
- Да кому вообще нужен этот чистый код?
- Как написать чистый код?
- Подробное руководство
- Как править НЕ чистый код?
- SRP — принципа разделения обязанностей/единственной ответственности;
- OCP — принципа открытости/закрытости;
- LSP — принципа подстановки Лисков;
- ISP — принципа разделения интерфейса;
- DIP — принципа инверсии зависимости.
- Выбор подходящего алгоритма. Это, пожалуй, самое простое. От выбора алгоритма зависит, будет ли код работать как Flash или как Eeyore. Так что обновляйте свои алгоритмы.
- Использование соответствующего оборудования. Например, кэшей L1/L2 и CPU для ускорения работы кода. Кэш L1 может работать в 100 раз быстрее, чем оперативная память, а L2 — в 25 раз. Но для этого вам необходимо знать, как функция и данные расположены в памяти: чтобы кэш работал, они должны располагаться близко друг к другу. Для этого можно использовать паттерны Data-Oriented Design и Entity-Component-System.
- Дополнительные наборы инструкций для CPU, такие как MMX, SSE и AVX.
- Овладейте основами разработки. Не нужно глубоко проникать в то, что происходит внутри компьютера. Вам достаточно понимать, что происходит “под капотом” настолько, насколько это необходимо для работы с кодом. Освойте также на базовом уровне используемые вами язык программирования и инструменты.
- Изучите домен. Под доменом в программной инженерии обычно понимается предметная область, на которую рассчитано приложение. Глубокое знание домена позволяет понять, что именно пытается решить тот или иной код. Только в этом случае можно написать код, наиболее соответствующий потребностям домена. Например, для домена приложения “Очередь в больнице” не нужна производительность, измеряемая в наносекундах. Поэтому можно сократить время разработки. Иначе обстоит дело с видеоиграми, где требуется рендеринг в реальном времени. Но даже в этом случае некоторые части кода нуждаются в тщательной проработке. Возможно, рендеринг в реальном времени номера в очереди для приложения “Очередь в больницу” потребует повышения производительности. Или для игры более высокого уровня понадобится максимально чистый код, который облегчит создание модов.
- Используйте абстракции грамотно. Имея глубокие знания о домене, вы можете создать стратегию подхода к проблеме. После этого необходимо использовать абстракции по решению проблемы. Абстракции можно определить как сокрытие сложной и ненужной для данного контекста информации и придание ей большей значимости. В данном случае абстракция — это не просто абстрагирование, как в объектно-ориентированном программировании. Это лишь один из видов абстракции. Типы переменных — это абстракции. Они абстрагируют биты, составляющие реальное значение в памяти. Именование переменной — это абстракция. Это абстрагирование неизвестной переменной в нечто более релевантное текущему контексту переменной. Операции и функции являются абстракциями регистровых инструкций. Именование операции или функции — это абстракция. Структуры данных — это абстракции. Слои — это абстракции.
- Будьте прагматичны. В конце концов, цель программирования — предоставить пользователю решение в виде приложения. Разумеется, вы должны дать пользователю то, что он хочет получить от приложений или игр. Возможно, ему нужна производительная игра с более чем 100 FPS? А может, он заинтересован в приложении с большим количеством функций, надежном, без ошибок и поставляемом как можно быстрее? Вы должны быть прагматичным, располагая теми инструментами, которые у вас есть, потому что пользователям все равно, как вы выполните свою работу. Знаете крылатое выражение про молоток и гвозди? Если у вас в руках молоток, то вам везде мерещатся незабитые гвозди. Не надо так делать.
- Проявляйте гибкость. Поймите, что парадигмы, паттерны и принципы программирования — это лишь инструменты и ориентиры, позволяющие усовершенствовать код. Они не являются жесткими правилами, которые необходимо выполнять всегда и любой ценой. Не каждый switch-case надо изменять в соответствии с принципом открытости/закрытости. Не каждый объект нужно преобразовывать из “массива объектов” в “объект массивов” в соответствии с DOD (Data-Oriented Design, решение, ориентированное на поток данных). Любые правила нужно применять с учетом конкретной ситуации. А чтобы понять, какое из них следует использовать, необходимо глубокое понимание основ разработки и области применения.
- Больше заботьтесь о коде и команде. Эта рекомендация, пожалуй, не требует пояснений. Плохой код (т. е. медленный и/или грязный) возникает у программиста, который не заботится о нем. Заботьтесь о своем коде, товарищах по команде, продукте и пользователях. Только тогда вы станете производить максимально качественный продукт. В конце концов, вы ведь пишете код не для одного себя.
- Когда чистый код нецелесообразен
- Основные правила код-ревью
- Как написать чистый код, который легко читать
В Академии мы стараемся уделять качеству кода столько же времени (или даже больше), сколько и разработке функционала. Потому что научиться писать код можно за несколько недель, но чтобы научиться писать хороший код, нужно потратить не один год. Поэтому мы с самого начала стараемся выработать у академистов привычку критически относиться к качеству кода, постоянно искать лучшие решения, переписывать уже рабочий код и всячески совершенствовать стиль написания программ. И тогда вопросы “как назвать переменную?”, “стоит ли выносить этот код в отдельный файл?” или “сколько параметров должна принимать функция?” будут возникать в голове сами собой. Самое главное — это не пренебрегать качеством кода ради работающего функционала.
В заключение хочу привести известную цитату: “Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте”. На первый взгляд она может показаться довольно странной. Но если вдуматься, то можно осознать, какое большое влияние имеет код каждого разработчика на команду в целом. И если вы не хотите, чтобы на следующем code review ваше имя называли чаще остальных, а ваши пул реквесты отклоняли из раза в раз, заставьте себя относиться к коду не просто как к средству решения каких-то бизнес-задач, но еще и как к произведению искусства, которое многое говорит о своем авторе.
Keep calm and write clean code.
Как написать чистый код и сделать жизнь проще
Рассказали, что такое чистый код и зачем он нужен и опишем принципы его создания. Советы основаны на книгах по теме и личной практике.
Максим Морев
Технический директорВ университетах, как правило, рассказывают базовые понятия: алгоритмы и структуры данных, вычислительную математику. Но не про то, как красиво спроектировать приложение и сделать код удобочитаемым и пригодным для доработок. В итоге на практике мы часто получаем бессистемный подход и нечто, что трудно читать, сложно и страшно рефакторить. Потому что явно что-то где-то да упадёт.
Чтобы не допускать такого, мы запускаем серию статей про код, где подробно расскажем, как писать красиво и чисто и получать на выходе поддерживаемый код. В первой части расскажем, что такое чистый код и зачем он нужен и опишем принципы его создания. А дальше на конкретных примерах разберём, как делать надо и не надо.
Да кому вообще нужен этот чистый код?
Читаемый, легко тестируемый, легко компонуемый код, который решает бизнес-задачу и сам является документацией, сокращает ТТM (time to market). За счёт времени, которое разработчик тратит на изучение приложения, внесение изменений в код, добавление новых фич и прочее.
И если приложение плохо спроектировано, код спутан — продуктивность команды, которой приходится разбираться с этим примерно 70% рабочего времени, падает. Это факт. И я с ним сталкивался.
Так что, по сути, он нужен всем, кто работает в IT.
Разработчикам
В первую очередь для того, чтобы быстро анализировать и дорабатывать уже готовый код — в том числе собственный, написанный два месяца назад и благополучно за это время забытый. Так, сокращаем TTM.
К тому же, если мы плохо проектируем, плохо пишем, плохо автоматизируем, плохо доставляем, структура начинает тормозить, возникают ошибки. И приходят бизнес, лиды, тестировщики с претензиями, баг-репортами и доработками.
Чистый и юзабельный код не ценность — а обязанность. И чем он однообразнее, скучнее и проще тем проще нам автоматизировать процессы.
Лидам
Лиды, как и разработчики, отвечают за качество готового продукта. И им чистый код помогает быстрее проводить ревью, переключаться между задачами и следить за соблюдением соглашений.
Бегите из команды, если ваш техлид говорит: «Чистый код — это миф. А те, кто пишут про него книги, статьи и доклады, не работают, а выдумывают теорию, которая на практике неприменима».
Бизнесу
Бизнесу доклады про эстетику и красоту кода неинтересны. Бизнесу важна скорость появления фичей и отсутствие багов.
Так что чем быстрее работает команда, чем больше качественных продуктов и доработок она выпускает, тем больше бизнес может заработать.
Хорошо, и как тогда написать чистый код?
Сперва почитать хорошие книги
Да, лень — но надо. Всё хорошее и «правильное» уже придумано, и чтобы писать код грамотно, необязательно 5 лет изобретать велосипеды, как это делал я.
Рекомендую читать Роберта Мартина, Владимира Хорикова, Джошуа Блоха, Скота Влашина, Стива Макконнелла и стремиться к профессиональной простоте кодирования. Важно: старайтесь читать книги в оригинале.
Чистый код работает медленно, но он все равно нужен
Если вы еще не в курсе, то приготовьтесь: в Twitter в области программирования/разработки ПО происходит нечто интересное. Все началось с одного из видеороликов Casey Muratori (Кейси Муратори) о производительности программирования. Ролик называется “Clean Code, Horrible Performance” (“Чистый код, ужасная производительность”). Кейси критикует современное ПО, эффективность которого менее 1/20. Это обоснованное беспокойство, поскольку неэффективность является причиной того, что мы не можем получить качественные продукты. Затем в разговор вмешивается Uncle Bob (Дядя Боб), т. е. Robert C. Martin (Роберт К. Мартин), который провел с Кейси очень детальное и познавательное обсуждение с использованием GitHub. Дискуссия продолжается и по сей день. К тому же она породила тему в Hacker News.
Чистый код действительно медленный
Я посмотрел видео и считаю, что Кейси, хотя и прав, не совсем точно обрисовал картину в целом. Он утверждает: полиморфизм и принцип единственной ответственности (если ему слепо следовать) — это тормоза (а значит, зло), что в какой-то мере верно. К примеру, полиморфизм чреват затратами на поиск в координирующей таблице и перенаправления. Не говоря уже о том, что функция и/или данные будут разбросаны, а не находиться рядом друг с другом, что приведет к пропускам нужных данных в кэше CPU L1/L2. То же самое касается и принципа единственной ответственности. Распаковка функции на несколько частных вспомогательных функций также может привести к пропуску данных в кэше. К этому же приводят и встраиваемые функции. К сожалению, полиморфизм является основой SOLID — 5 ключевых принципов чистого кода:
Производительность действительно важна
Эффективность и производительность критически важны для быстродействующих программ, таких как игры и встраиваемые системы. Никто не захочет покупать игру с частотой 10 кадров в секунду или тормозящее встраиваемое устройство. Эффективность и производительность также важны для бэкендов, обеспечивающих максимально быструю передачу контента на сервер.
Например, неэффективное приложение сделает устройство медленным и горячим и будет потреблять больше энергии, чем должно. Неэффективный бэкенд может привести к увеличению затрат на ядра и/или память или дополнительные сервисы. Полагаю, что программисту всегда нужно думать о будущем своих проектов, поскольку стартапы не могут тратить больше, чем нужно. Операционные расходы будут меньше, если вы сможете создать эффективный код.
Существует множество способов сделать код производительным.
Но чистый код тоже важен
Однако есть и другие пути, кроме достижения только производительности. Я видел много примеров плохо написанного и нечитаемого кода. И большинство из них — из моего опыта работы разработчиком игр. Разработчики игр печально известны тем, что стремятся к производительному коду. Потому что это позволяет добиваться большего контентного наполнения, качества, количества трисов, текстур и т. д., чтобы игра выглядела лучше без ущерба для FPS.
Но я считаю, что если производительность становится приоритетом, то в итоге можно получить такой же глючный конечный продукт, как движок Source Engine. Печально известный дефект “coconut.jpg”, вероятно, является результатом нарушения принципа единственной ответственности. Если вы изменяете одну часть кода, это может повлиять на другую часть, которая не имеет никакого отношения к той, над которой вы работаете. Это произошло у меня с Blackberry Messenger. В BBM iOS есть класс BBMessage. Нам запрещено трогать этот класс без особой необходимости. А если все же приходится работать с ним, то нужно быть осторожным, потому что это может привести к поломке других вещей.
Высокопроизводительный код не самый простой для чтения и сопровождения. Если такой вам попадется, вы в этом убедитесь. Попробуйте, к примеру, понять суть кода, созданного на алгоритме Fast Inverse Square Root для видеоигры Quake. Хотя не весь этот код непонятен, некоторые места в нем — сплошной мрак.
Чистый код и другие современные принципы программирования в большей степени ориентированы на процесс разработки, а не на производительность. Они используются для сокращения времени программирования, а не для повышения производительности. Их цель — сделать код более читаемым, тестируемым, надежным, расширяемым и сопровождаемым. Иногда (или чаще всего) за счет производительности. Причина в том, что процессор и память обходятся дешевле, чем время разработки и сопровождения. Поэтому рекомендуется добавлять мощность процессора и объем памяти, чтобы компенсировать недостаток эффективности, создаваемый чистым кодом.
Должен сказать, что когда я переквалифицировался из разработчика игр в разработчика мобильных приложений (в основном для iOS) в KMK Labs/Vidio.com, то испытал настоящий шок. Парадигма требований в новом офисе оказалась совершенно другой. Мне было довольно трудно адаптироваться к приоритету чистоты и сопровождаемости кода над производительностью. Скорость процесса разработки мобильных приложений важнее, чем конечный продукт (хотя и в приемлемом смысле). Поэтому мне пришлось изучать чистый код, SOLID, чистую архитектуру, TDD, MVVM, экстремальное программирование и т. д.
Зато результат моих усилий оказался колоссальным. Процесс разработки стал лучше и быстрее, сократилось количество ошибок. Члены команды могли входить в класс и выполнять свою работу, не беспокоясь о влиянии на рабочий процесс коллег. Код стал легко читаться, что избавило нас от умственного переутомления. У нас появилась возможность легко расширять функции и так же легко тестировать их.
Так что же делать?
Главное — быть прагматичным и гибким. Нужно заботиться как о производительности, так и о чистоте кода. Чистота, читаемость, расширяемость и надежность кода важнее, чем производительность. Поскольку большинство процессов разработки не столь ресурсоемки, можно допустить некоторое снижение производительности и писать более структурированный код. Это работает, если не принимать во внимание нагрузку, которую код будет оказывать на устройство пользователя: как он будет разряжать батарею, нагревать девайс за секунду и т. д.
Но надо также понимать, какая часть приложения нуждается в производительности. Обычно она находится в самом глубоком слое приложения, где вызывается сотни/тысячи и сотни тысяч/миллионы раз. При ее наличии стоит отказаться от чистого кода в пользу тех или иных методологий, повышающих производительность. Поэтому я бы посоветовал разработчикам придерживаться (по возможности) следующих рекомендаций.
Заключение
Напоследок приведу цитату Роберта К. Мартина (он же Дядя Боб), взятой из его беседы с Кейси Муратори:
Если вы пытаетесь выжать каждую наносекунду из батареи GPU, то чистый код, скорее всего, не для вас. По крайней мере в самых трудоемких из ваших глубоких внутренних циклов. С другой стороны, если вы пытаетесь выжать каждый человеко-час производительности из команды разработчиков программного обеспечения, то чистый код может стать эффективной стратегией для достижения этой цели.
Читайте нас в Telegram, VK и Дзен