Refaktorinq: nədir, məqsədləri və təkmilləşdirmədə refaktorinq üsulları

Proqramlaşdırmada refaktorinq etmək nə deməkdir

Refaktorinq etmək — bu, müşahidə olunan davranışı dəyişmədən proqram kodunun daxili strukturunun keyfiyyət xarakteristikalarını yaxşılaşdırmaq məqsədi ilə dəyişdirilməsi prosesidir. Termin 1999-cu ildə Martin Fowler tərəfindən geniş istifadəyə verilmişdir və təcrübənin özü çevik inkişafın və ekstremal proqramlaşdırmanın əsaslarından birinə çevrilmişdir.

Refaktorinqin əsas xarakteristikası funksionallığın qorunmasıdır. Refaktorinqdən sonra proqram dəyişikliklərdən əvvəlki kimi eyni hərəkətləri yerinə yetirməli və eyni nəticələri qaytarmalıdır. Bunun təminatı refaktorinqin hər bir mikroaddımından sonra işə salınan avtomatlaşdırılmış testlərdir. Testlər yaşıl olarsa — davranış qorunub. Qırmızı olarsa — refaktorinq səhv yerinə yetirilib və ya davranış dəyişib, bu o deməkdir ki, bu artıq refaktorinq deyil, funksionallığın modifikasiyasıdır.

Sənayedə geniş yayılmış yanlış fikir var: hər hansı kod təmirini refaktorinq adlandırırlar. Əslində davranış dəyişikliyi ilə kodun yenidən yazılması “rewrite” və ya “rework”-dur, refaktorinq deyil. Fərq prinsipialdır: refaktorinq nəzarət olunan, təhlükəsiz prosesdir, məntiq dəyişikliyi ilə yenidən yazma isə bütün müşayiət edən risklərlə tam hüquqlu yeni inkişafdır.

Refaktorinq haqqında biliklərin Azərbaycan dilində mənimsənilməsi digər IT terminləri ilə eyni mexanizmlər vasitəsilə gedir: ingilis refactor sözünün kalkalanması. Proqram mühəndisliyi üzrə təhsil proqramları və kitab tərcümələri bu termini peşəkar leksikonda möhkəmləndirmişdir.

Refaktorinq vs Yenidən Yazma

Refaktorinqi kodun tam yenidən yazılmasından (rewrite) fərqləndirmək vacibdir. Refaktorinq — hər biri davranışı qoruyan kiçik, təhlükəsiz çevrilmələr seriyasıdır. Yenidən yazma — tez-tez arxitektura, texnologiya və davranışların dəyişdirilməsi ilə sıfırdan yeni tətbiqin yaradılmasıdır. Standish Group (2023) tədqiqatı göstərir ki, tam rewrite seçən layihələr 40% hallarda uğursuz olur, müntəzəm refaktorinq tətbiq edən layihələr isə 25% daha az texniki borc səviyyəsinə malikdir.

Kodu niyə refaktorinq etməli: əsas məqsədlər

Refaktorinq bir neçə əsas vəzifəni həll edir, hər biri birbaşa inkişaf sürətinə və dəyərinə təsir göstərir. Bu məqsədləri başa düşmək komandaya prioritetləri düzgün müəyyən etməyə və maraqlı tərəflər qarşısında refaktorinqə sərf olunan vaxtı əsaslandırmağa kömək edir.

Oxunaqlılığın və anlaşılanlığın yaxşılaşdırılması

Kod bir dəfə yazılır, amma onlarla və yüzlərlə dəfə oxunur. Əgər proqramçı funksiyanın nə etdiyini anlamaq üçün 30 dəqiqə sərf edirsə — bu birbaşa məhsuldarlıq itkisidir. Oxunaqlı kod idrak yükünü azaldır və komandanın yeni üzvlərinin adaptasiyasını sürətləndirir. Rename Method, Extract Variable və Introduce Explaining Variable kimi texnikalar məhz kodun anlaşılanlığını artırmağa yönəlmişdir. Developer Productivity (Microsoft Research, 2023) tədqiqatına görə, proqramçılar vaxtlarının 60%-ə qədərini kod yazmaq deyil, oxumaqla keçirirlər ki, bu da oxunaqlılığı məhsuldarlığın əsas amillərindən birinə çevirir.

Təkrarlanmaların aradan qaldırılması

DRY (Don’t Repeat Yourself) prinsipi — proqramlaşdırmada əsas prinsiplərdən biridir. Kodun təkrarlanması eyni dəyişikliyin bir neçə yerdə edilməsinə gətirib çıxarır ki, bu da səhv və unudulmuş düzəliş riskini artırır. Extract Method və Pull Up Method texnikaları ilə refaktorinq təkrarlanmaları aradan qaldırmağa və məntiqi mərkəzləşdirməyə imkan verir.

Mürəkkəbliyin azaldılması

Siklamatik mürəkkəblik və yuvalanma dərinliyi metrikaları birbaşa koddakı defektlərin sayı ilə korrelyasiya edir. Əgər funksiyanın siklamatik mürəkkəbliyi 10-15-dən yüksəkdirsə, onu test etmək çətindir və asanlıqla sındırmaq olar. Replace Conditional with Polymorphism, Decompose Conditional və Extract Method ilə refaktorinq mürəkkəbliyi idarə olunan səviyyəyə endirməyə imkan verir. NIST (2024) tədqiqatı göstərir ki, yüksək mürəkkəblikli modullar hər min sətir kodda 2-3 dəfə çox defekt ehtiva edir.

Dəyişikliklərə hazırlıq

Refaktorinqin əsas səbəblərindən biri yeni funksionallıq əlavə etmək zərurətidir. Əgər mövcud kod strukturu mövcud davranışı pozmadan dəyişiklik etməyə imkan vermirsə, refaktorinq zəmin hazırlamağa kömək edir. “Kempinq qaydası” (kodu tapdığından təmiz qoy) — Martin Fowler-in tövsiyələrindən biridir ki, refaktorinqi epizodik fəaliyyətdən daimi təcrübəyə çevirir.

GitHub-da 500 open-source layihənin təhlili məlumatları (IEEE Transactions on Software Engineering, 2024) göstərir ki, müntəzəm refaktorinq edilən layihələrdə arabir refaktorinq edilən layihələrlə müqayisədə 30% az “kod qoxusu” (code smells) və 15% aşağı texniki borc göstəricisi var.

Refaktorinqin əsas texnikaları

Martin Fowler öz kitabında 70-dən çox refaktorinq texnikasını kataloqlaşdırmışdır. Praktikada əksər komandalar müntəzəm olaraq onlardan 10-15-ni istifadə edir. Hər bir proqramçının bilməli olduğu əsas texnikaları nəzərdən keçirək.

Extract Method

Ən çox istifadə edilən texnika. Əgər kod parçasını mənaca ayrıca funksiyaya çıxarmaq olarsa — bunu etmək lazımdır. Extract Method oxunaqlılığı yaxşılaşdırır, əməliyyata ad verməyə imkan verir və test etməni asanlaşdırır. Qayda: əgər kod blokunun nə etdiyini izah edən şərh görürsünüzsə — bu bloku ayrıca metod çıxarmaq olar.

// Refaktorinqdən əvvəl
double total = amount * price;
double discounted = total * (1 - discountRate);
double tax = discounted * taxRate;

// Refaktorinqdən sonra
double total = calculateTotal(amount, price);
double finalPrice = applyDiscountAndTax(total);

Rename Variable / Rename Method

Ad mahiyyəti əks etdirməlidir. Əgər dəyişənin və ya metodun adı “bura nə saxlanılır/edilir” sualına cavab vermirsə — onu adlandırmaq lazımdır. Müasir IDE-lər bu əməliyyatı trivial edir. Təmiz adlar — kodu yaxşılaşdırmağın ən ucuz və effektiv yoludur.

Replace Conditional with Polymorphism

Şərti məntiq çox böyüdükdə və qarışdıqda, polimorfizm daha təmiz alternativ təklif edir. Növə görə switch-case əvəzinə — həddən artıq yüklənmiş metod ilə sinif iyerarxiyası yaradın. Polimorfizm kodu genişləndirilə bilən edir: yeni tipin əlavə edilməsi mövcud şərtlərin dəyişdirilməsini deyil, yalnız yeni alt sinfin yaradılmasını tələb edir.

// Refaktorinqdən əvvəl (şərti ifadələr)
if (type.equals("email")) {
    sendEmail(message);
} else if (type.equals("sms")) {
    sendSms(message);
}

// Refaktorinqdən sonra (polimorfizm)
Notifier notifier = new EmailNotifier();
notifier.send(message);

Introduce Parameter Object

Funksiya çox parametr qəbul etdikdə (3-4-dən çox), onları oxumaq və ötürmək çətin olur. Əlaqəli parametrlərin parametr obyektində qruplaşdırılması imzanı qısaldır, oxunaqlılığı yaxşılaşdırır və sonrakı dəyişiklikləri asanlaşdırır.

Nə vaxt refaktorinq etməli və etməməli

Refaktorinq qərarı texniki deyil, idarəetmə qərarıdır. O, cari məhsuldarlıq ilə kod bazasının uzunmüddətli sağlamlığı arasında tarazlıq tələb edir. Refaktorinqin əsaslandırıldığı tipik vəziyyətləri və nə vaxt çəkinməyin daha yaxşı olduğunu nəzərdən keçirək.

Nə vaxt refaktorinq etməli

Birinci vəziyyət — dəyişdirməli olduğunuz kodu başa düşmürsünüz. Əgər mövcud kodu anlamaq yeni funksionallığı tətbiq etməkdən daha çox vaxt aparırsa — bu əvvəlcə refaktorinq etmək lazım olduğuna işarədir. İkinci vəziyyət — inkişafı yavaşladan və səhv riskini artıran təkrarlanma tapmısınız. Üçüncü — yeni funksionallığın əlavə edilməsi mövcud strukturu pozmadan mümkün deyil.

Həmçinin kod bazasında “qoxular” (code smells) olduqda refaktorinq etməyə dəyər: uzun metodlar, böyük siniflər, həddindən artıq şərhlər, çağırış zəncirləri, paralel miras iyerarxiyaları. Fowler-in kitabındakı code smells kataloqu 20-dən çox tipik problem göstəricisini ehtiva edir, hər birinin müvafiq refaktorinq texnikası var.

Nə vaxt refaktorinq etməməli

Kod sabit işləyirsə və onu dəyişdirmək planlaşdırılmırsa, refaktorinq lazım deyil. “İşləyir — toxunma” (if it ain’t broke, don’t fix it) prinsipi nadir hallarda dəyişdirilən kod üçün xüsusilə aktualdır. Refaktorinq naminə refaktorinq — faydadan çox zərər gətirən mühəndis perfeksionizminin formalarından biridir.

Həmçinin yaxın zamanda tamamilə əvəz ediləcək kodu refaktorinq etməməlisiniz. Əgər komanda modulu başqa dildə və ya arxitekturada yenidən yazmağı planlaşdırırsa, cari versiyanın refaktorinqi vaxt itkisidir. Və nəhayət, testsiz refaktorinq — xüsusilə kod bazası böyük və mürəkkəb olduqda macəradır. İstisna — geri qaytarıla bilən IDE vasitəsilə sadə çevrilmələrdir.

Layihə üçün risksiz refaktorinq necə etməli

Təhlükəsiz refaktorinq — intizamdır. Riskləri minimuma endirən və prosesi proqnozlaşdırıla bilən edən bir neçə prinsip var. Birinci və əsas — refaktorinq yalnız testlər altında. Əgər dəyişdirilən kodu əhatə edən testləriniz yoxdursa — əvvəlcə onları yazın.

İkinci prinsip — kiçik addımlar. Hər bir refaktorinq əməliyyatı minimal olmalıdır: bir dəyişənin adlandırılması, bir metodun çıxarılması, bir sinfin ayrılması. Hər addımdan sonra — kompilyasiya edin və testləri işə salın. Mikroaddımlara bölmə dərhal səhvi aşkarlamağa və son dəyişikliyi geri qaytarmağa imkan verir. Martin Fowler-ə görə, mikroaddımlar refaktorinqi böyük dəyişikliklərdən 3-4 dəfə təhlükəsiz edir.

Üçüncü prinsip — alətlərdən istifadə. Müasir IDE-lər (IntelliJ IDEA, VS Code, Eclipse) avtomatlaşdırılmış refaktorinqlər təklif edir: rename, extract method, extract variable, move class və onlarla başqa. Alət refaktorinqləri çevrilmənin düzgünlüyünü təmin edir və kodun dəyişdirilməli olduğu bütün yerlərin əl ilə axtarılmasını tələb etmir.

Dördüncü prinsip — refaktorinqi funksionallıq dəyişikliyi ilə qarışdırmayın. Əgər eyni anda refaktorinq edir və yeni məntiq əlavə edirsinizsə, hansı dəyişikliyin səhvə səbəb olduğunu anlamaq mümkün deyil. Commitlərin bölünməsi “refaktorinq” və “feat” — code review və dəyişikliklərin geri qaytarılmasını asanlaşdıran sənaye standartıdır. Tövsiyə olunan struktur: əvvəlcə refaktorinq ilə commit (yalnız struktur dəyişiklikləri, davranış qorunub), sonra yeni funksionallıq ilə commit.

Refaktorinq üçün Git-flow: ayrıca budaq yaradın, refaktorinq edin, yaşıl testlərə nail olun, commit edin, sonra eyni budaqda yeni funksionallıq əlavə edin. Əgər nə isə səhv gedirsə — refaktorinq dəyişikliklərini həmişə git revert vasitəsilə geri qaytarmaq olar.

# Git-də refaktorinqin mikro-addımları
git checkout -b refactor/extract-payment
# Addım 1: hesablama metodunu ayırın
# ...dəyişikliklər... → tərtib → testlər
git commit -m "refactor: extract calculatePayment method"
# Addım 2: dəyişən adlarını dəyişin
# ...dəyişikliklər... → tərtib → testlər
git commit -m "refactor: rename amount to grossAmount"