Във Fashinza наблягаме много на писането на чист код. За тази цел имаме стриктни PR прегледи и процеси на одобрение. Това е от решаващо значение, тъй като помага на разработчиците да четат, поддържат и подобряват кода ефективно. Това не винаги е било така, тъй като основният фокус беше функциите да бъдат пуснати възможно най-рано. Осъзнахме проблема с това не много отдавна; тогава решихме да преработим кодовата си база.
Но какво точно е преработването на кода и как да разберем, че имаме нужда от него, освен това как да подходим? Нека погледнем.

Какво точно е рефакторинг на код?

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

Има множество причини, поради които може да е необходимо да преработите кода си; те включват, но не се ограничават до:

  • Мръсен код, съчетан с кратки срокове.
  • Добавяне на една последна функция към проект точно преди пускането му.
  • Липса на значение, което се отдава на качеството на кода и технологиите и повече фокусиране върху изданията на функции.

Рефакторингът на кода се справя с тези проблеми и има за цел да ги разреши по систематичен начин, за да трансформира разхвърляния код в качествен и по-чист. В дългосрочен план това помага за намаляване на TAT за развитие, което прави процеса по-ефективен и рационализиран.

Как да разберем, че имаме нужда от него?

В бързината на днешния гъвкав свят има голям натиск за предоставяне на функции наистина бързо с много функционалност за минимално време. Това е много често срещано при работа в бърза стартираща среда.

В крайна сметка идва момент, когато възниква необходимостта да погледнем объркания код, който написахме поради споменатите причини. Това трябва да стане рано или късно; ще знаете, че имате нужда от преработване на кода, когато:

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

Същото се случи и с нас във Fashinza и решихме да преработим кодовата си база.

Какво направихме?

Нашият основен технологичен стек във фронтенда е ReactJS, комбиниран с Redux. Предприехме няколко стъпки, за да преработим кодовата база на интерфейса:

  • Първо, започнахме да следваме ръководства за стил, Linting и кодови стандарти и правила. Например, поправихме начина, по който сортираме импортирания, започнахме да използваме специфичен регистър за променливи, имена на функции и класове и т.н.
  • След това се отдалечихме от неподредените базирани на клас компоненти и преминахме към функционални такива, за да се възползваме от предимствата на куките. Стигна се до точката, в която повечето от нашите компоненти бяха повече от 300 реда код и когато се опитахме да добавим нова функционалност или да подобрим съществуваща, тя счупи нещо друго. Преминаването към функционални компоненти ни помогна да намалим кода си до голяма степен. Например, нека да разгледаме разликата в този прост компонент:

Сега го сравнете с преработения и вижте колко по-чист изглежда.

  • Логиката за изобразяване и повторно изобразяване на компоненти е написана в базирани на клас методи на жизнения цикъл: componentDidMount и componentDidUpdate [Код A:Ред 8–21]. Преобразуването на това във функционална кука useEffectпомогна да се опрости много логиката [Код B: Ред 11–13].
  • Също така, вместо да се свързваме с redux чрез mapStateToProps mapDispatchToProps, ние използвахме кукички useSelector и useDispatch съответно.
  • Извършването на тези промени ни помогна да намалим дължината на кода с повече от 50%.
  • Започнахме също да използваме TypeScript, той помогна на разработчиците да разберат типовете данни и интерфейсите на компонентите и функциите, без дори да изпълняват кода. Производителността се увеличи толкова много, когато започнахме да използваме TS, че заслужава отделна статия.
  • Започнахме да използваме git правилно! Правехме толкова много промени с толкова бързо темпо, че компонентите, които изграждахме, се заменяха с нови всяка седмица. Поколебахме се да изтрием по-стария код, страхувайки се, че може да бъде използван отново в бъдеще. Това се случи толкова много, че нашата файлова структура започна да изглежда така:
components
   > AddOrderOld
   > AddOrderNew
   > AddOrderNewer

Справихме се с този проблем, като използвахме git правилно, с валидни имена на клонове, PR заглавия, съобщения за ангажиране, етикети и т.н.

  • Наложихме някои добри практики по целия проект. Това включва използването на styled-components за писане на нашите стилове вместо извън SASS. Това ни помогна да избегнем противоречиви имена на класове в целия проект и също така ни помогна да направим комуникацията между компонентите и неговия стил много по-лесна.

Поглеждайки назад, ние направихме много промени в нашето репо за дълъг период от време. Рефакторингът на кода не е еднократен процес, а непрекъснат, който може да се извърши успоредно с изграждането на нови функции. Все още активно преработваме старата си кодова база и успяхме да мигрираме 45%от кода в TypeScript. Ние правим същото и в кодовата база на бекенда, като въвеждаме шаблони за проектиране, тестови случаи, документация за API и т.н.

TL;DR

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