Tutorial Yoxsa Real Layihə? Hansı Daha Tez İnkişaf Etdirir

Bu ay on tutorial bitirmisiniz: React ilə alış-veriş səbəti, Node.js ilə blog, Python ilə hava proqnozu. Hamısı işləyir. Amma müsahibədə "bu layihədə ən çətin qərarınız hansı idi?" sualını eşidəndə susursunuz — çünki qərarları siz yox, video müəllifi verib. Bu yazıda tutorial yoxsa real layihə sualını müqayisə edirik: hər birinin nə verdiyini, harada işlədiyini və on səthi tutorialın niyə bir dərin layihəyə uduzduğunu göstəririk.

Qısa cavab: Tutoriallar yeni texnologiya ilə tanış olmaq üçün sürətli və faydalıdır, amma qərar vermə, debugging və kənar halları idarə etmə bacarığı qurmur. Bir dərin real layihə — tələbləri, xəta halları, testləri və rəyi olan — bu bacarıqları məcburən formalaşdırır və müsahibədə danışmaq üçün material verir. Ən yaxşı nisbət: az tutorial, çox real layihə.

Dilemma: niyə tutoriallar bu qədər cəlbedicidir?

Tutorial rahatdır: addımlar bəllidir, nəticə zəmanətlidir, bir-iki saata "bitmiş layihə" alırsınız. Bu, irəliləyiş hissi verir. Problem ondadır ki, bu hiss çox vaxt yanıldıcıdır. Videoda müəllif problemləri artıq həll edib; siz yalnız həllin təkrarını görürsünüz. Psixologiyada bu fenomen "tanışlıq illüziyası" kimi tanınır: gördüyümüz şeyi tanıyırıq və onu bacardığımızı zənn edirik.

Müqayisə cədvəli

Meyar	10 səthi tutorial	1 dərin real layihə
Vaxt	Hər biri bir neçə saat	Bir neçə həftə
Qərarları kim verir	Video müəllifi	Siz
Qarşılaşılan problemlər	Əvvəlcədən həll olunub	Gözlənilməz, real
Debugging təcrübəsi	Minimal	Çox
Kənar hallar	Adətən atlanır	Məcburən həll olunur
Test və keyfiyyət	Nadir hallarda	Layihənin bir hissəsi
Müsahibə üçün material	"Bunu da etdim" siyahısı	15 dəqiqəlik dərin söhbət
Portfolio dəyəri	Aşağı — hamıda var	Yüksək — unikal kontekst
Tanışlıq	Bir çox texnologiya ilə	Bir neçə texnologiyada dərinlik

Tutorialların üstün və zəif tərəfləri

Üstün tərəflər:

• Sürətli tanışlıq: yeni kitabxana və ya alətin əsas məntiqini tez görmək
• Nümunə: təcrübəli developerin kodu necə strukturlaşdırdığını görmək
• Motivasiya: tez nəticə başlanğıcda həvəs verir

Zəif tərəflər:

• Qərar yoxdur: "niyə belə?" sualını heç vaxt özünüzə vermirsiniz
• Uğursuzluq yoxdur: xətalarla mübarizə — əsl öyrənmə — atlanır
• Hamı eyni şeyi qurur: portfolio fərqlənmir
• Asılılıq: video olmadan boş fayl qarşısında ilişmək

Dərin layihənin üstün və zəif tərəfləri

Üstün tərəflər:

• Qərar vermə: arxitektura, data modeli, kitabxana seçimi — hamısı sizindir
• Debugging: real xətalar real araşdırma tələb edir
• Bütöv mənzərə: tələbdən deploy-a qədər tam dövrə
• Hekayə: müsahibədə danışmaq üçün konkret problemlər və həllər

Bu yanaşma işə qəbul araşdırmaları ilə də uyğundur: Schmidt və Hunter-in meta-analizi (Psychological Bulletin, 1998) iş nümunəsini gələcək performansın ən güclü proqnozlaşdırıcıları arasında göstərir — dərin layihə məhz belə bir iş nümunəsidir.

Zəif tərəflər:

• Çətin və yavaş: irəliləyiş hissi gec gəlir
• İlişib qalma riski: rəy olmadan bəzən saatlarla bir problemin üzərində qalmaq
• Yarımçıq qalma riski: böyük hədəf plansız olduqda bitməyə bilər

Real nümunə: eyni texnologiya, iki yol

Yol A: React ilə on tutorial. Hər birində komponent, state və API sorğusu var. Nəticə: on sadə tətbiq, hamısı "uğurlu ssenari"də işləyir.

Yol B: React ilə bir layihə — kiçik komandaların tapşırıqlarını idarə edən panel. Burada eyni anlayışlar var, amma üstəlik: rollar və icazələr (kim nəyi görür?), formaların validasiyası, server xəta qaytaranda nə göstərilir, yüzlərlə tapşırıq olanda siyahı necə yavaşlamır, eyni anda iki nəfər dəyişiklik edəndə nə olur, testlər.

Yol B-də siz on tutorialda heç vaxt qarşılaşmayacağınız on problemlə üzləşirsiniz. Müsahibədə "ən çətin qərarınız" sualına artıq cavabınız var.

Hansı halda hansını seçməli?

Tutorial seçin, əgər:

• Yeni texnologiya ilə ilk dəfə tanış olursunuzsa
• Konkret bir anlayışı (məsələn, autentifikasiya axını) görmək istəyirsinizsə
• Bir neçə saatlıq sürətli giriş lazımdırsa

Dərin layihə seçin, əgər:

• Əsasları artıq bilirsinizsə
• Portfolio və müsahibə üçün material lazımdırsa
• "Tutorial hell"də ilişdiyinizi hiss edirsinizsə — bu vəziyyəti öyrənirəm amma irəliləmirəm yazımızda ətraflı açmışıq

Ən effektiv nisbət: hər yeni texnologiya üçün bir qısa tutorial, ardınca həmin texnologiyanı dərin layihədə istifadə etmək.

Tutorialdan dərin layihəyə necə keçmək olar?

1. Tutorialı bitirin və bağlayın. Sonra eyni şeyi videosuz yenidən qurun.
2. Konteksti dəyişin. "Blog" yerinə "kiçik kitabxananın kitab qeydiyyatı".
3. Üç real tələb əlavə edin. Rollar, validasiya, xəta halları.
4. Test yazın. Ən azı əsas axınlar üçün.
5. Deploy edin və README yazın. "Verdiyim qərarlar" bölməsi ilə.
6. Rəy alın. Kodunuzu təcrübəli birinə göstərin.

Layihə ideyaları üçün portfolio üçün 10 layihə ideyası yazımıza baxın.

Dərin layihədə ilişməmək üçün

Dərin layihənin ən böyük riski — rəysiz ilişib qalmaq və yarımçıq qoymaqdır. Bunun qarşısını almaq üçün iki şey lazımdır: layihəni həftəlik mərhələlərə bölmək və müntəzəm kənar rəy almaq. Bunu Devlab komandası sizin üçün qura bilər: Devlab-ın təcrübə proqramlarında hər həftə real biznes probleminə əsaslanan tapşırıq — yəni addımları yox, tələbləri verilmiş dərin iş — alırsınız və sahə mütəxəssisi olan mentor onu yoxlayır. 13 modul boyunca tapşırıqlar tədricən mürəkkəbləşir və yekun layihə ilə bitir.

Dərin layihə üçün 4 həftəlik plan

Dərin layihənin ən böyük riski — böyük hədəfin yarımçıq qalmasıdır. Onu həftəlik mərhələlərə bölün:

Həftə	Hədəf	Nəticə
1	Minimal işləyən versiya: əsas axın başdan-sona	Demo edilə bilən ilk versiya
2	Real tələblər: rollar, validasiya, xəta halları	"Uğurlu ssenari"dən kənar davranış
3	Keyfiyyət: testlər, refaktorinq, performans	Etibarlı kod
4	Təqdimat: deploy, README, rəy və düzəliş	Portfolioya hazır layihə

Hər həftənin sonunda layihə "göstərilə bilən" vəziyyətdə olsun. Mükəmməl, amma yarımçıq layihədən sadə, amma bitmiş layihə həmişə güclüdür.

Tutorialı aktiv izləmək: video zamanı nə etməli?

Tutorialdan tamamilə imtina etmək lazım deyil — onu passivdən aktivə çevirmək lazımdır:

• Videonu dayandırın və proqnoz verin: "Müəllif indi nə yazacaq?" — sonra yoxlayın
• Kodu kopyalamayın, yazın: hər sətiri öz əlinizlə
• Kiçik dəyişiklik edin: müəllifin kodunu dəyişib nəticəni müşahidə edin
• Xəta yaradın: qəsdən bir şeyi sındırın və xəta mesajını oxuyun
• Sonda xülasə yazın: üç cümlə ilə nə öyrəndiniz

Bu üsullar tutorialı "baxmaq"dan "məşq etmək"ə çevirir və tanışlıq illüziyasını azaldır.

Dərin layihədə ilişəndə nə etməli?

Real problemlə ilişmək dərin layihənin normal hissəsidir — və əsl öyrənmə məhz orada baş verir. Faydalı ardıcıllıq:

1. Xəta mesajını diqqətlə oxuyun — çox vaxt cavab oradadır
2. Problemi kiçildin — ən sadə nümunədə təkrarlayın
3. Sənədləşməyə baxın — tutorial yox, rəsmi sənəd
4. 30 dəqiqə qaydası — irəliləmirsə, soruşun: icma, mentor, həmkar
5. Həlli qeyd edin — növbəti dəfə eyni problemlə vaxt itirməmək üçün

Bu dövrə özü də müsahibədə danışmaq üçün dəyərli materialdır: "Bu xətanı belə tapdım və belə həll etdim."

Müsahibəyə necə təsir edir?

Müsahibədə ən çox fərqləndirən suallar "ən çətin problem nə idi?" və "yenidən etsəydiniz nəyi dəyişərdiniz?" sualıdır. On tutorial bu suallara cavab vermir — çünki çətin problemləri müəllif həll edib. Dərin layihə isə hər iki suala hazır cavab verir və müsahibəçini sizin layihənizlə 10–15 dəqiqə maraqlandıra bilir.

Dərin layihə ideyaları: sahə üzrə

• Frontend: rolları, filtrləri və real vaxt yeniləmələri olan komanda tapşırıqları paneli
• Backend: audit izi, rollar və fon tapşırıqları olan sifariş idarəetmə API-si
• Data Analytics: real satış datası üzərində kohort, funnel və A/B test təhlili + dashboard
• Data Science: izah olunan risk proqnozu modeli, sadə API kimi təqdim olunmuş
• AI Engineering: mənbə göstərən, qiymətləndirilmiş və qoruyucu qaydaları olan RAG köməkçisi

Hər birində ən azı üç "real" element olsun: istifadəçi və ya biznes konteksti, kənar halların idarəsi və ölçülən keyfiyyət (test və ya qiymətləndirmə).

Tutorial və dərin layihəni birləşdirməyin praktik qaydası

Sadə nisbət işləyir: hər yeni anlayış üçün ən çox bir qısa tutorial, ardınca həmin anlayışı öz layihənizdə ən azı üç fərqli şəkildə istifadə etmək. Məsələn, autentifikasiya haqqında video izlədinizsə, onu layihənizdə qeydiyyat, giriş və rol yoxlaması üçün tətbiq edin. Bu qayda tutorialı "son nöqtə"dən "başlanğıc nöqtə"yə çevirir və hər videonun dəyərini bir neçə dəfə artırır.

Nəticədə portfoliosunda bir-iki dərin layihə olan namizəd, onlarla tutorial layihəsi olan namizəddən daha çox diqqət çəkir — çünki onun hər layihəsinin arxasında real qərarlar, real xətalar və real öyrənmə hekayəsi dayanır. İşəgötürən də məhz bu hekayəni eşitmək istəyir.

Bu, həm öyrənmə, həm də karyera üçün ən etibarlı yoldur.

Nəticə

Tutorial yoxsa real layihə sualının cavabı "hər ikisi, amma düzgün nisbətdə"dir. Tutorial tanışlıq verir; dərin layihə isə qərar vermə, debugging və keyfiyyət bacarığı qurur və işəgötürənə real sübut göstərir. Bir dərin problemi həll etmək on səthi tutorialdan daha çox öyrədir — çünki çətin hissələri sizin yerinizə heç kim həll etmir.

Tutorialdan real tapşırıqlara keçmək istəyirsinizsə, pulsuz qeydiyyatdan keçin və 3 real tapşırıq nümunəsinə baxın. Sualınız varsa, komandamızla əlaqə saxlayın.

Tez-tez verilən suallar

"Tutorial hell" nədir?

Bir tutorialdan digərinə keçib, heç vaxt öz başına layihə qurmamaq vəziyyətidir. Hər tutorial irəliləyiş hissi verir, amma müstəqil bacarıq formalaşmır.

Neçə tutorial kifayətdir?

Sayı yox, məqsədi vacibdir. Yeni texnologiya üçün bir-iki tutorial kifayətdir; ondan sonra öyrənməni öz layihənizdə davam etdirin.

Dərin layihə nə qədər böyük olmalıdır?

Bir neçə həftəlik iş və real tələblər — rollar, xəta halları, testlər, deploy. Çox böyük hədəf yarımçıq qalır; həftəlik mərhələlərə bölün.

Tutorial layihəsini portfolioya qoymaq olarmı?

Olar, amma onu dəyişdirib genişləndirdikdən sonra. Dəyişdirilməmiş tutorial layihəsi digər namizədlərinkindən fərqlənmir.