Real Layihədə İşləmək Nə Deməkdir? Git, Agile, Code Review və Komanda İşi

Bir çox junior proqramçı belə düşünür:

“Mən kod yazmağı bilirəm, deməli artıq işə hazıram.”

Əslində isə proqramlaşdırma biliyi ilə real proqram təminatı mühitində işləmək bacarığı eyni şey deyil.

Kursda və ya evdə layihə hazırlayarkən proses adətən sadə olur:

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

Real şirkətdə isə proses daha fərqlidir:

Tapşırıq → Planlaşdırma → Branch → Kod → Commit → Pull Request → Code Review → Dəyişikliklər → Merge → Test → Deploy

Üstəlik, bütün bunları tək etmirsən.

Frontend developer Backend developer ilə, Backend developer QA ilə, developer isə UI/UX dizaynerlə koordinasiya edir. Tapşırıqlar prioritetləşdirilir, deadline-lar müəyyən olunur və yazılan kod digər developer-lər tərəfindən nəzərdən keçirilir.

Yəni real layihədə developer olmaq yalnız kod yazmaq deyil.

Bu, müəyyən edilmiş mühəndislik prosesinin bir hissəsi olmaqdır.

---

1. Git və Git Flow mədəniyyəti

Git öyrənərkən ilk öyrəndiyimiz əmrlər adətən bunlardır:

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

Bunları bilmək vacibdir. Amma komanda daxilində işləmək üçün kifayət etmir.

Real layihədə əsas sual:

“Kodu Git-ə necə göndərim?” yox, “dəyişikliklərimi komandanın iş prosesinə necə təhlükəsiz inteqrasiya edim?” olur.

Komanda daxilində müxtəlif branch-lərdən istifadə etməklə developer-lərin bir-birinin işinə mane olmadan paralel işləməsi mümkün olur.

Məsələn:

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

Bir developer login sistemi üzərində işləyərkən digər developer profil səhifəsini hazırlaya bilər.

Git workflow-un məqsədi sadəcə branch yaratmaq deyil. Əsas məqsəd kod dəyişikliklərini idarə olunan, izlənilə bilən və təhlükəsiz şəkildə layihəyə inteqrasiya etməkdir.

Pull Request nədir?

Feature üzərində işini bitirdikdən sonra branch-i push edib Pull Request açırsan.

Proses təxminən belə görünür:

feature/login
      ↓
Pull Request
      ↓
Code Review
      ↓
Changes
      ↓
Approved
      ↓
Merge

Pull Request komanda üzvlərinə yazılmış kodu nəzərdən keçirmək, suallar vermək və dəyişikliklər haqqında müzakirə aparmaq imkanı verir.

Yaxşı Pull Request-də ən azı bunlar aydın olmalıdır:

• Nə dəyişdirilib?
• Niyə dəyişdirilib?
• Problemin həlli necə həyata keçirilib?
• Necə test edilib?
• Reviewer nəyə xüsusi diqqət etməlidir?

Merge Conflict nədir?

Real komanda işində merge conflict ilə qarşılaşmaq normaldır.

Məsələn, iki developer eyni kod hissəsini dəyişdikdə Git hansı dəyişiklikdən istifadə etməli olduğunu avtomatik müəyyən edə bilməyə bilər.

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

Burada məqsəd sadəcə konfliktin bir hissəsini silmək deyil.

Developer əvvəlcə dəyişikliklərin məntiqini anlamalı, hansı variantın düzgün olduğunu müəyyən etməli, konflikti həll etməli və daha sonra layihəni test etməlidir.

Git biliyi ilə Git mədəniyyəti arasındakı fərq məhz burada ortaya çıxır.

---

2. Code Review: Kodun müəllifi olmaq kifayət deyil

Junior developer üçün ən vacib yeni təcrübələrdən biri Code Review prosesidir.

Sən kod yazırsan, Pull Request açırsan və başqa developer yazdığın kodu nəzərdən keçirir.

Reviewer belə suallar verə bilər:

• Kod tələb olunan funksiyanı yerinə yetirirmi?
• Kod lazımsız dərəcədə mürəkkəbdirmi?
• Testlər kifayət qədərdirmi?
• Variable və function adları aydındırmı?
• Mövcud coding standard-a uyğundurmu?
• Potensial edge case-lər nəzərə alınıbmı?
• Documentation yenilənməlidirmi?

Google Engineering Practices-də Code Review-un əsas məqsədlərindən biri kod bazasının ümumi sağlamlığını zaman keçdikcə yaxşılaşdırmaqdır.

Bu səbəbdən Code Review yalnız səhv axtarmaq prosesi deyil.

Bu, həm də kod keyfiyyətini qorumaq və bilik paylaşmaq mexanizmidir.

Code Review tənqid deyil

Junior developer üçün feedback qəbul etməyi öyrənmək vacibdir.

Reviewer:

“Sən pis kod yazmısan.”

deməməlidir.

Daha düzgün yanaşma:

“Bu yanaşma burada əlavə mürəkkəblik yaradır. Daha sadə həll istifadə edə bilərik.”

Beləliklə, müzakirə developer-in şəxsiyyətinə deyil, kodun keyfiyyətinə yönəlir.

Ən sağlam yanaşma:

“Mənim koduma hücum edilir” yox, “mənim kodum təkmilləşdirilir.”

Başqasının kodunu oxumaq da eyni dərəcədə vacibdir. Çünki Code Review zamanı yalnız öz səhvlərini görmürsən, digər developer-lərin problemləri necə həll etdiyini də öyrənirsən.

---

3. Agile və Scrum: Şirkətdə bir gün necə keçir?

Real layihədə səhər kompüteri açıb:

“Bu gün nə kod yazım?”

deyərək işə başlamırsan.

İşin müəyyən bir planın içindədir.

Scrum-da iş Sprint adlanan qısa və sabit müddətli dövrlər daxilində təşkil olunur.

Məsələn, komandanın Sprint məqsədi belə ola bilər:

Sprint Goal: İstifadəçinin sistemə qeydiyyatdan keçməsini təmin etmək.

Bu məqsəd daha kiçik task-lara bölünə bilər:

AUTH-101 → Registration UI
AUTH-102 → Registration API
AUTH-103 → Form validation
AUTH-104 → Email verification
AUTH-105 → QA testing

---

Sprint Planning

Sprint başlamazdan əvvəl komanda qarşıdakı müddətdə hansı işlərin görüləcəyini müəyyən edir.

Burada əsas suallar bunlardır:

• Bu Sprint-in məqsədi nədir?
• Hansı işləri yerinə yetirə bilərik?
• Bu işləri necə həyata keçirəcəyik?

Beləliklə, developer yalnız task-ı icra etmir.

O, task-ın niyə hazırlandığını və məhsula hansı dəyəri verdiyini də anlamalıdır.

---

Daily Scrum

Sprint ərzində komanda qısa gündəlik görüşlər keçirə bilər.

Daily Scrum adətən 15 dəqiqəlik koordinasiya görüşüdür.

Məsələn:

Dünən: Login API-ni tamamladım.

Bu gün: Frontend inteqrasiyasını edəcəyəm.

Problem: Refresh token davranışı ilə bağlı Backend developer ilə dəqiqləşdirməli olduğum məsələ var.

Bu cür kommunikasiya komandanın iş prosesində problemləri daha tez aşkar etməsinə kömək edir.

---

Jira və task management

Real layihələrdə task-lar adətən müəyyən statuslardan keçir:

TODO
  ↓
IN PROGRESS
  ↓
CODE REVIEW
  ↓
QA
  ↓
DONE

Task-ın IN PROGRESS statusunda uzun müddət qalması artıq komanda üçün görünən məlumatdır.

Əgər developer hansısa problemlə qarşılaşıbsa, bunu son günə qədər gizlətmək düzgün deyil.

Peşəkar developer:

“Bu deadline-a çatmayacağam” deməkdən qorxmur.

Əsas məsələ problemi vaxtında bildirmək və həll yolu üzərində komanda ilə işləməkdir.

---

4. Komandalararası kommunikasiya

Real məhsul bir developer tərəfindən hazırlanmadığı üçün müxtəlif rollar arasında kommunikasiya mühüm əhəmiyyət daşıyır.

UI/UX Designer

İstifadəçi interfeysinin necə görünəcəyini və istifadəçinin məhsulla necə qarşılıqlı əlaqədə olacağını müəyyənləşdirir.

Frontend Developer

Dizaynı işlək interfeysə çevirir və Backend API-ləri ilə inteqrasiya edir.

Backend Developer

Server tərəfini, biznes məntiqini, verilənlər bazasını və API-ləri hazırlayır.

QA Engineer

Funksionallığın düzgün işləyib-işləmədiyini və potensial problemləri yoxlayır.

Bu rolların hamısı bir-birindən asılıdır.

---

API Contract nədir?

Məsələn, Backend developer aşağıdakı endpoint-i hazırlayır:

PATCH /api/users/profile

Request:

{
  "name": "Ali",
  "phone": "+994..."
}

Frontend developer isə bilməlidir:

• Endpoint nədir?
• HTTP method hansıdır?
• Request body necədir?
• Response strukturu necədir?
• Error formatı necədir?
• Authentication tələb olunurmu?

Əks halda Frontend və Backend developer ayrı-ayrılıqda işləyən kod yaza bilər, amma birlikdə işləyən sistem yarada bilməzlər.

Buna görə API contract və documentation komanda işinin vacib hissəsidir.

---

5. Documentation niyə vacibdir?

Real layihədə bütün məlumat developer-in beynində saxlanılmır.

Documentation layihənin ümumi yaddaşıdır.

Məsələn, README faylında aşağıdakı məlumatlar ola bilər:

Project Setup
Environment Variables
Installation
Running Locally
API Documentation
Testing
Deployment

Yeni developer komandaya qoşulduqda layihəni daha asan başa düşə bilməlidir.

Yaxşı documentation komandanın asılılığını azaldır və məlumatın bir developer-dən digərinə ötürülməsini asanlaşdırır.

---

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

| Evdə və ya kursda | Real layihədə | | ------------------------------------------- | -------------------------------------- | | Tək işləyirsən | Komanda ilə işləyirsən | | Birbaşa kod yazırsan | Task və prioritet əsasında işləyirsən | | Birbaşa main branch istifadə edə bilərsən | Branch və PR workflow-u tətbiq olunur | | Kod əsasən yalnız sənin tərəfindən oxunur | Kod Code Review-dan keçir | | Deadline elastikdir | Sprint və deadline-lar var | | Bug-u özün tapırsan | QA və digər developer-lər də test edir | | Arxitekturanı tək seçirsən | Mövcud arxitekturaya uyğunlaşırsan | | Conflict az olur | Merge conflict yarana bilər | | Documentation çox vaxt ikinci plandadır | Documentation layihənin bir hissəsidir | | Texniki qərarları tək verirsən | Qərarlar komanda ilə müzakirə olunur |

Ən böyük fərq isə budur:

Kursda sən öz layihəni idarə edirsən. Real layihədə isə sən mövcud sistemin bir hissəsinə çevrilirsən.

---

7. Junior Developer üçün real layihə təcrübəsi niyə vacibdir?

Junior developer müsahibəsində:

“React bilirəm.”

demək vacibdir.

Amma bu, hər zaman kifayət etmir.

İşəgötürən üçün daha maraqlı suallar bunlardır:

• Git branch yaratmısanmı?
• Pull Request açmısanmı?
• Code Review almısanmı?
• Merge Conflict həll etmisənmi?
• Jira və ya oxşar task management sistemi ilə işləmisənmi?
• Backend developer ilə API inteqrasiyası etmisənmi?
• QA-dan gələn bug-u düzəltmisənmi?
• Deadline ilə işləmisənmi?
• Komanda daxilində texniki problemi izah edə bilirsənmi?

Çünki şirkət yalnız kod yaza bilən developer axtarmır.

Komandanın iş prosesinə qoşula bilən developer axtarır.

---

Devlab-da real layihə təcrübəsi

Devlab-da məqsəd yalnız texnologiyaları öyrətmək deyil.

Tələbələrin real layihə mühitinə mümkün qədər yaxın proseslərlə işləməsi hədəflənir.

Bu prosesdə tələbələr:

• komandalara bölünür;
• layihə üzərində birlikdə işləyir;
• Git və branch workflow-dan istifadə edir;
• Pull Request açır;
• Code Review prosesindən keçir;
• Agile və Scrum prinsipləri ilə task-ları idarə edir;
• Sprint daxilində işləyir;
• komanda üzvləri ilə kommunikasiya qurur;
• Frontend, Backend və digər rollarla koordinasiya edir;
• deadline-lara uyğun işləməyi təcrübədən keçirir.

Beləliklə, tələbə proqramı bitirəndə yalnız:

“Mən bu texnologiyanı bilirəm.”

demir.

Daha vacib olanı deyə bilir:

“Mən bu texnologiya ilə komanda daxilində real layihə workflow-u üzrə işləyə bilirəm.”

---

Nəticə

Proqramlaşdırmanı öyrənmək ilə Software Engineer kimi işləməyi öyrənmək arasında ciddi fərq var.

Kod yazmaq başlanğıcdır.

Peşəkar mühəndislik mühiti isə sənə bunları öyrədir:

Git → Branching → Pull Request → Code Review → Agile → Scrum → Testing → Documentation → Communication → Teamwork

Bunların hər biri junior developer-in texniki biliklərini real iş bacarığına çevirir.

Əgər məqsədin sadəcə kod yazmağı öyrənmək yox, real layihədə developer kimi işləməyə hazırlaşmaqdırsa, sənə yalnız texnologiyanı deyil, həmin texnologiyanın hansı proses daxilində istifadə edildiyini də öyrənmək lazımdır.

Çünki şirkətlərdə kod tək yazılmır. Kod komanda ilə birlikdə hazırlanır, yoxlanılır, müzakirə edilir və məhsula çevrilir.

Devlab ilə real layihə təcrübəsinə başla

Real layihə mühitində işləməyin nə demək olduğunu praktiki şəkildə öyrənmək istəyirsənsə, Devlab haqqında daha ətraflı məlumat əldə et.

Devlab - öyrən, komanda ilə işlə, real layihədə təcrübə qazan.