Рефакторинг який ми не робимо

Рефакторинг який ми не робимо

Не так давно я описував процес рефакторинга одного проекту зайшов до відділу, ми разом посміялися так поплакали, але відати мораль звідти не винесли. І в цій історії ми не «білі і пухнасті» ...

Історія починалася банально - проект загинається, замовник шукає нову команду розробки і знаходить нас. Ми такі всі з себе, на білому коні в'їжджаємо в проект, а там нічого страшного, просто функціональний plain PHP код, тобто класів немає, функцій практично теж (один файл functions.php, а в ньому dbconnect (), userlogin () та функція-шаблонизатор, і щось ще по дрібниці). Дивимося - а проблема то в навантаженні - до 10 000 онлайн користувачів і в цей час на сайт і зайти не можна. Добре, завдання зрозуміле, садимо в проект розробника, який знайомий з оптимізацією, ну і він почав працювати. І так, після двох тижнів роботи (а може і більше, вже не пам'ятаю) сайт ожив, трохи індексів, трохи кешування, ще трохи оптимізації SQL запитів і навантаження на сервера спала.

Через деякий час, ми замінюємо розробника в проекті, новій людині більше до душі припадають фичи і ченжі замовника, і наша ефективність знову йде вгору, замовник задоволений, ми вважаємо гроші. Все добре і ніщо не віщувало того, що сталося.

У проекті все менше і менше роботи, завдання скочуються до рівня trivial, і ми приймаємо рішення посадити в нього «зеленого» бійця, щоб випробувати його, та й замовник дав на це добро. Старт був гладким, а потім почалися проблеми, то вилізли за терміни, які самі і обмовили, то на сервер залили не зовсім робочий код. І як підсумок - «Спасибі, що допомогли, ви мене дійсно виручили, але далі я обійдуся без вас»

Починаємо розбір польотів, вирішуємо, що новенького ми даремно посадили в проект, але я до того моменту заліз в вивчення коду по вуха, і тому зараз опишу те, чого я там не побачив.

шаблонизатор

В системі був створений елементарний шаблонизатор з нативним синтаксисом (що скоріше плюс), але в шаблонах постійно зустрічалися звернення до БД, і при зміні структури доводилося перелапачівать не тільки код сторінок, але і всі шаблони. Таким чином необхідно було розділити логіку від уявлення раз і назавжди.

Якщо говорити про функції-шаблонизатор, то ось елементарний приклад:

Решта залишається на совісті розробника, власне навіть в той же Smarty можна впихнути логіку при належному бажанні.

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

контролери

Тут просто напрошувався цей пункт, тому я його додав, і хотів сказати наступне - якщо у вас в корені проекту лежить пару десятків файлів, то не варто морочитися, і переписувати їх все, щоб у вас вийшла татко controllers і єдина точка входу, адже ці файли з поставленим завданням цілком справляються. Як висновок - не варто гнатися за ідеальним кодом. такі вкладення праці можуть не окупитися.

Робота з БД

Як я описував вище, SQL запити зустрічалися в проекті по всіх усюдах, і навіть процес екранування вхідних даних в них був різний. Привести до єдиного стилю. створити нормальний врапер для БД, або хоча б замінити використання розширення mysql на що-небудь більш сучасне.

Можна було б написати простий врапер для врапера PDO за 20 хвилин, звичайно він не буде універсальний, але полегшить працю рефакторінга:

  • легко Залогуватися використовуючи одну точку входу
  • можна швидко додати кешування для всіх запитів

кешування

Тут варто згадати, кешування прикрутили, АЛЕ лише там де вказав замовник, а хотілося б, щоб був кеш всюди де це має сенс, а не виходячи з ув'язнення «начебто тут», тобто треба було в кожен файл заглянути, логи проаналізувати, та й час кешування можна було потюніть в рейлтайме, але зрушення часового поясу нам напевно сильно завадив, і ніхто не захотів заради цього з дому моніторити сервер, або хоча б попросити про це наших же адмінів ( а ми такі послуги надаємо;).

Робота над помилками

Тут все легко, якщо ви відкриваєте PHP файл, а вам IDE підказує кричить про помилки в коді, то приділіть п'ять хвилин часу і виправте їх:

Рефакторинг який ми не робимо

І ще - в обов'язковому порядку включите відображення помилок, і запам'ятайте - «пригнічений» Notice краде час:

тестування

- Unit тестування? Про що мова, у нас тут запара, треба викочувати на лів!
Ну ну…

клієнтська оптимізація

Цього пункту не торкнувся ні один з розробників, які брали участь у проекті, і це дійсно засмучує. Звичайно, головна сторінка проекту не надто й важка - всього 300кб, але на них припадає 15 JS файлів, 18 картинок в CSS (спрайт врятують сервер), так само варто потерти старі хукі для браузерів (IE5.5 і IE6), полегшити верстку, адже 8,7kb це не так вже й мало (занадто багато таблиць).

Власне, сайт по оцінці YSlow отримує оцінку C (70), що я вважаю неприпустимим, для порівняння мій блог з купою картинок - A (90). Як поліпшити ці свідчення дуже добре розповідає сайт webo.in. і я думаю йому варто приділити місце в закладках.

«Не наш» проект

Ще я б хотів розповісти про те, що дуже часто програмісти не переймаються і не живуть проектом, а це дуже негативно позначається на взаємини з замовником і на розвиток проекту. Проект повинен стати чимось невід'ємним від вас, якщо сайт загинається під напливом користувачів - вам теж має бути не по собі, адже це ваш твір страждає, і йому потрібна ваша допомога. Ви як фахівець повинні радити замовнику, як розвивати проект, адже саме ви знаєте про всіх ноу-хау в web-розробці, і не варто чекати, що з пропозицією про поліпшення виступить він, зробити перший крок повинні саме ви і саме зараз. Не варто в проекті жити одним днем, треба дивитися вперед і можливо рефакторинг проекту коштувало почати ще вчора.

Якщо у вашому проект все йде гладко, то придивіться, можливо під настільки солодким виглядом причаївся рак вашого байдужості до життя проекту.

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

інформація

Схожі статті