Legacy-фобія

Колеги, у мене для вас є чудова новина, ми отримали чудовий проект, його кілька років писали невідомі нам розробники, адреса яких ми навряд чи дізнаємося (щоб «поділитися зворотним зв'язком»), писали дуже давно і не відомо під ніж, і нам треба його підтримувати і розвивати. Проект зараз знаходиться на піку своєї продуктивності і ми скоро упремося, будь неакуратні зміни можуть його покласти, але ми будемо його розвивати. Ура!

Погодьтеся, дивно звучить? Як марення хворого на голову програміста. Хто ж любить legacy? Це ж завжди говнокод (адже тільки ми самі пишемо ідеально), в ньому повно багів (а ми самі пишемо без помилок), жахливі рішення (адже тільки ми самі вибираємо відповідну архітектуру), і майже завжди його складно читати (адже тільки ми самі пишемо зрозуміло і красиво).



Я знайомий з цією страшилкою стільки, скільки взагалі знайомий з областю розробки. Лякання legacy-кодом — це універсальна страшилка для програмістів, як для дітей історія про сірого вовчка, який прийде і вкусить за бочок.

Тому хотілося б трохи поламати стереотипи щодо legacy, нехай не все, але хоча б частини розробників, і дати розуміння того, наскільки насправді цікавий legacy і що його можна насправді не боятися, а навіть любити.

Відразу обмовлюся, що ми зараз говоримо про код, і тільки про нього. Не про красиві офіси, привабливих Hrів, крутих лідів і великий PR. Код.

Припустимо ви розробник на PHP, і вам би сказали «Приходь до нас на проект, ми вже пишемо цей код на PHP кілька років, у нас сотні мегабайт коду, майже ніякого ООП та функціональне програмування». Якось сумнівно звучить в розрізі legacy? А якби вам сказали «Приходь кодити vk?». Різниця є, і вона значна.
Зайдемо з іншого боку.
Вам би сказали: «Слухай, у мене для тебе є відмінна можливість, мені потрібно щоб ти застосував всі патерни які тобі знайомі, можеш використовувати будь-які фреймворки та технології, можеш написати все з нуля, зроби мені просто домашній блог для моєї собачки». Ніякого legacy, повний простір думки і свобода дій. Все можна зробити ідеально красиво на модному node.js, прикрутити ajax, comet, поставити кеші на redis, додати RT пошук з морфологією на elastic'e, але… навіщо?

Банальність №1:
Цікавий проект — це той, який цікавий розробнику в принципі. Поза мови, поза технології, поза архітектури. І це не має ніякого відношення до legacy.


Вам знайоме почуття, коли думаючи над новим проектом, ви малюєте у себе в голові картинку того, як будь сутності повинні з чим взаємодіяти, які верстви архітектури треба зробити, де виявляться вузькі місця і що потрібно зробити щоб цього уникнути? Такий собі казковий світ зі своїми мешканцями і зв'язками, яке живе своїм життям і який ви поступово переводите в код, у щось відчутне, що починає «існувати».
Розкрию вам секрет — неможливо писати код, якщо ти не «художник». Але і художники не відразу можуть написати гарні полотна. Вони вчаться більш гармонійно підбирати кольори, відображати перспективу, поєднувати елементи і т.д. Програмісти точно також вчаться підбирати рішення, бачити майбутнє проекту і робити все максимально зручним, підтримуваним, ефективним, і в межах наявних ресурсів. А якщо в процесі життя картини до неї з'являються нові вимоги — «А давайте зробимо що тепер вечір. А ще нехай до неба летить дракон. А ще насправді зараз зима, а не літо. І нехай на задньому плані буде Дайнерис вбиває Джорджа Мартіна» — в такі моменти складно зберегти початковий творчий, в чомусь прекрасне, задум автора.

Коли ви починаєте працювати з новим проектом, за фактом ви є творцем, винахідником. Прекрасне почуття. Коли ж ви отримуєте legacy код, проект на підтримку, чомусь у більшості складається образ, як ніби вони тільки що отримали Авгієві стайні, притому це ще до того, як власне заглянули в код. Досить просто подумати що це legacy.

Який би не був проект, в його основі теж лежить картина, може мазки на ній вже не так гармонійно поєднуються, але картина була. І поки ви читаєте legacy, ви, як дослідник, можете відновити її в своїй голові, і мало того, ви, як професіонал, можете зробити її красивою. Грамотно додати відсутніх деталей, домалювати те, що вийшло дуже красиво у попередніх «майстрів», та отримати нову картину, вже вашу, і тільки у ваших силах зробити її ще кращою, ніж вона може бути навіть була спочатку.

Банальність №2:
«Legacy» не означає «негарно». Це шанс зробити ще красивішим.


Багатьом знайома фраза «Дурень вчиться на своїх помилках, а розумний на чужих». Якщо хтось із вас все ж практикував TDD, той прекрасно знає, що неможливо, при всьому професіоналізм, завжди писати код без помилок, навіть з мільйоном перестраховок. Це природне явище.
Так от якщо ви досить досвідчені і вмієте, як справжній детектив, дослідник і навіть реконструктор, копатися в чужому коді, створювати його образ у своїй голові, знаходити приховані закономірності, то ви також зможете і витягти з нього чимало корисного. Якісь дивні рішення, які насправді були до місця, але ви раптом задумаєтеся, і зрозумієте, що знаєте і більш оптимальне рішення, просто тому що неоптимальне за вас вже написали, і ви побачили його в дії, і тепер ви знаєте, як зробити краще. Ми всі знаємо, що рефакторіть можна нескінченно, але щоб рефакторіть, дізнаватися нове про код, потрібно, щоб він уже щось пожив, вже був написаний, і тут як раз legacy підходить ідеально.
Хочу тільки зауважити, що в цьому мене зрозуміють тільки ті, хто любить знаходити нові підходи, хто любить думати не за шаблоном. Зустрічаються розробники, які, скоріше в силу своєї недосвідченості, зустрічаючись зі старими проектами, готові брати прапори і кричати «Так тут суцільний говнокод, все це насправді пишеться по-іншому на %my_favorite_framework%, він ідеальний, він вирішує всі проблеми, всі переписати!!!».

В legacy коді багато чому можна навчитися при належному підході і навичках. Перш за все того, як бачить код інший розробник, і в чому його підхід хороший, а чим поганий. Розширення своєї картини світу завжди робить її ще більш повною, якщо не замикатися на шаблонних рішень.
За фактом, код більшості популярних фреймворків, бібліотек і компонентів вже багато в чому став legacy. І думаю ви навряд чи станете заперечувати, що вивчення цього коду ніколи не дасть вам чогось нового, цінного для розробника. Того, що не прочитаєш ні в одній книзі.

Банальність №3:
Legacy — це відмінний підручник того, як треба і як не треба робити.


Ви коли-небудь читали книги, які були дуже складні для сприйняття? Візьміть, наприклад, для порівняння вірші Данте, або розповіді Германа Гессе, або Айн Ренд, або взагалі хоч якийсь кодекс РФ. Знайоме відчуття, коли шестерні розумового процесу починають ламати один про одного зуби вже на другій сторінці? Але хіба це яким-небудь чином принижує смислову цінність твору?
Так от читання чужого коду часом може бути не менш зубодробильний. Звичайно, вже давно придумали таке поняття, як CodeStyle. Однак, чомусь у багатьох legacy асоціюється з чимось, що дуже складно прочитати, що написано в порушення всіх правил дуже давно. Насправді ж той, хто писав цей код, просто дотримувався «тим» правилами, і навчитися читати код в будь-якому стилі не так вже й складно.

Банальність №4:
Legacy не так складно читати, навіть якщо порушений CodeStyle. До того ж, основні сучасні IDE вже навчилися на гідному рівні підтримувати автоформат коду.


Як-то давно, на фрілансі, один знайомий замовник попросив доопрацювати простенький проект на одному відомому фреймворку. Йому його виготовив один фрілансер, буквально недавно, але він зник після одержання оплати, а потрібно поправити дрібниця.
Яке ж було моє здивування, коли я виявив копіпаст запуску простого контролера з одним view-файлом, в якому і був розташований весь(!) код проекту. Чоловік зробив проект «на модному фреймворку», але(!) зробив. Якщо б цей код отлежался рік-другий, і дістався комусь на підтримку, то він би з жахом в очах сказав би «Так що це за legacy?!». Але для мене цього коду не було і «тижні від народження». Це був звичайний, банальний говнокод.
Зараз же я працюю на проекті, код якого розвивається вже 12-ий рік і буде рости далі. І знаєте, незважаючи на окремі недоліки, навіть дуже старі шматки виглядають і читаються дуже добре. Це legacy, хороший, добротний legacy, багато разів доопрацьований, але все ще читається і підтримуваний legacy.

Банальність №5:
«Legacy» не одно «говнокод».


Чи траплялося з вами, що відкриваючи проект за давністю декількох років, ви бачите код і відчуваєте легке " дежа-вю? Ніби з туману поступово починають виявлятися обриси чогось до болю знайомого, майже рідного. І щоб розвіяти останні сумніви в хід йде blame і annotate, і тут все встає на свої місця. Він. Він самий. І в голові починають крутитися думки на кшталт «Так як я таке міг написати?! Еххх, зелений був. О, а ось це я круто зробив, простенько і зі смаком. Так так, а ось це треба швидко поправити поки ніхто не побачив». Знайоме?
Так от багато хто чомусь думають що legacy це що-те, що буває з кимось іншим. Що ви або ніколи не будете дивитися на свій код за кілька місяців/років, або навіть не допускаєте тієї думки, що зараз пишете щось, що буде виглядати як legacy (або вже виглядає так?). Тим не менш, це не так.

Банальність №6:
Ви теж пишете Legacy.


Резюмуючи все вищесказане, хотілося б сказати, що як такий термін legacy не заслуговує честі бути «страшилкою». У ньому є свої чудові сторони, і лише недосвідченість розробників, притому не тільки тих, хто написав код, а часом і тих, хто збирається працювати з ним, створює йому таку славу. Багато legacy коду пройшло через мої руки, і з більшістю з нього мені справді було приємно працювати. Розбиратися як він працює, намагатися зрозуміти задум автора, знаходити відповідні рішення або навпаки переконуватися в тому, що рішення автора хоч і не було очевидним, але виявлялося досить ефективним. Допрацьовувати вже те, що працює, чим користуються, робити це краще — це відмінний досвід. Не можна навчитися писати код добре, якщо писати його чи завжди за шаблоном, або завжди з нуля. Людина все пізнає в порівнянні, і чим більше джерел для порівняння, тим краще ви пишете.



Успіхів вам на теренах розробки і побільше хорошого, добротного Legacy-коду! Сподіваюся, тепер для вас ця фраза сприймається інакше, ніж до початку статті: )

Бонус у вигляді списку книг, якщо ще не прочитали:
Refactoring — Improving the Design of Existing Code
Working Effectively with Legacy Code
Refactoring to Patterns
Clean Code: A Handbook of Agile Software Craftsmanship

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.