Question 1

Dart kodunda kod review zamanı ən çox hansı səhvlərə rast gəlirsən?

Accepted Answer

Bu sual açıq görünür, amma əslində sənin sistemliliyini yoxlayır. Səhvləri təsadüfi sadalamaq zəif təsir bağışlayır; kateqoriyalarla danış və hər kateqoriyaya bir nümunə ver. 1. Async: unudulmuş await — funksiya iş bitmədən qayıdır və xəta try/catch-dən yan keçir. Ən çox void qaytaran metodlarda olur, çünki analyzer default konfiqurasiyada susur. 2. Null safety: ! ilə analyzer-in susdurulması. ! özü pis deyil, əsassız ! pisdir — onu görəndə "bu dəyərin null olmadığını nə zəmanətləyir?" soruşuram; cavab yoxdursa, ?./??/promotion təklif edirəm. 3. Kolleksiyalar: == ilə siyahı müqayisəsi, iterasiya zamanı mutasiya, lazy Iterable-in iki dəfə keçilməsi. 4. Ədədlər: pulun double-da saxlanması və / ilə ~/ qarışdırılması. 5. Ömür: await-dən sonra artıq ləğv olunmuş obyektə toxunmaq, StreamSubscription-ın cancel edilməməsi. Sonda bir cümlə ilə mövqeyini göstər: "Bunların çoxunu insan yox, alət tutmalıdır — unawaited_futures, avoid_dynamic_calls və cancel_subscriptions qaydaları ilə. Kod review-da mən dizayn və adlandırmaya baxmaq istəyirəm, await axtarmağa yox."

Question 2

İki List-i və ya iki Map-i necə müqayisə edirsən? Öz sinfin üçün bərabərliyi necə yazırsan?

Accepted Answer

Faktla başla, çünki bu, sualın əsl mövzusudur: Dart-da kolleksiyalar üçün == identiklikdir, ona görə [1, 2] == [1, 2] yalandır. Praktik həllər: package:collection-dan const DeepCollectionEquality().equals(a, b) — iç-içə strukturlar üçün də işləyir; Flutter tərəfində sadə siyahılar üçün listEquals/mapEquals. Testdə isə expect(a, equals(b)) onsuz da elementbəelement müqayisə edir — bu fərqi bilmək faydalıdır, çünki adamlar "testdə işləyir, kodda işləmir" halına çaşır. Öz sinfin üçün: == və hashCode birlikdə override olunur. Qayda: bərabər obyektlərin hashCode-u mütləq bərabər olmalıdır; əks halda obyekt Set-ə iki dəfə düşür və Map-də açar kimi tapılmır. Sahələr üçün Object.hash(a, b), kolleksiya sahəsi üçün Object.hashAll(items). Vacib əlavə (bunu deyən namizəd az olur): hashCode hesablanan sahələr dəyişməz olmalıdır. Obyekti Set-ə atıb sonra sahəsini dəyişsən, o obyekt həmin Set-də "itir" — buna görə dəyər siniflərini final sahələrlə və const konstruktorla yazıram. Alternativ: layihədə çoxlu dəyər sinfi varsa, əl ilə yazmaq əvəzinə kod generasiyası (freezed) və ya Equatable istifadə olunur — amma bunun qiyməti build addımıdır, ona görə kiçik layihədə əl ilə yazmaq da normaldır.

Question 3

late nə vaxt haqlıdır, nə vaxt "kod qoxusu"dur?

Accepted Answer

Əvvəlcə late-in nə etdiyini dəqiq de: o, kompilyatorun "bu sahə mütləq initialize olunmalıdır" yoxlamasını runtime yoxlamasına çevirir. Yəni sən zəmanəti öz üzərinə götürürsən. Haqlı hallar: Lazy hesablama: late final int total = _rows.fold(...) — bahalı hesablama yalnız ilk müraciətdə baş verir və bir dəfə keşlənir. Bu, late-in ən gözəl istifadəsidir. Dövri asılılıq: iki obyekt bir-birinə istinad edir və hər ikisini eyni anda konstruktorda qurmaq mümkün deyil. Framework-ün ömür dövrü: obyekt konstruktorda yox, sonrakı inisializasiya mərhələsində qurulur (Flutter-də initState bu modelə uyğundur). Kod qoxusu olan hallar: late sadəcə ? yazmamaq üçün istifadə olunur — dəyər real olaraq bəzən yoxdursa, tip nullable olmalıdır; late problemi gizlədir, həll etmir. Sahə bir neçə fərqli yerdən təyin olunur — o zaman "nə vaxt hazırdır?" sualının cavabı yoxdur və LateInitializationError vaxt məsələsidir. Mənim qaydam: late yazanda özümdən soruşuram — "bu sahənin oxunmasından əvvəl yazıldığını sübut edə bilirəmmi?" Cavab "əminəm ki, elədir"dirsə, bu kifayət deyil; late final + inisializator, konstruktor parametri və ya nullable tip seçirəm.

Question 4

Böyük komandada unudulmuş await problemini necə həll edərdin?

Accepted Answer

Senior cavabın forması: fərdi diqqət yox, sistem. 1. Alət: analysis_options.yaml-a unawaited_futures (və faydalıdırsa discarded_futures) qaydasını əlavə edirəm və CI-da dart analyze --fatal-infos ilə bloklayıcı edirəm. Bu, problemin 90%-ni birdəfəlik bağlayır. 2. Niyyəti görünən etmək: həqiqətən fire-and-forget lazım olan yerlərdə unawaited(future) yazılır — həm lint susur, həm də oxuyan adam bunun qərar olduğunu görür. Onun yanında mütləq catchError və ya zone handler olmalıdır, əks halda xəta itir. 3. API dizaynı: bu, ən dərin hissədir — asinxron metod void yox, Future<void> qaytarmalıdır. void qaytaran async metod çağıranı await etmək imkanından məhrum edir; belə imzalar kod bazasında "await etmək mümkün deyil" halları yaradır. 4. Mövcud kod bazasına tətbiq: qaydanı birdən açsan yüzlərlə xəbərdarlıq alırsan və hamısı görməzdən gəlinir. Mən modul-modul gedirəm: bir paketdə qaydanı error səviyyəsinə qaldırıram, dart fix ilə mexaniki hissəni düzəldirəm, qalanına baxıram — sonra növbəti paket. Bağlayış: "Belə səhvlər diqqətsizlikdən deyil, dilin await-i məcbur etməməsindən yaranır. Ona görə həll də diqqət çağırışı deyil, konfiqurasiya olmalıdır."

Question 5

Lazy Iterable semantikası nədir və o, production-da hansı problemləri yaradır?

Accepted Answer

Mexanizmi bir cümlə ilə ver: map, where, expand, take hesablamır, sadəcə hesablamanın təsvirini qaytarır; iş yalnız keçid anında (for-in, toList, length, first, fold) baş verir və hər keçiddə yenidən görülür. Production problemləri — konkret olsun: Təkrarlanan bahalı iş: final rows = ids.map(loadFromDb); rows.length; rows.first; — DB-yə iki dəfə gedirsən. Profiler-də səbəbi görmək çətindir, çünki kod "bir dəfə yazılıb". Təkrarlanan yan effekt: map içində log və ya sayğac varsa, rəqəmlər iki dəfə artır. Dəyişən mənbə: Iterable mənbə siyahıya canlı istinad saxlayır; sonradan siyahını dəyişsən, artıq "hesablanmış" kimi düşündüyün nəticə də dəyişir. Bu, ən çətin tapılan variantdır. Gec partlayan xəta: map içindəki throw map sətrində yox, keçid sətrində baş verir — stack trace səni səhv yerə aparır. Qaydam: nəticə bir dəfədən çox istifadə olunacaqsa və ya funksiyadan kənara qaytarılırsa, .toList() ilə materiallaşdırıram; API-də List qaytarmaq Iterable qaytarmaqdan daha az sürpriz yaradır. Əks tərəf (balans göstər): lazy semantika hədiyyədir — böyük fayl və ya Stream üzərində where().take(10) yazanda yalnız lazım olan qədər iş görülür. Yəni məsələ "lazy pisdir" deyil, nəticəni neçə dəfə istifadə etdiyini bilməkdir.

Tələ	Nə baş verir	Düzgün variant
Unudulmuş `await` (fire-and-forget)	Funksiya iş bitmədən qayıdır; xəta `try/catch`-dən yan keçir və unhandled olur	`await repo.save(x);` — qəsdən olarsa `unawaited(...)` + `catchError`; lint: `unawaited_futures`
`!` ilə analyzer-i susdurmaq	Kompilyasiya xətası runtime `Null check operator used on a null value`-ya çevrilir	`?.`, `??`, `if (x != null)` promotion, və ya `late final` — `!` yalnız sübut edilə bilən halda
İterasiya zamanı siyahını dəyişmək	`ConcurrentModificationError` — həm də yalnız bəzi datalarda üzə çıxa bilər	`list.removeWhere(...)` və ya `for (final x in [...list])` (kopya üzərində)
Kolleksiyaları `==` ilə müqayisə etmək	`[1, 2] == [1, 2]` → `false`: `List` üçün `==` identiklikdir, dərin bərabərlik deyil	`const DeepCollectionEquality().equals(a, b)` (package:collection); Flutter-də `listEquals`/`mapEquals`
Lazy `Iterable`-i iki dəfə keçmək	`map`/`where` hər keçiddə yenidən hesablanır — iş iki dəfə görülür, yan effektlər təkrarlanır	Bir dəfə materiallaşdır: `.toList()` / `.toSet()`
`int` bölməsində `/` işlətmək	`7 / 2` → `3.5` (`double`), `List` indeksi kimi işlətsən tip xətası	Tam bölmə üçün `7 ~/ 2` → `3`; pulu minor vahiddə `int` saxla
`late` ilə "sonra doldurarıq"	Oxunma yazılmadan əvvəl olarsa, `LateInitializationError` — kompilyator artıq kömək etmir	Konstruktorda təyin et, ya nullable saxla; `late` yalnız lazy hesablama və dövri asılılıq üçün
Closure-da kölgələnmiş dəyişən	Lokal ad sahəni gizlədir — kod düz görünür, amma heç nəyi dəyişmir	Adları fərqləndir və ya `this.count` ilə açıq yaz; `dart analyze` bəzi halları tutur
`==` ilə `identical` qarışdırmaq	`==` dəyəri, `identical` isə eyni obyekt olub-olmadığını yoxlayır; string-lər üçün nəticələr fərqlənə bilər	Məzmun üçün həmişə `==`; `identical` yalnız cache/canonicalization məsələlərində
`await`-dən sonra ölmüş obyektə toxunmaq	Async iş obyektin ömründən uzun sürür: `Bad state: ... after dispose` və ya səssiz sızma	Hər `await`-dən sonra `if (_disposed) return;`; `dispose()`-da subscription və timer-ləri ləğv et
`double` ilə pul hesablamaq	`0.1 + 0.2 != 0.3`; qəpiklər yığılıb hesabatı pozur	Minor vahiddə `int` (qəpik) və ya `Decimal` paketi; formatlaşdırma yalnız göstərmə anında
`dynamic` ilə tipi "aşmaq"	Bütün yoxlamalar runtime-a keçir; `json['user']['name']` bir gün `NoSuchMethodError` verir	`Object?` + pattern matching və ya model sinfinə parse; lint: `avoid_dynamic_calls`

Klassik Dart tələləri

📚 Mənbələr və sənədlər