Както при всяка кодова база, проектът на основния уебсайт на VoucherCodes се разраства органично с течение на времето. Промяната на екипите, непрекъснато променящите се изисквания – и дори пълната смяна на стека на технологиите – ни оставят с мозайка от старо и ново.

Ние се грижим да гарантираме, че дори по-старите части от нашата кодова база са обгрижени и не попадат в категорията „наследени“. Ето някои от нашите знания по този въпрос, които се надяваме да се приложат към вашата кодова база в момента.

В тази статия ще разгледаме:

  • Структура на проекта
  • Стил на кода
  • Анализ на кода
  • Тестване
  • Рефакторинг на код

Структура на проекта

Както сега е индустриалният стандарт, вашият код трябва да се придържа към пространството на имената на PSR-4 autoloader (https://www.php-fig.org/psr/psr-4/) и да има последователна структура на папките. Тази структура на място, за да работи автоматичното зареждане, премахва необходимостта изрично да include класовете, които използвате във файл. Класове като user_service трябва да бъдат заменени с класове с пространство от имена, напр. \App\User\UserService и подходящата структура на папките src/User/Userservice.php .

Ако използвате PHPStorm, има „вградена проверка“ „Пътят на класа не съответства на структурата на проекта“, която ще ви уведоми кога даден файл трябва да бъде променен, за да се придържа към PSR-4

Почистете кода си

Можем да използваме инструменти като PHP Codesniffer, за да форматираме автоматично вашия съществуващ PHP код, за да съответства на определен стил на код, като PSR-12.

Прилагайте тези промени в стила на кода изолирано - не се опитвайте да смесвате промени в поведението. Целта тук е да се опростят git diffs и да се улеснят прегледите на кода в бъдеще.

Ако използвате PHPStorm, можете да конфигурирате вашия стил на код и IDE да приложи това форматиране вместо вас, докато пишете.

Добавяне на увереност към вашите промени в кода

Когато работим с крехка кодова база - такава, в която промените могат да причинят каскадни проблеми - е трудно да имаме увереността да направим много от промените, които трябва да модернизираме.

Най-добрият начин да вдъхнем тази увереност е да добавим някои тестове и проверки към кода, който модернизираме, като се надяваме, че това ще подчертае всички потенциални проблеми, когато се правят промени.

Статичен анализ

Ние придобиваме увереност, че нашите промени са „правилни“, като използваме инструменти за статичен анализ. През последните няколко години PHPStan спаси кожата ни многократно с незабавна обратна връзка, че кодът ни вероятно съдържа грешки.

PHPStan сканира цялата ви кодова база и търси както очевидни, така и трудни грешки. Дори в тези рядко изпълнявани изрази „if“, които със сигурност не са обхванати от тестове.
https://phpstan.org/

Възприехме подхода да използваме базова линия с разумно високо ниво, за да гарантираме, че новонаписаният код е на ниво. След това се съсредоточихме върху намаляването на тази базова линия, докато почти изчезне напълно.

Ако има само едно нещо, което отнемате от тази статия, то трябва да е това. Използвайте статичен анализатор! Само наличието на такъв ви прави по-добър разработчик.

Рефакторинг на код

Има много причини да преработим кода, причината, която най-често се появява за нас, е да добавим разширяемост за нова функционалност.

Често използваме подхода на преработване на текущия код, за да позволи разширяемост, като същевременно запазим функционалността същата — след това можем да се възползваме от тази нова разширяемост, като добавим функционалност отгоре. Третирането им като две независими стъпки носи увереност в преработването на вашия код.

Интеграционните тестове пред модулните тестове

Когато рефакторираме нашия код, ние променяме подробностите за внедряването - и модулните тестове са свързани с подробностите за изпълнението. Така че нека изберем различен тип тест, който се фокусира върху резултатите.

Интеграционните тестове валидират по-голяма част от функционалността и са идеални, когато искаме да променим подхода си под капака. Помислете за примери като преминаване от локална файлова система към AWS S3, замяна на вашия имейл, добавяне на нов тип оферта.

Изненадващо, интеграционните тестове могат да бъдат лесни за писане за съществуваща система! Имате система, която вече работи днес. Въведете малко данни, вижте какво ще изскочи. След това го копирайте в тест, като правите точно това.

Умението се състои в това да знаете какво да тествате. Не можем да тестваме всичко, но сравняването на употребата в реалния свят с вашите тестове ще ви отведе по-голямата част от пътя. Когато преработваме, можем да твърдим, че той просто прави същото нещо за момента - промените могат да дойдат по-късно, след като сме на по-добро място.

Запазване на вашите промени атомарни

Винаги е изкушаващо, когато преработвате кода, да отидете към големия взрив. Променете всичко наведнъж и го освободете наведнъж. Огромни разлики като този водят до проблеми, ако възникнат проблеми.

Помислете как ще коригирате всички проблеми, които възникнат скоро след пускането. Връщане назад? Поправка напред? Сега си представете, че току-що сте пуснали пет големи промени вместо една. Връщането назад не звучи като приличен вариант.

Най-добре е да се опитате да направите възможно най-малки, приложими промени. Пускайте рано и често, за да поддържате ритъма си. Това не само ще помогне при идентифицирането и отстраняването на проблеми, вие получавате допълнителната полза от повишаване на морала на екипа, виждайки как нещата се доставят.

Автоматично преработване

Ние мигрирахме нашите CLI скриптове — помислете за PHP crons и демони — към symfony/console. Правенето на това ръчно може да бъде досадна, повтаряща се работа, податлива на грешки. За да поддържаме това, използвахме инструмент, наречен „Ректор“.

Ректорът ни предостави инструменти за автоматично картографиране на нашата реализация на конзолни идеи към имплементацията на конзолната команда от symfony. Получавате директен достъп до AST (абстрактно синтактично дърво), описващо вашия код, и можете да го трансформирате по желание. Идентифицирането на общи модели и програмното им трансформиране спестява ръчния труд и избягва проблемите с използването на глобално търсене и заместване на текстово базирано манипулиране.

Има дори публично достъпни шаблони за ректор за помощ при използването на рамка, като например rectorphp/rector-symfony.

Знай кога да спреш

Знаем, че трябва да избягваме преработването на големия взрив, но има елемент на прагматизъм, който трябва да се има предвид, когато избираме да преработваме нещо.

Има много въпроси, които трябва да си зададете:

Трябва ли този код да бъде преработен сега?
Ще бъде ли достатъчно бързо коригиране?
Каква е пътната карта около това?
Ще съществува ли този код след шест месеца? Годишно? две? Десет?!

Кодът, който е грозен, но работи, все още е код, който работи. Фокусирайте се върху работата, която ще подобри нещата в дългосрочен план спрямо краткосрочните поправки. Добре е да оставите нещата за по-късно.

Чували ли сте? Наемаме служители във VoucherCodes! Вижте нашата страница за кариери тук.