İşləyən sistemi dəyişmək boş fayl yazmaq deyil

Yeni sistem yazanda hər şey daha rahat görünür.

Fayl boşdur. Qaydaları sən müəyyən edirsən. Hələ heç kim həmin sistemə öyrəşməyib.

Amma real layihələrdə çox vaxt belə olmur.

Əksər dəyişiklik artıq işləyən bir sistemin üzərinə gəlir. Kimsə hər gün həmin sistemdən istifadə edir. Başqa bir servis ona bağlıdır. Bazada illərdir məlumat var.

Ona görə mənə dəyişiklik gələndə ilk düşündüyüm şeylərdən biri budur: bu, tamamilə yeni bir şeydir, yoxsa artıq işləyən prosesə toxunur?

“Kiçik dəyişiklik” həmişə kiçik olmur

Ticket-də bəzən belə yazılır:

• “Sadəcə bir field əlavə etmək lazımdır.”
• “Sadəcə statusu dəyişək.”
• “Bu qaydanı bir az yumşaldaq.”

Ekranda bunlar həqiqətən kiçik dəyişiklik kimi görünə bilər.

Amma kodu dəyişməzdən əvvəl başqa suallar ortaya çıxır:

• Bu field əvvəllər yox idisə, köhnə məlumatlarla nə olacaq?
• Status dəyişəndə hansı proseslərə təsir edəcək?
• Qaydanı yumşaltsaq, əvvəllər keçməyən hansı əməliyyatlar artıq keçəcək?
• Bu dəyişiklik başqa servislərə, hesabatlara və ya ödəniş prosesinə təsir edir?
• Köhnə məlumatlar dəyişiklikdən sonra hələ də düzgün qalacaq?

Bunları düşünmədən kod yazmaq çox asandır.

Çətin olan isə dəyişiklikdən sonra sistemin başqa bir yerində səssizcə səhv yaranmamasını təmin etməkdir.

Mən əvvəl nəyin pozulmayacağını düşünürəm

Yeni feature-a başlamazdan əvvəl mövcud prosesə baxmağa çalışıram.

• İndi necə işləyir?
• Kim bundan istifadə edir?
• Hansı kod və proseslər bundan asılıdır?
• Nəyi dəyişmək olar, nəyi isə toxunmadan saxlamaq lazımdır?
• Ən vacibi — dəyişiklikdən sonra əvvəlki məlumatlar və proseslər hələ də düzgün işləyəcəkmi?

Xüsusilə bank sistemlərində bunu daha çox hiss edirsən.

Orada işləyən bir prosesi pozmaq sadəcə “regression” yaratmaq deyil. İnsanların güvəndiyi bir prosesi dəyişməkdir.

Amma bu, yalnız bank sistemlərinə aid deyil.

Kimsə hər gün eyni sistemdən istifadə edirsə, sənin yazdığın dəyişiklik onun gündəlik işinə də təsir edir.

Bəzən bunu hiss etmədən işi asanlaşdırırsan.

Bəzən isə kiçik görünən bir dəyişiklik başqa yerdə problem yaradır.

Yaxşı dəyişiklik mənim üçün nədir?

Məncə, yaxşı dəyişiklik yalnız yeni tələbi yerinə yetirən dəyişiklik deyil.

Həm yeni tələbi həll etməli, həm də mövcud sistemi qorumalıdır.

Məsələn:

• Yeni davranış aydın olmalıdır.
• Köhnə davranış təsadüfən pozulmamalıdır.
• Xəta baş verəndə sistem səssizcə yanlış məlumat yaratmamalıdır.
• Dəyişikliyin səbəbi gələcəkdə kodu oxuyan developer üçün başa düşülən olmalıdır.

Kod yazmaq əlbəttə ki, vacibdir.

Amma işləyən sistemin içinə kod əlavə etmək boş faylda yeni kod yazmaqdan fərqlidir.

Çünki orada artıq istifadəçilər, məlumatlar, digər servislər və formalaşmış biznes qaydaları var.

Ona görə mənim üçün proses belədir:

• Əvvəl mövcud prosesi başa düş.
• Sonra dəyişikliyin nəyə təsir edə biləcəyini müəyyən et.
• Daha sonra kod yaz.

Məncə, software engineering-in vacib tərəflərindən biri də məhz budur: yeni bir şey əlavə edərkən, artıq işləyən şeyi təsadüfən pozmamaq.