Рефакторинг
Рефакторинг — это контролируемый процесс улучшения кода, без написания новой функциональности. Результат рефакторинга — это чистый код и простой дизайн.
Грязный код является не только результатом лени и невежества, но и побочным продуктом частых изменений в процессе разработки.
Чистый код — это код, который просто читать, понимать и поддерживать. Чистый код улучшает предсказуемость разработки и повышает качество продукта.
Пошаговые изменения, сопровождаемые частыми запусками тестов — это то, что делает процесс рефакторинга эффективным и безопасным.
Запахи кода — это индикаторы проблем, на которые нужно обращать внимание при рефакторинге. Часто их легко найти и исправить, но иногда они предвещают о глубинных проблемах с кодом.
Техники рефакторинга описывают конкретные методы борьбы с грязным кодом. Большинство рефакторингов имеет как достоинства, так и недостатки. Поэтому любой рефакторинг должен быть мотивирован и обдуман.
21 запах кода, 66 рефакторингов
Живые примеры на Java/C#/PHP
Никаких лимитов по времени
It’s okay to write dirty code
Писать грязный код — нормально
Многие разработчики считают, что им нужно писать чистый код. Они хорошие разработчики, если пишут чистый код и паршивые, если они этого не делают.
Я чувствую то же самое. И стараюсь делать мой код максимально чистым.
Но эта попытка писать чистый код на самом деле тормозит большинство из нас. Мы учимся медленнее. Мы делаем меньше. И в результате мы вносим меньший вклад в этот мир.
Я хочу подчеркнуть, что писать грязный код — это нормально. Я даю разрешение себе и вам писать грязный код в этой статье.
Когда писать грязный код
Есть несколько случаев, когда можно написать грязный код:
Второй пункт звучит противоречиво, да? Мы доберемся до этого. Обещаю.
Пишите грязный код, когда вы в тупике
Когда вы в тупике, любой прогресс лучше, чем отсутствие прогресса. Это относится ко всему в жизни, даже к кодингу.
Например, я обычно испытываю трудности, когда пытаюсь писать статьи. Я чувствую себя некомфортно, потому что подвергаю себя цензуре. Эти мысли пришли мне в голову, когда я писал эту статью:
Написание грязного кода в равной степени страшно, потому что мы, разработчики, гордимся написанием хорошего и чистого кода. Мы носим это как знак чести. Если мы не пишем чистый код, мы паршивые разработчики.
Мы тупим, потому что сосредоточены на попытках писать чистый код. Наши идеи не текут.
Думайте о мыслях как о воде в кране.
Если вы хотите, чтобы мысли текли, вы должны включить кран. Если вы подвергаете себя цензуре, вы вставляете большой палец в кран.
Попробуйте включить кран, вставив в него большой палец. Что происходит? Вода застревает. Вы не дадите ни одной из ваших мыслей вытечь.
Если вы хотите сделать что-то стоящее, вам нужно перестать подвергать себя цензуре. Это запустит процесс создания. Это позволит воде течь.
Затем, когда вы включите кран, холодная вода неизменно потечет первой. Неважно, как давно вы включили нагреватель. Это потому, что холодная вода уже готова вытечь. Горячая вода пойдет только после того, как холодная вода закончится.
Сначала вы должны выбросить свои плохие идеи, потому что хорошие идеи не придут, пока все плохие не исчезнут.
Хорошие идеи появляются во время работы. Они всплывают, только если вы перестаете подвергать себя цензуре.
Догадываетесь как я пришел к этой аналогии холодной/горячей воды?
Я начал писать эту статью со слов «Я цензурирую себя прямо сейчас …». Посмотрите, что вы сейчас читаете. Вы даже не осилили половину, и вы хотите читать дальше. Да? 🙂
Пишите грязный код, когда вы хотите написать хороший код
Как вы можете писать грязный код, чтобы писать хороший код? Это звучит противоречиво.
Хороший код происходит от плохого кода. Так же, как хорошее письмо происходит от плохого письма.
Вы можете высказать свои мысли (без редактуры) в своем блоге. Это просто. Но это будет плохая писанина. Она будет содержать всякую не относящуюся к делу информацию.
Хорошее письмо происходит от очистки плохого письма. Это называется редактированием. Именно здесь мы режем и сжигаем все, что не помогает нам донести сообщение, которое мы хотим донести.
Хороший код тоже происходит от редактирования. За исключением того, что мы называем этот процесс рефакторингом: изменением кода так, чтобы написанное не влияло на его поведение.
Вы должны написать плохой код, чтобы получить творческие соки. Затем вы должны отрефакторить его, чтобы другие могли его понять.
Этот процесс занимает время. Это требует терпения.
Когда вы хотите сделать что-то быстро.
Разработчики имеют привычку добавлять функционал, который не нужен, в нашем коде. Например:
В этих трех примерах я говорил об использовании различных функций JavaScript, когда мы пишем код.
Когда мы что-то делаем, то часто добавляем больше сложностей, чем нужно. Например, когда я делал таймер обратного отсчета для страницы продаж Learn JavaScript, я добавил поддержку часовых поясов для всех часовых поясов в мире… хотя мне был нужен только PST.
Я сделал это, потому что я хотел выпустить таймер обратного отсчета в качестве библиотеки для других. Но я так и не выпустил его. Я часами изучал часовые пояса, в то время как в моем списке задач были более насущные вопросы.
В начале нормально писать плохой код. Это мешает вам писать что-то слишком навороченное и помогает делать вещи быстрее.
Как писать хороший код (последовательно и быстро)
По сути, процесс написания хорошего кода сводится к:
Процесс рефакторинга критичен, если вы хотите писать хороший код последовательно и быстро. Это перепрошивает ваш мозг. Продираясь через убер-паршивый код, вы начнете видеть как писать лучший код с самого начала. Вы также научитесь определять, как выглядит хороший код.
Сворачиваемся
Если вы хотите писать хороший код, мы должны сначала написать плохой код. Пусть паршивость изольется из тебя и что-то хорошее последует за ней.
Это рискованно и страшно. Но это то, что мы должны сделать.
Написание этой статьи позволило мне писать грязный код (а также публиковать грязный код). Я надеюсь, что это и вам позволит писать грязный код.
Вот что улучшит положение дел, когда вы впервые напишите дерьмовый код. 🍻.
Прощай, чистый код
Мой коллега только что записал в репозиторий код, над которым работал целую неделю. Мы делали тогда графический редактор, а в свежем коде были реализованы возможности по изменению фигур, находящихся в рабочем поле. Фигуры, например — прямоугольники и овалы, можно было модифицировать, перемещая небольшие маркеры, расположенные на их краях.
Но в нём было много повторяющихся однотипных конструкций. Каждая фигура (вроде того же прямоугольника или овала) обладала различным набором маркеров. Перемещение этих маркеров в разных направлениях по-разному влияло на позицию и размер фигуры. А если пользователь, двигая маркеры, удерживал нажатой клавишу Shift, нам, кроме того, надо было сохранять пропорции фигуры при изменении её размера. В общем — в коде было много вычислений.
Код, о котором идёт речь, выглядел примерно так:
Меня все эти вычисления, все эти почти одинаковые строки, сильно зацепили.
У меня появилась идея.
Можно избавиться от дублирующихся конструкций, по-другому сгруппировав код. Например — так:
Затем можно прибегнуть к композиции и собрать из этих базовых методов то, что нужно:
То, что у меня получилось, было в два раза меньше того, что написал коллега. В моём варианте программы полностью отсутствовали повторяющиеся фрагменты! Чистейший код. Если нужно было изменить поведение системы, относящееся к конкретному направлению, или к конкретной фигуре, можно было сделать это в одном месте, а не переписывать несколько методов.
Была уже поздняя ночь (я увлёкся). Я влил результаты рефакторинга в ветку master и отправился спать, гордый тем, как я «причесал» неопрятный код коллеги.
Следующее утро
…прошло не так, как ожидалось.
Руководитель пригласил меня на разговор за закрытыми дверями, в ходе которого вежливо попросил меня откатить мои изменения. Меня это потрясло. Ведь старый код — это же сплошной бардак. А мой код был чистым.
Я нехотя исполнил просьбу, но мне понадобились годы для того, чтобы понять правоту руководителя и коллеги.
Это — одна из ступеней развития программиста
Зацикленность на «чистом коде» и стремление к удалению дубликатов — это одна из ступеней развития программиста, через которую проходили многие из нас. Когда мы не чувствуем уверенности в своём коде, возникает желание привязать наше восприятие самооценки и профессиональной гордости к чему-то такому, что можно измерить. Набор строгих правил линтинга, схема именования сущностей, структура файлов проекта, минимизация дублирующегося кода.
Нельзя автоматизировать борьбу с повторяющимся кодом, но эта борьба, совершенно точно, становится легче с практикой. Обычно после каждого изменения можно сказать о том, больше или меньше одинаковых конструкций стало в проекте. В результате избавление от дублирующихся фрагментов программы воспринимается как улучшение некоего объективного показателя качества кода. И, что хуже, это искажает самосознание программиста: «Я из тех, кто пишет чистый код». Это так же сильно влияет на человека, как и любой другой род самообмана.
Как только программист узнаёт о том, как создавать абстракции, он вполне может этим увлечься. Он, видя дублирующийся код, будет находить абстракции там, где их нет. А после нескольких лет такой практики дублирующийся код будет обнаруживаться абсолютно везде. Абстрагирование станет новым талантом программиста. Если кто-то скажет ему, что абстрагирование — это добродетель, он это примет. И он начнёт осуждать тех, кто не преклоняется перед «чистотой».
Теперь я понимаю, что у моего «рефакторинга», и у того, как я к нему подошёл, было два серьёзных недостатка:
Я, конечно, о таких вещах тогда не думал. Я много размышлял о том, как выглядел код — но не о том, как он развивался вместе с командой, состоящей из людей, которым не чуждо ничто человеческое.
Программирование — это путь. Подумайте о том, как далеко вы продвинулись от написанной вами первой строчки кода, до того места, где находитесь сейчас. Я полагаю, что вы, в первый раз извлекая функцию или подвергая класс рефакторингу, с восхищением наблюдали за тем, как эти приёмы упрощают сложный код. Если вы чувствуете гордость за своё дело, то у вас появится стремление к преследованию чистоты кода. Поддайтесь на некоторое время этому стремлению.
Но не останавливайтесь на этом. Не становитесь фанатичным приверженцем чистого кода. Чистый код — это не цель. Это — попытка как-то осмыслить огромную сложность систем, с которыми мы имеем дело. Это защитный механизм, который программист применяет тогда, когда ещё не уверен в том, как некое изменение повлияет на кодовую базу проекта, но ищет ориентиры в море неизвестности.
Пусть идея чистого кода станет вашим ориентиром. А потом — отпустите эту идею.
Уважаемые читатели! Как вы относитесь к «чистому коду»?
Грязный, чистый, устремлённый
Грязный
Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?
Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код? 
Давайте сначала разберёмся с определениями.
Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.
Да, мы научились определять общие закономерности, скажем, в лицах, которые считаются красивыми. Но готовы ли мы дать чёткое определение красоте? Думаю, нет.
Эта аналогия не вполне корректна (как и большинство аналогий), но примерно передаёт ощущения, возникающие при работе с кодом. Неважно – чужим ли, своим ли, написанном пару месяцев назад и уже прочно забытым. Код либо нравится, либо нет. Он либо красив, чист и приятен – либо волосат, уродлив и дурно пахнет.
И, конечно же, у каждого есть свои критерии «красоты кода». Свой, так сказать, вкус.
Но, тем не менее, есть какие-то общие точки, о которых если и спорят, то вяло и соглашательски. Не о сути, а об обрамлении.
Давайте попробуем их перечислить.
| Легко читается и понимается | Запутан, неочевиден, трудно понимаем |
| Легко поддаётся изменениям | Закостенел в своих внутренних связях; изменить что-либо стоит неимоверных усилий и жертв |
| Может быть расширен, либо встроен куда-нибудь в виде отдельного модуля | Для расширения требует переписывания, для встраивания – обёрток |
| Поддаётся автоматизированному тестированию | Может быть протестирован, лишь как «чёрный ящик» |
Конечно, можно начать спор о «читабельности» или «понимабельности» кода. Это совсем не формализованные термины.
Но и они интуитивно понятны: если, например, кто-то станет доказывать окружающим, что он привык писать всю программу в виде одной-двух огромных функций, «которые делают всё», а решение тех же задач при помощи хотя бы разбиения на большое количество небольших процедур и функций для него непонятно – ему намекнут, что надо бы подтянуть азы.
А желательно – основательно поковырять ООП и стараться инкапсулировать логику в отдельных классах, чтобы не приходилось напрягать головной мозг ни разбором огромных «портянок» кода на десятки экранов, ни запутанными связями процедур и функций, которые к тому же (omg) оперируют кучей глобальных переменных.
Примерно так же дело обстоит и с остальным: конечно, даже среди приведённых 4х пунктов есть взаимоисключающие параграфы (легко читаемый код далеко не всегда будет легко изменяемым, лёгкость расширяемости может конфликтовать с автоматизацией тестирования и т.п.) – но в целом обстановка понятна.
В принципе, руководствуясь этими пунктами (усиливая или ослабляя каждый из них в зависимости от требований конкретных задач), можно легко отличить грязный код от чистого.
Хотя лучше всего, если это происходит само собой, без чересчур подробного анализа. Когда есть «нюх», позволяющий быстро понять, что код грязен и воняет.
Чистый
Теперь давайте всё-таки попробуем разобраться – зачем же он вообще нужен, этот чистый код? И так ли уж плох код грязный и волосатый?
Ну, для начала нужно сказать: it depends.
Бывают моменты, когда написать «быстро и грязно» куда важнее, чем «долго и чисто». Хотя нужно отметить, что «грязно» далеко не всегда означает «быстро». Бывает, что ровно наоборот. 
В общем, давайте попробуем рассмотреть более-менее жизненные примеры и постараться понять в каждом случае – когда грязное кодирование бывает оправдано, а когда абсолютно недопустимо.
Например
На сервере что-то происходит, логи пишутся – но они огромны, и читать их некому. Нужно написать небольшую утилитку, которая прочитает логи, вытащит оттуда какие-то численные данные и представит их в виде таблицы. На входе – лог-файл, на выходе – текст с цифирями.
Такую задачу вполне можно написать как угодно грязно – лишь бы утилька работала, а написание не заняло много времени. Ведь мы решаем здесь одну сиюминутную задачу.
Решить же задачу долговременную куда как лучше, изменив систему регистрации ошибок (писать те же численные данные в базу, например).
То есть утилиту эту в идеале используют один-два раза, после чего выкинут. Чистота кода здесь совершенно не важна.
Другой пример
Сервер иногда падает, почему – никто не знает. Анализатор логов позволил понять, что падение вызывается большим количеством однотипных запросов, приходящих с вполне определёнными значениями параметров, и эту ситуацию необходимо срочно воспроизвести.
Нужно написать небольшую утилитку, которая будет в точности воспроизводить это поведение.
Казалось бы – всё один в один повторяет первый пример. Однако здесь возникает вопрос: раз процесс тестирования не предусматривает воспроизведение подобных ситуаций, то не возникнет ли необходимость дальнейшего развития этой утилиты в качестве инструмента тестирования? Не станет ли она самостоятельным приложением, которым пользуются регулярно?
Если ответ – «да» или хотя бы «возможно», то стоит уделить немного внимания тому, чтобы код был понятен хотя бы самому разработчику через месяц-другой, и в то же время позволял бы как-то себя расширять.
К примеру, добавлять другие последовательности запросов, конфигурировать адрес сервера и число запросов, значения ключевых параметров и т.д.
Это ненамного замедлит разработку утилиты «здесь и сейчас» — зато, когда вновь встанет вопрос о воспроизведении последовательности запросов на сервер – утилита будет тут как тут и потребует минимального допиливания; а главное – минимального времени на вспоминание, что там к чему.
Третий пример
Разработка программного модуля для основного программного продукта компании, уже несколько лет успешно развивающегося на рынке.
Казалось бы – модуль изолирован, интерфейсы взаимодействия с другими модулями определены. «Кручу-верчу, говнокод писать хочу». Но тут возникает серьёзное «НО».
Что будет с этим модулем через полгода? Год? Потребует ли он поддержки? Изменения? Расширения функционала? Возможно, в итоге разовьётся в отдельный продукт?
Если хотя бы на один вопрос можно дать хотя бы ответ «вероятно» — то говнокодить, увы и ах, строго не рекомендуется.
Но это не весь список вопросов. А кто будет работать с этим модулем через два-три года? Тот, кто его писал, или кто-то другой?
Если кто-то другой – то ведь ему придётся в этом коде разбираться.
И если это будет плохой, негодный код – то либо плакать и жевать кактус, проклиная создателя, либо выкинуть всё на помойку и переписать заново, получая при этом поджопники от начальства за срыв сроков.
Если же работать с этим кодом будет сам разработчик – то тем более. Да он через полгода уже не будет помнить: что, где и как работает! Ему придётся разбираться в этом коде так, как будто код совершенно чужой. Не враг же он самому себе?
Четвёртый пример
Разработка приложения (сайта, базы данных с простейшим интерфейсом – чего угодно) под заказ в сжатые сроки за небольшие деньги.
С одной стороны – code and forget, можно писать что угодно и как угодно, лишь бы работало.
С другой стороны – а что, если этот заказчик через месяц вернётся и попросит за дополнительные деньги что-то добавить или переделать? Будем плакать, колоться, но жевать кактус? Откажемся от заказа?
А что, если он обратится к другому разработчику (компании), получит негативный feedback о качестве исполнения проекта, и больше никогда не вернётся к «злым говнокодерам», да ещё своим друзьям отсоветует?
Я уже не говорю о таких вещах, как качество кармы и память потомков.
Пятый пример
Самый жёсткий случай абсолютного недопущения говнокодирования.
Мне сложно даже представить себе какие-либо аргументы в пользу осознанного выбора плохого кода в случае командной разработки.
Да что там говорить – один говнокодер способен принести вреда больше, чем вражеский агент в тылу врага!
Если команда не изолирует его, бросив на написание никому не вредящих, ни с чем не связанных, абсолютно левых утилит и мини-приложений – то его продуктивность в команде будет не то, что нулевой – она будет отрицательной!
Необходимость читать, вникать, исправлять, матерясь – а в итоге выкидывать и переписывать заново – мало того, что занимает больше времени, чем самостоятельная разработка хорошего кода, так ещё и портит общую атмосферу в команде и минусует мораль всех разработчиков, вынужденных сталкиваться с говнокодом не по своей вине.
А тестирование? Сопровождение? Расширение функционала??
Я мог бы написать ещё пару хулительных абзацев – но нет. Не могу.
Клавиатура выпадает из ослабевших пальцев при мысли о том, сколько вреда может принести говнокод в команде…
Это ужасно… ужасно…
Устремлённый
Итак, мы примерно понимаем, что такое грязный код и чем он плох. Мы всё ещё не вполне понимаем, что такое чистый код, но ощущаем его необходимость.
Почему же он всегда есть, этот грязный код, почему он всегда присутствует и портит жизнь всем – в том числе и своим авторам?
На мой взгляд, всё предельно просто: писать чистый код – это искусство, это сверхспособность, развить которую в себе может практически каждый; но далеко не каждый даже задумывается о необходимости её развития.
Не говоря уже о том, чтобы получать представление о сиём предмете в профильном университете или на профильных курсах – там дают лишь самые верхушки «нужных» технологий, платформ и языков – немногие вообще уделяют специальное внимание улучшению собственных навыков чистого кодирования.
Конечно, с течением времени, если у разработчика развит «нюх на грязый код», он неизбежно начинает писать всё чище и лучше.
Он читает на досуге интересные статьи, он изучает паттерны проектирования. Но бывает, что он делает это потому, что ему интересно – а не потому, что осознаёт необходимость развития своих навыков написания чистого кода.
И при этом, в идеале, он всегда ощущает, что его код всё ещё недостаточно хорош, что ему ещё далеко до совершенства. И пусть его сегодняшний «говнокод» на голову выше самого лучшего, что он писал два-три года назад – всё равно есть куда расти.
В связи с этим мне вспоминается один интереснейший разговор с моим коллегой, которому, как и мне, довелось провести не одно собеседование с кандидатами на должность разработчика – возможно, даже больше, чем собеседований в качестве такового кандидата.
Мы говорили о молодых программистах и о том, какие их качества более всего свидетельствуют о потенциале профессионального развития.
В итоге всё свелось к нескольким простейшим пунктам, в порядке важности:
1) Хорошо работающая голова (поэтому у нас всегда есть задачки на логику)
2) Высокий уровень самокритичности (поэтому всегда есть задачки на написание кода и поиск ошибок в нём)
3) Интерес к программированию (важен в меньшей степени, задачками не определяется в принципе)
То есть понятно, что если голова работает плохо – то разработчиком не станешь при всём желании и старании. Однако, если она даже золотая и светится от разумности – это ещё далеко не гарантия.
Частенько бывает, что молодой специалист, видя, как легко ему всё даётся (особенно – в сравнении с большинством своих одногруппников, сокурсников, просто ровесников) начинает искренне считать, что круче бывают только яйца.
И, хотя наверняка к этому есть некоторые основания, но ЧСВ зашкаливает настолько, что в итоге в один прекрасный момент он просто перестаёт развиваться, считая, что «я и так умный, а кто пытается это оспорить – тот дундук».
И хорошо, если при этом у него остаётся живой, острый интерес к своей работе. Если он продолжает читать статьи и книги «потому, что интересно». Тогда у него остаётся небольшой шанс не застыть, а продолжать развиваться.
И, наконец, бывает, что парень (или девушка – что встречается гораздо реже, уж извините меня за эту неполиткорректную реальность) и умный, и самокритичный – редко остаётся довольным своим кодом и вообще считает, что ему ещё расти и расти – в какой-то момент теряет (хорошо, если не полностью) интерес к профессии, начинает меньше читать, меньше экспериментировать.
Начинает чаще выполнять задачи «строго по спецификации», желательно – уже знакомые задачи, из знакомых сфер. Меньше уделять внимания новым языкам, платформам, концепциям.
И становится вполне хорошим, годным специалистом. Зачастую даже не очень узким, а относительно многопрофильным. Вполне себе уважаемым.
Но так и не достигает вершины своего изначального потенциала.
И лишь в очень редких случаях умный, способный, в высшей степени самокритичный молодой человек с горящими глазами растёт ежегодно, ежечасно – и в итоге становится звездой. Бывает, что очень быстро становится «локальным светилом» – но не застывает, не ограничивается этим, а продолжает расти, развиваться, совершенствоваться.
Ах, как прекрасна эта картина – так и хочется смахнуть несуществующую слезу! Как прекрасен он, этот устремлённый в бесконечность молодой человек, своим духовным порывом приподнимающий самые небеса, в которые нацелен его всепроникающий взгляд!
Как счастливы люди, окружающие его, когда они понимают, сколь величествен его путь, и делают, в свою очередь, хоть два-три шага рядом с ним. Приближаясь хоть на волос к той прекрасной бесконечности возможностей, куда летит он на всех парах!
Как хочется видеть побольше горящих глаз, светлых умов, обращённых в эту бесконечность. Как хочется хотя бы немного помочь этим атлантам на их пути, хоть на мгновение поддержать, подтолкнуть ввысь, приблизить их к этой недостижимой и прекрасной цели.
И остаться внизу, с щемящей радостью наблюдая, как пронизывают они пространство и время в своём стремлении.
И знать, что хотя бы немного, хотя бы чуть-чуть – помог, поддержал, а не стоял в стороне, застывший в своём упоении собственной важностью, не бросал презрительных взглядов – «пхе… молодёжь..»
