Komandada Developer Kimi İşləmək: Git, Code Review, Scrum

"Mən kod yazmağı bilirəm, deməli işə hazıram." Bir çox junior developer belə düşünür — ta ki ilk iş günündə kimsə "branch-ini aç, PR göndər, Jira-da taskı yenilə, standup-da danış" deyənə qədər. Kursda proses sadədir: tapşırıq → kod → bitdi. Şirkətdə isə kod daha böyük bir prosesin yalnız bir hissəsidir. Bu yazıda komandada developer kimi işləmək nə deməkdir — Git iş axını, code review, Scrum və komandalar arası ünsiyyət — sadə dillə və nümunələrlə izah edirik.

Komandada developer kimi işləmək nədir?

Komandada developer kimi işləmək — kodu tək yazmaq deyil, müəyyən edilmiş mühəndislik prosesinin bir hissəsi olmaqdır: tapşırıqlar planlaşdırılır və prioritetləşdirilir, hər dəyişiklik ayrıca branch-də hazırlanır, pull request ilə təqdim edilir, başqa developerlər tərəfindən yoxlanılır, test olunur və yalnız sonra məhsula daxil olur. Texniki bilik başlanğıcdır; bu prosesdə işləmək isə ayrıca bacarıqdır.

Kursda və real layihədə proses

Kursda:

Tapşırıq → Kod yaz → Test et → Bitdi

Real şirkətdə:

Tapşırıq → Planlaşdırma → Branch → Kod → Commit → Pull Request → Code Review → Düzəlişlər → Merge → Test → Deploy

Üstəlik, bütün bunları tək etmirsiniz: frontend developer backend developerlə, backend QA ilə, hamı isə dizayner və məhsul meneceri ilə koordinasiya edir.

1. Git iş axını: "kodu necə göndərim" yox, "necə təhlükəsiz inteqrasiya edim"

İlk öyrənilən əmrlər adətən bunlardır:

git add .
git commit -m "add login"
git push

Bunlar vacibdir, amma komandada kifayət etmir. Komandada hər iş ayrıca branch-də aparılır ki, developerlər bir-birinə mane olmadan paralel işləyə bilsin:

main
├── feature/login
├── feature/profile
└── feature/payment

Pull request nədir?

İşi bitirdikdən sonra branch-i göndərib pull request (PR) açırsınız — "bu dəyişikliyi əsas koda qatmağı təklif edirəm" deməkdir. Yaxşı PR-da bunlar aydın olur:

• Nə dəyişdirilib?
• Niyə dəyişdirilib?
• Necə test edilib?
• Reviewer nəyə xüsusi diqqət etməlidir?

Merge conflict nədir?

İki developer eyni kod hissəsini dəyişdikdə Git hansının düzgün olduğunu özü həll edə bilmir:

<<<<<<< HEAD
const title = "Dashboard";
=======
const title = "User Dashboard";
>>>>>>> feature/profile

Burada məqsəd bir hissəni silmək deyil — hər iki dəyişikliyin məntiqini anlamaq, düzgün variantı seçmək və sonra yenidən test etməkdir. Git biliyi ilə Git mədəniyyəti arasındakı fərq məhz buradadır.

2. Code review: kodun müəllifi olmaq kifayət deyil

PR açdıqdan sonra başqa developer kodunuzu oxuyur və suallar verir:

• Kod tələb olunan funksiyanı yerinə yetirirmi?
• Lazımsız mürəkkəblik varmı?
• Adlar aydındırmı?
• Kənar hallar (edge cases) nəzərə alınıbmı?
• Testlər kifayətdirmi?

Google-un açıq code review təcrübələri code review-un əsas məqsədini kod bazasının ümumi sağlamlığını zamanla yaxşılaşdırmaq kimi təsvir edir. Yəni bu, səhv axtarmaq yox, keyfiyyəti qorumaq və bilik paylaşmaq mexanizmidir.

Rəy şəxsi tənqid deyil. "Pis kod yazmısan" yox, "bu yanaşma burada əlavə mürəkkəblik yaradır, daha sadə variant belə ola bilər". Ən sağlam münasibət: "koduma hücum edilir" yox, "kodum təkmilləşdirilir". Başqalarının kodunu review etmək də öyrənmənin ən sürətli yollarındandır.

3. Scrum: şirkətdə bir iş həftəsi necə keçir?

Səhər kompüteri açıb "bu gün nə yazım?" deyə düşünmürsünüz — iş planın içindədir. Scrum Guide işi sprint adlanan qısa, sabit müddətli dövrlərdə təşkil etməyi təsvir edir.

Sprint məqsədi nümunəsi: "İstifadəçinin sistemə qeydiyyatdan keçməsini təmin etmək." Bu məqsəd kiçik tapşırıqlara bölünür:

AUTH-101 → Qeydiyyat interfeysi
AUTH-102 → Qeydiyyat API-si
AUTH-103 → Forma validasiyası
AUTH-104 → E-poçt təsdiqi
AUTH-105 → QA testi

Sprint planlaşdırması

Komanda sprintin məqsədini, hansı işlərin görüləcəyini və necə görüləcəyini müəyyən edir. Developer yalnız taskı icra etmir — onun məhsula hansı dəyəri verdiyini də anlamalıdır.

Gündəlik qısa görüş (Daily Scrum)

Scrum Guide-a görə bu, 15 dəqiqəlik görüşdür və məqsədi sprint məqsədinə doğru irəliləyişi yoxlamaq və planı uyğunlaşdırmaqdır. Praktikada belə səslənir:

Dünən: Login API-ni bitirdim. Bu gün: Frontend inteqrasiyası. Maneə: Refresh token davranışını backend ilə dəqiqləşdirməliyəm.

Tapşırıq statusları

TODO → IN PROGRESS → CODE REVIEW → QA → DONE

Taskın uzun müddət "IN PROGRESS"də qalması komanda üçün görünən siqnaldır. Peşəkar developer "bu deadline-a çatmayacağam" deməkdən qorxmur — problemi vaxtında bildirmək gizlətməkdən qat-qat yaxşıdır.

4. Komandalar arası ünsiyyət və API müqaviləsi

Real məhsulda rollar bir-birindən asılıdır: UI/UX dizayner interfeysi planlaşdırır, frontend onu qurur, backend API və biznes məntiqini hazırlayır, QA yoxlayır. Bu rolların hər birini IT sahəsində peşələr yazımızda izah etmişik.

Frontend və backend arasındakı əsas razılaşma API müqaviləsidir. Məsələn:

PATCH /api/users/profile

Frontend developer bilməlidir: hansı metod, hansı request body, hansı cavab strukturu, xəta formatı necədir, autentifikasiya lazımdırmı. Müqavilə olmasa, hər iki tərəf ayrılıqda işləyən, amma birlikdə işləməyən kod yaza bilər.

5. Sənədləşmə: layihənin ortaq yaddaşı

Bütün bilgi bir developerin başında qalsa, o məzuniyyətə gedəndə komanda dayanır. README-də adətən bunlar olur: layihənin qurulması, mühit dəyişənləri, lokalda işə salma, API sənədləri, testlər, deploy. Yaxşı sənədləşmə yeni gələn developerin bir neçə gündə yox, bir neçə saatda işə başlamasına imkan verir.

Evdə kod yazmaq vs real layihədə işləmək

Evdə və ya kursda	Real layihədə
Tək işləyirsiniz	Komanda ilə işləyirsiniz
Birbaşa kod yazırsınız	Tapşırıq və prioritetə görə işləyirsiniz
main-ə birbaşa yazırsınız	Branch və PR iş axını
Kodu yalnız siz oxuyursunuz	Kod code review-dan keçir
Deadline çevikdir	Sprint və deadline var
Arxitekturanı siz seçirsiniz	Mövcud arxitekturaya uyğunlaşırsınız
Sənədləşmə ikinci plandadır	Sənədləşmə işin bir hissəsidir

Junior üçün bu niyə vacibdir?

Müsahibədə "React bilirəm" demək vacibdir, amma işəgötürən bunları da soruşa bilər: branch və PR ilə işləmisinizmi? Code review almısınızmı? Merge conflict həll etmisinizmi? Deadline ilə işləmisinizmi? Texniki problemi komandaya izah edə bilirsinizmi? Şirkət yalnız kod yazan yox, komandanın prosesinə qoşula bilən developer axtarır. Müsahibənin texniki tərəfi üçün junior developer müsahibə sualları yazımıza baxın.

Bu prosesi işə başlamazdan əvvəl necə yaşamaq olar?

Öz layihələrinizdə də branch və PR istifadə edin, açıq mənbə layihələrinə töhfə verin. Daha strukturlu yol isə real iş ritmini təkrarlayan proqramdır. Bunu Devlab komandası sizin üçün qura bilər: Devlab-ın təcrübə proqramlarında hər həftə tələbləri və deadline-ı olan real biznes tapşırığı alırsınız, həllinizi GitHub linki ilə təhvil verirsiniz, sahə mütəxəssisi olan mentor code review aparır və siz rəyə görə düzəliş edirsiniz. Həftəlik canlı görüşlər, müsahibə məşqləri və məsuliyyət üzrə qiymətləndirmə iş mühitinin ritmini proqram boyu saxlayır.

Nəticə

Proqramlaşdırmanı öyrənmək ilə komandada developer kimi işləməyi öyrənmək fərqli şeylərdir. Real layihədə kod Git iş axını ilə hazırlanır, code review-dan keçir, sprint planı daxilində yaranır, API müqaviləsi ilə digər komandalara bağlanır və sənədləşmə ilə qorunur. Bu prosesi əvvəlcədən tanıyan junior işə ilk gündən daha hazır başlayır.

Real iş ritmini proqram boyu yaşamaq istəyirsinizsə, pulsuz qeydiyyatdan keçin. Sualınız varsa, komandamızla əlaqə saxlayın.

Tez-tez verilən suallar

Junior developerdən Git-i nə səviyyədə bilməsi gözlənilir?

Branch yaratmaq, commit etmək, pull request açmaq, sadə merge conflict-ləri həll etmək və rəydən sonra dəyişiklik göndərmək. Mürəkkəb əmrlər işdə öyrənilir.

Scrum hər şirkətdə istifadə olunurmu?

Xeyr, bəzi komandalar Kanban və ya öz proseslərini istifadə edir. Amma əsas ideyalar — kiçik tapşırıqlar, şəffaf statuslar, müntəzəm koordinasiya — demək olar ki, hər yerdə var.

Code review-da rəyə razı deyiləmsə nə etməliyəm?

Fikrinizi nəzakətlə və arqumentlə izah edin: "bu variantı seçdim, çünki...". Məqsəd mübahisədə qalib gəlmək yox, ən yaxşı həllə gəlməkdir. Əmin deyilsinizsə, rəyi qəbul edib sonra öyrənmək də yaxşı yanaşmadır.

Tək işləyən developer bu prosesləri necə öyrənə bilər?

Öz layihələrində komanda prosesini simulyasiya etməklə, açıq mənbə layihələrinə töhfə verməklə və ya real tapşırıq və code review olan təcrübə proqramına qoşulmaqla.