— Эх, может стоит всё бросить и снова заняться лапшой…

— Бросить – не бросить, лапша – не лапша. Тебя слишком занимает, что было, и то, что будет. Мудрецы говорят: «Прошедшее – забыто, грядущее – закрыто, настоящее – даровано». Поэтому его и зовут настоящим.

Кунг-Фу Панда.

Ещё будучи студентом-ACM-щиком, я понял, что теория без хорошей практики как минимум бесполезна. А как максимум – буквально «выжигает» тебя изнутри, потому что ты не можешь отбить затраченные усилия и получить заслуженный дофаминчик. Хорошая практика – это не бросание человека в воду в надежде, что он сам выплывет. Это про понимание типичных «граблей» на которых можно крепко застрять, и помощь в нужный момент на протяжении всего пути. Именно поэтому хороший специалист != хороший учитель.

В завершающем эпизоде курса поговорим о том, как перейти от теории к практике.

End-to-end примеры

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

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

«99 Bottles of OOP». Sandi Metz

Именно эта книга вдохновила меня на повторный заход в тему рефакторинга, который привел к написанию этой серии статей.

В ней рассматривается забавная задачка по генерации текста песни «99 Bottles», которая выглядит как рекурсивная процедура, но с приколами.

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

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

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

«Gilding the Rose: Refactoring-Driven Development». Kevlin Henney

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

В этом докладе берётся ката рефакторинга «Gilded Rose» по мотивам игры «World of Warcraft», в которой нужно добавить новую функциональность в хитрый алгоритм управления инвентарём таверны, продающей магические предметы. Исходный код специально запутан, чтобы разработчик сперва разобрался в нём, отрефакторил, а уже потом легко добавил изменение. И, конечно же, к изначальному коду нет тестов 😄

Автор по шагам показывает, как бы он стал действовать.

Тулинг

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

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

With Great Power Comes Great Responsibility

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

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

Keep Calm and Refactor

Я считаю, что работа должна не только приносить деньги, но и удовольствие. Это залог профессионального долголетия.

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

Удачи!