Розробка програмного забезпечення може здаватися публічним виступом. Інтернет винагороджує запусками, скриншотами та пунктами в списках змін (changelog). Тому, коли розробник витрачає цілий робочий день на проєкт і не має нічого видимого, щоб це показати, інстинктивним здається вважати цей день згаяним. Останній dev log платформи Food Blog Platform доводить протилежне. Там не було нових рецептів для відображення, не було редизайну карток чи додаткових кнопок для користувачів. Лише код, який розбирали, вивчали та збирали заново, зробивши його кращим, ніж він був.
Це і є та невидима робота, яка підтримує довгострокові проєкти життєздатними.
Функції приносять славу; рефакторинг підтримує стабільну роботу
Коли ви підтримуєте платформу для фуд-блогів, зовні все виглядає просто. Користувачі публікують рецепти, завантажують фото та переглядають контент за категоріями. Проте під капотом ви маневруєте між конвеєрами обробки зображень, зв'язками в базі даних між інгредієнтами та інструкціями, пошуковими індексами та рівнями кешування. З часом швидкі виправлення накопичуються. Функція-помічник, скопійована у три різні файли. Запит до бази даних, який мав сенс для десяти постів, але починає гальмувати, коли їх стає тисяча. CSS, який був організованим, поки п'ять екстрених патчів не перетворили його на лабіринт.
Рефакторинг означає пряме протистояння цьому безладу. Це може означати об'єднання дубльованої логіки, щоб форма редагування рецепта та панель адміністратора використовували один і той самий рівень валідації замість підтримки паралельних версій. Це може означати спрощення процесу обробки зображень, щоб процедура стиснення запускалася один раз, а не щоразу при перезавантаженні сторінки. Або ж це може бути реструктуризація кодової бази, щоб подальше додавання нового типу контенту не потребувало пошуку по шести непов'язаних директоріях.
Нічого з цього не відображається в інтерфейсі користувача. Відвідувач сайту не побачить банера з написом «запит оптимізовано» або «компоненти розв'язано». Але він відчує це, коли сайт завантажуватиметься швидше. Він помітить, коли нова функція з'явиться через три дні після запиту, а не через три тижні. Розробник не додав сьогодні нових можливостей. Він розчистив шлях, щоб ці можливості можна було додавати без боротьби з кодовою базою.
Чистий код — це інвестиція проти майбутніх невдач
Кожен проєкт, що триває довше місяця, накопичує тертя. Ви створюєте швидкий прототип, щоб протестувати ідею. Потім з'являються реальні користувачі. Потім вам потрібен рівень автентифікації, потім черга модерації, а потім — мобільний макет. Кожне з цих доповнень «прикручується» до тієї структури, яка вже існує. Без регулярного обслуговування архітектура починає нагадувати будинок, де кожна нова кімната була спроєктована іншою людиною, яка ніколи не бачила загального плану.
Технічний борг — це не провал дисципліни. Це природний побічний продукт компромісів, необхідних для випуску реального продукту. Небезпека не в тому, що ваш код недосконалий. Небезпека в тому, щоб залишати його недосконалим так довго, що зміна однієї змінної ламає три непов'язані функції. Ви починаєте боятися торкатися рядка пошуку, тому що минулого разу, коли ви спробували, зламалася система тегів. Ви відкладаєте додавання віджета планувальника харчування, бо знаєте, що схема бази даних перетворилася на вузол, на розплутування якого підуть години.
Витратити день на рефакторинг — це все одно що погасити цей борг до того, як відсотки вас переповнять. Це запобігає перетворенню малих проблем на великі. Коли Food Blog Platform зрештою додасть свою наступну велику функцію, розробнику не доведеться «танцювати навколо» крихкого коду. Він напише нову логіку, підключить її до чистого інтерфейсу і піде далі. У цьому і полягає окупність інвестицій.
Маленькі кроки, справжнє навчання
Навколо розробки програмного забезпечення існує міфологія, ніби прогрес — це геніальні прориви та марафонські сесії кодування, які переписують усе за одну ніч. Більшість працюючих розробників скажуть вам, що це фантастика. Справжній прогрес виглядає як diff у вівторок після обіду, де три функції стали коротшими, одна зайва залежність була видалена, а заплутану назву змінної змінено так, щоб наступний читач дійсно розумів, що вона робить.
Dev log Food Blog Platform ідеально передає цей ритм. Розробка програмного забезпечення — це про маленькі, послідовні покращення. Ви вчитеся на кожному виклику. Можливо, сьогодні викликом було розуміння того, чому певний модуль став настільки залежним від іншого. Можливо, ви усвідомили, що скорочення шляху, зроблене два тижні тому, вже почало коштувати більше часу, ніж заощадило. Кожен коміт робить проєкт кращим, навіть якщо цей коміт видаляє більше, ніж створює.
Цей підхід також допомагає зберегти вашу мотивацію. Масштабне переписування коду є виснажливим і ризикованим. Воно створює нові помилки, вирішуючи старі. Інкрементальний рефакторинг, виконаний