Proqramın düzgün işləməsi

1. Proqramçının vəzifələri

Çox zaman yeni başlayan proqramçılar proqramçının iş mahiyyətini təcrübəli proqramçılar kimi təsəvvür etmir.

Yeni başlayanlardan tez-tez «Proqram işləyir, sizə daha nə lazımdır?» kimi bir ifadə eşitmək olar. Amma təcrübəli proqramçı bilir ki, «düzgün işləyir» — bu sadəcə proqram üçün tələblərdən biridir, həm də ən vacibi deyil!

Kodun oxunaqlılığı

Əsas məsələ — proqramın kodunun digər proqramçılara aydın olmasıdır. Bu düzgün işləyən proqramdan daha vacibdir. Çox daha vacibdir.

Əgər sizdə düzgün işləməyən bir proqram varsa, onu düzəldə bilərsiniz, amma kodu anlaşılmayan bir proqramınız varsa, onunla heç nə edə bilməzsiniz.

Sadəcə hər hansı kompilyasiya olunmuş proqramı götürün, məsələn, notepad (bloknot) və onun fon rəngini qırmızıya dəyişin. Sizdə işləyən proqram var, amma anlaşılan proqram kodu yoxdur: belə bir proqrama dəyişikliklər etmək qeyri-mümkündür.

Klassik nümunə — Microsoft-un Windows-dan Pinball oyununu çıxarması, çünki onu 64-bit arxitekturaya portlaya bilmədilər. Halbuki onların hətta onun kodu da var idi. Sadəcə onlar yazılmış kodun necə işlədiyini başa düşə bilmədilər.

Bütün istifadə ssenarilərinin nəzərə alınması

Proqram üçün ikinci ən vacib tələb — onun işləmə ssenarilərinin hamısının nəzərə alınmasıdır. Çox vaxt hər şey göründüyündən bir az daha çətin olur.

Başlayan proqramçının öz proqramında SMS göndərməsini necə görməsi:

Peşəkar proqramçının bunu necə görməsi:

Və «düzgün işləmək» — adətən çoxsaylı ssenarilərdən sadəcə biridir. Məhz buna görə də bir çox yeni başlayanlar CodeGym-də tapşırıqların validatoruna şikayət edirlər: 10 ssenaridən biri işləyir və yeni başlayan proqramçı bunun kifayət olduğunu düşünür.

2. Gözlənilməz hallar

Hər hansı bir proqram işləyərkən gözlənilməz hallar baş verə bilər.

Məsələn, bir faylı yaddaşa vermək istəyirsiniz, ancaq diskdə yer yoxdur. Və ya proqram məlumatı yaddaşa yazmağa çalışır, amma yaddaş kifayət deyil. Və ya internetdən şəkil yükləyirsiniz, amma yükləmə zamanı əlaqə kəsilir.

Proqramçı (proqramın müəllifi) hər bir gözlənilməz halı a) öncədən proqnozlaşdırmaq, b) bu hal üçün proqramın necə işləməli olduğunu müəyyənləşdirmək, c) mümkün qədər arzu olunan həll variantını proqramlaşdırmaq məcburiyyətindədir.

Bu səbəbdən uzun müddət proqramların davranışı çox sadə idi: əgər proqramda xəta baş verirdisə, proqram bağlanırdı. Və bu kifayət qədər yaxşı yanaşma idi.

Təsəvvür edin ki, sənədi diskə yazdırmaq istəyirsiniz və yazdırma zamanı müəyyən olur ki, diskdə yer kifayət deyil. Proqramın hansı davranış variantı daha çox sizin xoşunuza gələrdi:

• Proqram bağlandı
• Proqram işləməyə davam etdi, amma fayl yaddaşa verilmədi.

Yeni başlayan bir proqramçıya ikinci variant daha yaxşı görünə bilər, axı proqram işləyir. Amma əslində belə deyil.

Təsəvvür edin ki, 3 saat Word-də sənəd yazırsınız, halbuki işin ikinci dəqiqəsində artıq məlum idi ki, proqram sənədi diskə yaddaşa verə bilmir. İki dəqiqə işinizi itirmək daha yaxşıdır, yoxsa üç saat?

Əgər proqram lazım olanı edə bilmirsə, bağlanması, hər şeyin qaydasında olduğunu göstərməyə çalışmaqdan daha yaxşıdır. Proqramın öz-özünə aradan qaldıra bilmədiyi bir problem baş verdikdə ən yaxşısı dərhal istifadəçini problem haqqında məlumatlandırmaqdır.

3. İstisnaların yaranma tarixçəsi

Qeyri-adi vəziyyətlər təkcə proqramlarda deyil, həm də bir proqramın daxilində - metodların daxilində olur. Məsələn:

• Metod faylı diskə yazmaq istəyir, amma yer yoxdur.
• Metod dəyişkənə funksiya çağırmaq istəyir, amma dəyişkən == null.
• Metodda sıfıra bölmə baş verdi.

Bu halda çağırılan metod bəlkə də vəziyyəti düzəldə bilərdi (alternativ ssenari icra edə bilərdi), əgər hansı problemin çağırılan metodun iş vaxtı baş verdiyini bilsəydi.

Əgər biz faylı diskə saxlamağa çalışırıqsa və belə bir fayl artıq mövcuddursa, istifadəçidən sadəcə faylı yenidən yazmaq üçün təsdiq istəyə bilərik. Əgər diskdə yer yoxdursa, istifadəçiyə bildiriş çıxarıb başqa bir disk seçməyi təklif edə bilərik. Amma proqramın yaddaşı bitibsə — qəza ilə başa çatacaq.

Bir zamanlar proqramçılar bu məsələ üzərində düşünürdülər və belə bir həll tapdılar: bütün metodlar/funksiyalar işlərinin nəticəsi kimi xəta kodu qaytarmalıdırlar. Əgər funksiya mükəmməl işləyibsə, o 0 qaytarırdı, əks halda isə xəta kodunu (sıfır olmayan) qaytarırdı.

Bu yanaşmada səhvlərlə işləmək üçün proqramçıya demək olar ki, hər bir funksiyanın çağırılmasından sonra yoxlama əlavə etməli idi ki, funksiya səhvlə bitib-bitməyib. Proqram kodları əhəmiyyətli dərəcədə böyüyür və belə görünürdü:

File file = new File("ca:\\note.txt");
file.writeLine("Mətn");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Mətn");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

Bundan əlavə, çox vaxt funksiya “hiss edirdi” ki, bir xəta baş verib, amma nə edəcəyini bilmirdi: çağırdığı funksiyaya xətanı qaytarmalı olurdu, o da bunu öz çağırıcısına qaytarırdı və s.

Böyük bir proqramda onlarla funksiyanın çağırış zənciri - adi haldır: bəzən hətta yüzlərlə funksiyanın dərin çağırışını da görmək olar. Və xətanın kodunu aşağıdan ən üstdəki funksiyaya ötürmək lazım olur. Əgər bu yolda hər hansı bir funksiya çıxış kodunu nəzərdən keçirməzsə, səhv itir.

Bu yanaşmanın digər bir mənfi tərəfi odur ki, əgər funksiyalar xəta kodunu qaytarırsa, artıq onlar işlərinin nəticəsini qaytara bilmirdilər. Hesablamaların nəticəsini ötürmək üçün referans-parametrlərdən istifadə etmək lazım olurdu. Bu kodu daha da qarışıq etdi və xətaların sayını daha da artırdı.