İşi bir neçə icraçı arasında necə bölmək olar

Kiçik bir alış-veriş siyahısı tətbiqiniz var və ona iki funksiya lazımdır: qeydləri süzmək və siyahını CSV formatında ixrac etmək. Tapşırıqlar bir-biri ilə demək olar ki, bağlı deyil, ona görə də fikir özü yaranır: işi iki nəfərə bölək, bir saat əvəzinə yarım saata hər iki hissəni alaq. Bir icraçı filtri, digəri ixracı götürür, düzəlişlər qarışmasın deyə hərəsinə ayrıca iş qovluğu verilir. Hər iki hissənin siyahı qeydini necə başa düşəcəyi əvvəlcədən müzakirə olunmur. Guya hər şey aydındır.

Yarım saatdan sonra hər iki hissə hazırdır. Hərəsinin yoxlamaları uğurludur, birləşdirmə də konfliktsiz keçib. Amma ümumi ssenari işləmir: ekranda filtr üç sətir göstərir, ixrac edilmiş faylda isə sütun boşdur. Səbəb elə də maraqlı deyil. İcraçılardan biri oxunuşu yaxşılaşdırsın deyə completed sahəsinin adını done edib, ikincinin isə bundan xəbəri olmayıb.

Ayrı qovluqlar faylları ayırdı, amma qərarları uzlaşdırmadı. Tapşırığa üç addımda baxaq: əvvəl bu işi bölməyə dəyib-dəymədiyinə qərar verək, sonra dəyişiklik sahələrini və ümumi razılaşmaları bölüşdürək, sonda isə belə sürpriz lap axırda üzə çıxmasın deyə birləşdirilmiş nəticəni yoxlayaq.

Asılılıqları yoxlayın

İşi bölmək üçün adətən iki səbəb olur. Birincisi, müxtəlif sahələri müstəqil araşdırmaqdır: siyahının necə göstərildiyini və ixracın nəyin əsasında qurulduğunu eyni vaxtda öyrənmək. İkincisi, sərhədləri və yoxlanıla bilən nəticəsi artıq məlum olan hissələr üzərində paralel işləməkdir. "Burada plan, burada icra, burada yoxlama" bölgüsü özlüyündə üç iştirakçı tələb etmir, bir sessiya bunları növbə ilə edə bilər. Kiçik tapşırıq üçün bir icraçı ilə başlamaq məntiqlidir.

Səbəb varsa, növbəti sual budur: A-nın nəticəsi məlum olmayana qədər B işinin hansı hissəsi davam edə bilər? B tamamilə A-dan asılıdırsa, bu addımlar ardıcıl görülür. Bəzən B əvvəlcədən müstəqil bir hissəni hazırlaya bilər, amma nəticələri birləşdirmək yenə də A-nı gözləməlidir.

Həmin alış-veriş siyahısı nümunəsindən üç vəziyyət:

Üçüncü sətir ən çox rast gəlinən tələdir. Elə görünür ki, filtr src/filter.js faylındadır, ixrac isə src/export-csv.js faylında, deməli hissələr müstəqildir: fayllar axı ayrıdır. Amma hər ikisi eyni qeydi və eyni completed sahəsini oxuyur. Məqalənin əvvəlindəki ssenari məhz buna görə pozuldu, ayrı fayllar da kömək etmədi. Müstəqillik davranış və ümumi razılaşmalarla bağlıdır, kodun neçə faylda yerləşməsi ilə yox.

Hissələrə bölməyi agentə tapşıra bilərsiniz, amma icraçıları başlatmadan:

Tapşırığı hissələrə böl. Hər biri üçün giriş məlumatlarını, nəticəni,
asılılıqları və yoxlama üsulunu göstər. Hansı hissələrin indi başlaya biləcəyini qeyd et.
İcraçıları hələ başlatma.

Belə cavabı işə başlamazdan əvvəl yoxlamaq olar. Açıq asılılığı olmayan hissələr eyni vaxtda başlamaq üçün namizəddir. Asılılıqlar sütunu boşdursa, bunu layihədə yoxlayın: agent ümumi modeli və ya tənzimləməni görməmiş ola bilər.

Ümumi nəticəyə qədər vaxtı hesablayın

Sürətlənmə adətən bir rəqəmlə ölçülür: işin özü nə qədər vaxt apardı. Amma hesablanmalı olan qəbul edilən ümumi nəticəyə qədərki vaxtdır. Buraya işin özündən əlavə, hər icraçı üçün tapşırığın təsviri, hər birinin layihəni yenidən oxuması, gözləmə, iki nəticənin yoxlanması və bir nəticədə birləşdirilməsi daxildir.

Nümunəmiz üzrə şərti hesab. Rəqəmlər yalnız hesablamanı göstərmək üçündür, məhsuldarlıq ölçümü deyil:

Tapşırığın ümumi hazırlığı hər iki variantda lazımdır, ona görə hesablamaya daxil deyil. On dəqiqəlik qazancı bir dəfə yenidən işləmək silir. Birləşdirmə nə qədər baha başa gəlirsə, paralel iş bir o qədər çox vaxta qənaət etməlidir.

Vaxtdan başqa, asanlıqla unudulan daha iki xərc var. Hər əlavə icraçı layihəni yenidən oxuyur, bu da resurs sərfidir; üstəlik, ətraflı nəticələr qayıdanda ümumi söhbətdə yer tutur. İkinci xərc daha vacibdir: öz diqqətiniz. İki nəticəni oxumalı, müqayisə etməli və qərar verməlisiniz. Gələnləri oxumağa macal tapmırsınızsa, sürət artıq sizə aid deyil.

Əlavə xərcləri az olan, həcmcə müqayisə oluna bilən iki müstəqil hissədə sürəti təxminən ikiqat artırmaq mümkündür. Amma icraçıların sayı bunu vəd etmir.

Dublikat, yoxsa yoxlama

Dublikat iş hesabatlarda görünmür. İki icraçı səssizcə eyni faylları açır, hər ikisi siyahı qeydinin necə işlədiyini araşdırır və kodu öyrəndiyini dürüstcə yazır. Amma bəzən ikinci yoxlama qəsdən lazımdır: fərziyyə vacibdir və onu birincinin mülahizələrini görməyən birinin yoxlamasını istəyirsiniz. Belə yoxlama təsadüfi təkrardan bununla fərqlənir: yoxlanacaq mövzu və səbəb əvvəlcədən müəyyən edilir, cavablar fərqli çıxsa nə edəcəyiniz də bəlli olur. Sonuncu yoxdursa, yoxlama fikir toplamağa çevrilir.

İndi isə əks vəziyyət. İki icraçıdan siyahı qeydindəki completed sahəsinin nə demək olduğunu soruşublar. Hər ikisi eyni cavabı verib: məhsulun alındığını bildirən işarədir. Bu, iki tərəfdən təsdiq kimi görünür.

Əslində hər ikisi bir il əvvəl yazılmış eyni README.md sətrini oxuyub, halbuki kodda bu sahə çoxdan başqa məna daşıyır. Onların nəticəsi yox, mənbəyi eyni olub.

Buradan bir neçə faydalı vərdiş çıxır:

• cavabın nəyə əsaslandığını göstərin: fayl, sətir, kod parçası. Sözlə nəql yox, özünüz aça biləcəyiniz sübutu;
• ümumi fərziyyəni ayrıca və həqiqətən yoxlayın: kod nə edir, ssenaridə nə baş verir. Hamı razı olsa belə.

Ayrı sessiyalar səhvlərin müstəqil olacağına zəmanət vermir: ümumi mənbə ümumi səhv yaradır. Cavablar fərqlənəndə səsləri saymayın, əsasları araşdırın: biri aktual koda baxa bilər, ikisi isə köhnəlmiş qeydə.

Kodla yoxlanmış sahə dəyəri işə başlamazdan əvvəl razılaşdırılan ümumi modelin əsasına çevrilir. Bu üç yoxlamadan sonra da işi bölmək sərfəli görünürsə, indi bölgüyə keçək.

Hər sahəyə məsul şəxs təyin edin

Paralel iş zamanı qayda sadədir: hər dəyişiklik sahəsinə bir məsul şəxs düşür. Söhbət "bu fayla heç vaxt iki nəfər toxuna bilməz" qaydasından getmir, razılaşma belədir: "bu iki tapşırıq davam edən müddətdə burada o yazır". Bu, layihənin daimi xüsusiyyəti yox, müəyyən müddət üçün razılaşmadır.

Qaydanın ikinci hissəsi daha vacibdir, amma onu daha tez-tez unudurlar. Ümumi nəticəyə də məsul şəxs lazımdır: hissələri birləşdirib bütöv nəticənin hazır olub-olmadığını deyən adam. Birləşdirməyə heç kim təyin edilməsə, bu iş axırıncı bitirənin üzərinə düşəcək. Halbuki başqasının hissəsi barədə ən az bilən də məhz odur.

Başlamazdan əvvəl layihəyə baxın və lazım olan hissələrin artıq hansısa şəkildə ayrılıb-ayrılmadığını yoxlayın. Ayrılmayıbsa, paralel iş naminə böyük refaktorinqə başlamaq lazım deyil: günün ən böyük tapşırığı elə bu olacaq və bölməyə heç nə qalmayacaq.

Alış-veriş siyahımız üçün bölgü belə görünür:

Cədvəl dəyişikliklərə görə məsuliyyəti bölür, giriş hüquqlarını yox: ümumi faylları ehtiyacı olan hər kəs oxuyur.

package.json sətri səbəbsiz yerə əlavə edilməyib: npm install hər iki faylı eyni anda dəyişir, ona görə paralel quraşdırmalar heç yerdən konflikt yaradır. Eyni kitabxananın iki fərqli versiyası da build zamanı sürpriz verə bilər. Kitabxana hər ikisinə lazım olsa, icraçılar nəyin və nə üçün lazım olduğunu bildirirlər. Qərarı bir nəfər verir və düzəlişi bir dəfə edir.

İşə başlamazdan əvvəl ümumi model barədə razılaşın

Ümumi razılaşma olmadan fayllara görə sərhəd qoymaq yaxşı işləmir. Filtr və ixrac eyni qeyd modelinə əsaslanır. Aşağıda onların interfeyslərinin eskizi var, icra olunan nümunə deyil: funksiyaların reallaşdırılması göstərilməyib. İşə başlamazdan əvvəl qeydlərin sırasını saxlamaq, ilkin massivi dəyişməmək və CSV-də boolean dəyərləri true/false kimi yazmaq barədə də razılaşmışıq. CSV escape qaydaları əvvəlki kimi qalır.

// siyahıdakı bir qeyd: bu üç sahə əvvəlcədən razılaşdırılıb, adları dəyişdirilmir
const item = { id: 41, title: "oat milk", completed: false };

// filter.js hazır qeydlər toplusunu qaytarır, formatlaşdırmır və ixrac etmir
filterItems(items, mode);   // mode: "all", "active", "completed"

// export-csv.js artıq süzülmüş toplunu qəbul edir və özü heç nə seçmir
exportCsv(items);           // id,title,completed sütunları olan CSV sətrini qaytarır

Diqqət edin, razılaşma fayl adları ilə yox, giriş və çıxışla bağlıdır. "İxrac artıq süzülmüş siyahını alır" xırda detal kimi səslənir, amma məhz bu cümlə ikisindən hansının qeydləri seçməyə cavabdeh olduğunu müəyyən edir. Bu olmasa, hər ikisi seçimi öz hissəsində etməli olduğunu düşünə bilər; onda fayla ya hər şey düşər, ya da siyahı iki dəfə süzülər.

Nəticənin necə qəbul ediləcəyini də işə başlamazdan əvvəl razılaşdırırlar. Nümunəmiz üçün ümumi ssenari: 41 və 43-cü qeydlərdə completed: true, 42-cidə isə false olmalıdır. "completed" rejimi 41 və 43-ü ilkin ardıcıllıqla göstərməli, CSV isə eyni iki qeydi id,title,completed başlığı və son sütunda true dəyəri ilə ixrac etməlidir. Ssenari hər iki hissədən keçir və məhz məqalənin əvvəlindəki xətanı tutur.

Razılaşmanın özünü dəyişmək məsələsi də var. İş zamanı ümumi formatı dəyişmək lazım olduğu üzə çıxsa, bu, bir faylda xırda düzəliş deyil. Formatdan asılı olan bütün tapşırıqlara yenidən baxmaq lazımdır, çünki artıq görülmüş işin bir hissəsi əvvəlki varianta əsaslana bilər.

Ayrı iş qovluqları (git worktree) razılaşmanı əvəz etmir. Onlar düzəlişləri fiziki olaraq ayırır, bu faydalıdır: ümumi qovluqda yoxlama qonşu tapşırığın yarımçıq dəyişikliklərini də tuta və heç bir icraçının ayrıca yoxlamadığı vəziyyəti təsdiqləyə bilər. Amma qovluq qeyd formatını razılaşdıra bilməz, portlar, lokal verilənlər bazaları və digər xarici resurslar isə ümumi qalır. İzlənilməyən .env isə yeni qovluqda standart olaraq ümumiyyətlə olmur: onu kopyalayırlar, məsələn .worktreeinclude vasitəsilə.

Hər kəsə qısa tapşırıq verin

Tapşırıq təsvirinin uzun olması vacib deyil. Adətən yeddi bənd kifayətdir: məqsəd, hansı versiyadan başlamaq, öz faylları, ümumi razılaşmalar, yoxlanıla bilən nəticə, cavabda nə qaytarılmalıdır və başqasının sahəsi lazım olsa nə etməli.

Məqsəd: siyahı filtri bütün qeydləri, yalnız tamamlanmamışları və ya yalnız tamamlananları göstərir.
Başlayın: qeyd modelinin razılaşdırıldığı əsas budağın son commit-indən.
Fayllarınız: src/filter.js və tests/filter.test.js.
Ümumi razılaşma: completed sahəsi boolean qalır, sahə adlarını dəyişmirik;
filtr qeydlər massivini qaytarır və heç nə ixrac etmir.
Nəticə: filtr testləri keçir; üç qeyddən ibarət topluda hər rejim
gözlənilən siyahını qaytarır.
Qaytarın: faktiki dəyişdirilmiş faylların siyahısı, test nəticələri
və onların hansı versiyada başladıldığı, qalan suallar.
Əgər src/item-model.js və ya src/app.js faylını dəyişmək lazım olsa: dayanın,
lazım olan dəyişikliyi və səbəbini izah edin, cavab gözləyin.

İkinci icraçıya verilən tapşırıq da eyni quruluşdadır: öz fayl cütü, eyni qeyd formatı, yoxlanıla bilən nəticəsi və sərhəddən çıxanda eyni addımlar. Onu burada bütövlükdə təkrarlamağa ehtiyac yoxdur.

İndi cavab barədə. Orada faktiki dəyişdirilmiş faylların siyahısı və yoxlamaların faktiki nəticəsi olmalıdır. "Başqasının fayllarına toxunulmayıb" cümləsini yazmaq asandır, israrla istədikdə cavabda görünmə ehtimalı da artır. Cümləyə yox, dəyişikliklər siyahısına baxın. Tapşırıq təsvirindəki sərhəd razılaşma rolunu oynayır, qadağa deyil: sorğu mətni agentin fayla yazmasına mane olmur, giriş hüquqları ayrıca tənzimlənir.

Kəsişən işi yenidən razılaşdırın

Gec-tez kimsə başqasının sərhədinə dirənəcək. İcraçı B görür ki, src/app.js faylını dəyişmədən ixracı qoşmağa yer yoxdur: ixrac düyməsi çağırılmır.

Yaxşı cavabda səbəb, lazım olan dəyişiklik və asılılıq göstərilir. src/app.js faylında qoşulma artıq birləşdirməyə məsul şəxsə tapşırılıb, ona görə B öz modulunu bitirib qoşulma sorğusu göndərə bilər. Ümumi dəyişiklik olmadan öz hissəsini davam etdirmək mümkün deyilsə, asılı iş dayandırılır.

Sonra iki variant var. Birləşdirməyə məsul şəxs ümumi fayldakı dəyişikliyi özü edir, çünki bu sahə ona aiddir. Ya da sahəni açıq şəkildə icraçı B-yə verir, amma əvvəlki sahibinin həmin faylda artıq işləmədiyinə əmin olur: işi dayandırmadan ötürmək bölgünün qarşısını aldığı vəziyyəti yenidən yaradar.

İcraçını sərhədi dolanmağa məcbur etmək isə olmaz. "app.js-ə toxunma, başqa yol tap" xahişi adətən öz faylında başqasının məntiqinin surətini və ya sonra heç kimin izah edə bilməyəcəyi əlavə qat yaradır. Formal olaraq cədvələ əməl olunub. Əslində isə layihədə ixracın necə işlədiyinə dair ikinci bir həqiqət yaranıb.

Təkcə faylları yox, davranışı birləşdirin

Birləşdirmədən əvvəl məsul şəxs üç şeyi anlamalıdır: hər hissə hansı versiyadan başlayıb, hər icraçı nəyi və hansı versiyada yoxlayıb, əslində hansı fayllar dəyişib. Bunların hamısı tapşırığa verilən cavablarda olmalıdır, faylların siyahısı isə faktiki dəyişikliklərlə tutuşdurulur.

Sonra hissələri birləşdirirlər və əsas iş başlayır: işə başlamazdan əvvəl razılaşdırılmış ümumi ssenarini icra etmək. Buna iki tam fərqli problem mane ola bilər.

Mətn konflikti. Hissələr kodun eyni yerini müxtəlif cür dəyişib, faylı silib və ya adını dəyişib, Git isə onları avtomatik birləşdirə bilməyib. Konflikt həll edilir, sonra yekun davranış yoxlanır.

Məna uyğunsuzluğu. Eyni sətrə iki nəfər toxunmayıb, mətn problemsiz birləşir, konflikt bildirişi də yoxdur. Ad dəyişdirmə nümunəmiz məhz burada üzə çıxır: filtr done oxuyur, ixrac completed oxuyur və boş nəticə alır. Hər iki hissənin yoxlamaları uğurludur, çünki hər biri öz hissəsini, özü də öz məlumatları üzərində yoxlayır.

Sxemdə aşağı oxu izləyin. Yuxarı hissə adətən işin bölünməsi deyilən şeydir: ayrı fayllardakı iki müstəqil hissə. Hazır olub-olmaması barədə nəticə isə bir mərtəbə aşağıda, hər iki hissədən keçən ssenaridədir. Bu oxdan keçənə qədər iki lokal nəticəniz var, ümumi nəticəniz isə yoxdur. Layihə qaydaları bütün yoxlamaları tələb edirsə, ümumi ssenari onları əvəz etmir.

Ümumi qərarı qeydə alın

Birləşdirmədən sonra ümumi nəticəyə məsul şəxs növbəti addımı seçir. Məsələn:

1. Ümumi nəticəni qəbul etmək: ssenari keçir, dəyişikliklər izah edilə bilir, meyarlar yerinə yetirilib.
2. Konkret hissəni yenidən işləmək üçün qaytarmaq və nəyin nə ilə uyğun gəlmədiyini göstərmək. "İxrac qəribədir" yox, "ixrac artıq modeldə olmayan sahəni oxuyur".
3. Bölgünün özünə yenidən baxmaq: icraçıların sayını azaltmaq və ya hissələri ardıcıl etmək.

Üçüncü variant normaldır, uğursuzluq deyil. Bölgünü yenidən nəzərdən keçirməyin vaxtı gəldiyini göstərən əlamətlər tez görünür:

• ümumi qeyd formatı təkrar-təkrar dəyişir və hər dəfə hər iki hissəni yenidən işləmək lazım gəlir;
• icraçılar bir-birini gözləyir, deməli asılılıq var imiş, sadəcə adı çəkilməyib;
• nəticələr onları oxumağa macal tapdığınızdan daha tez gəlir.

Sonuncu əlamət ən xoşagəlməz olanıdır, çünki kənardan uğur kimi görünür. Bir uğurlu bölgü hələ qanunauyğunluq deyil: agentin nəticəsi bir işə salınmadan digərinə dəyişir, ona görə vacib nəticəni oxşar tapşırıqda yenidən yoxlamaq lazımdır.

Qismən nəticə də normaldır. Filtr hazır və yoxlanmış ola bilər, ixrac isə yox; bunu olduğu kimi yazın: iki hissədən biri. Ümumi tapşırıq hələ də açıq qalır. Yarısının işləməsinə görə onu bitmiş saymaq olmaz, bölgünü nə qədər səliqəli aparmağınız da bunu dəyişmir.

Özünüzü yoxlayın

İki vəziyyət. Əvvəl özünüz cavab verin, sonra yoxlayın.

Xətanın səbəbi hələ tapılmayıb.
İxrac bəzən boş fayl verir və düzəlişi dərhal iki nəfərə tapşırmaq istəyirsiniz. Əvvəl xətanı təkrarlayın və araşdırın. Yoxlanıla bilən fərqli fərziyyələr ortaya çıxsa, onları iki icraçıya vermək olar. Amma əsas olmadan təklif edilən iki düzəliş tapşırığı həll etmir: hər birini səbəblə əlaqələndirib ilkin ssenaridə yoxlamaq lazımdır.

Fayllar ayrı, say isə eyni.
Filtr məhsul sayını ədəd ilə hesablayır, ixrac isə eyni miqdarı qablaşdırma ilə göstərir. Hər iki hissənin yoxlamaları uğurludur, amma ekrandakı və fayldakı rəqəmlər uyğun gəlmir. Bu, kod xətası deyil: hissələrdən heç biri öz sərhədini pozmayıb. Ölçü vahidi barədə razılaşma çatmır. İşə başlamazdan əvvəl bu, ümumi qeyd modelində müəyyən edilir, src/item-model.js faylını birləşdirməyə məsul şəxs dəyişir, sonra ümumi ssenari yenidən icra olunur.

Claude Code nəyi üzərinə götürə bilər

Agent məqalənin əvvəlində göstərildiyi kimi bölgü qaralaması təklif edə, sizin bəndləriniz əsasında isə tapşırığın əlaqəli təsvirini yaza bilər. Qərar yenə sizdə qalır, amma daha üç yerdə kömək edir:

• Sahələrin qaralama xəritəsi. Ondan layihəni gözdən keçirib tapşırığın hər hissəsində hansı faylların dəyişəcəyini yolları ilə təklif etməsini istəyin. Bu, yalnız qaralamadır: hər sahəyə məsul şəxsi siz təyin edirsiniz.
• Birləşdirmə və ümumi yoxlama. Agent hissələri birləşdirər, dəyişikliklərin tam siyahısını göstərər və ümumi ssenarini icra edər. Sonra dəyişikliklərin hamısını özünüz nəzərdən keçirin.
• Mübahisəli məqam. İki əmin izah qərarın qəbul edildiyi demək deyil. Əsasları, faylı və sətri istəyin. Ümumi faylı kimin dəyişəcəyi əvvəlcədən cədvəldə müəyyən olunur, kimin cavabının daha inandırıcı səsləndiyinə görə yox.

Nəticədə hər şey bir qərardan və iki təyinatdan asılıdır. Qərar: işi bölməyə dəyərmi? Hər əlavə icraçının faydası onun işini hazırlamaq, yoxlamaq və birləşdirmək xərclərini doğrultmalıdır. Təyinatlar: hər dəyişiklik sahəsinə və ümumi nəticəyə məsul şəxs. Alış-veriş siyahısı nümunəsində məhz bunlar çatmadı: completed sahəsi barədə razılaşma və filtr ilə ixracı birlikdə kimin yoxlayacağı. Alətlər işin mexaniki hissəsini azaldır, birləşdirilmiş davranışın həqiqətən sifariş etdiyiniz nəticə olub-olmadığı barədə qərarı isə insan verir.