Bir xüsusiyyət istifadəyə verildikdən altı ay sonra repository-ni açsanız, çox şeyi yenidən qura bilərsiniz. Arxitekturanı izləyə, sxemi yoxlaya, testləri oxuya və dəqiq hansı sətirlərin dəyişdiyini görə bilərsiniz.
Amma adətən yenidən qura bilmədiyiniz şey, həmin sətirləri zəruri edən söhbətdir.
Kod sizə deməyəcək ki, bir validasiya qaydası ona görə mövcuddur ki, bir müştəri qüsurlu export-lar göndərir. O, qəribə görünən retry siyasətinin downstream sistemdə təkrarlanan tranzaksiyaların qarşısını aldığını izah etməyəcək. Daha təmiz interfeysin accessibility testindən sonra rədd edildiyini və ya xidmət sərhədinin mühəndislik üstünlüyündən yox, müqavilə məhdudiyyətindən qaynaqlandığını göstərməyəcək.
Git kod tarixçəsini qorumaqda əladır. Niyyəti isə yalnız komanda onu qəsdən yazıya alanda və implementasiya ilə əlaqəli saxlayanda qoruyur.
Bu boşluq həmişə proqram mühəndisliyinin bir hissəsi olub. AI kodlaşdırma alətləri bunu daha görünən edir. Sistem repository-dəki hər faylı oxuya, hər simvolu izləyə və texniki baxımdan inandırıcı bir patch yarada bilər, amma yenə də yanlış problemi həll edə bilər.
Problem kodun yanıltıcı olması deyil. Kod sadəcə daha dar bir suala cavab verir.
Mühəndislik həqiqətinin beş qatı
Mənalı proqram dəyişikliklərinin çoxu beş fərqli sübut qatından asılıdır.
- Niyyət — İstifadəçi, müştəri və ya biznes hansı nəticəni istəyir? Bu, spesifikasiyada, ticket-də, dəstək söhbətində və ya görüş qeydlərində ola bilər.
- Məhdudiyyətlər — Nə pozulmamalıdır? Uyğunluq vədləri, təhlükəsizlik sərhədləri, qaydalar, müqavilələr, büdcələr və son tarixlər çox vaxt repository-dən kənarda olur.
- İmplementasiya — Sistem bu gün necə işləyir? Kod, testlər, sxemlər, asılılıqlar və deployment konfiqurasiyası bu qatı təmin edir.
- İşləmə mühiti sübutları — Real sistemdə nə baş verir? Log-lar, trace-lər, metrikalar, production məlumatları və insident hesabatları kodda məntiqli görünən fərziyyələrlə ziddiyyət təşkil edə bilər.
- Qərar tarixçəsi — Mövcud yanaşma niyə seçilib? Pull request-lər, dizayn müzakirələri, rədd edilmiş alternativlər və əvvəlki insidentlər cavabı saxlayır.
Repository üçüncü qatda ən güclüdür. Digərlərinin də bəzi hissələrini ehtiva edir, amma onları tam şəkildə təmsil etməyə nadir hallarda kifayət edir.
Bu vacibdir, çünki proqram təminatındakı uğursuzluqlar çox vaxt qatlar arasındakı sərhədlərdə üzə çıxır. İmplementasiya köhnəlmiş spesifikasiyaya uyğundur. Düzəliş ticket-i qarşılayır, amma əməliyyat məhdudiyyətini pozur. Testlər keçir, çünki onlar dünənin fərziyyələrini kodlaşdırır. Kod daxildən ardıcıldır, amma production məlumatları heç kimin sənədləşdirmədiyi bir nümunəni izləyir.
Lokal olaraq düzgün bir patch yenə də yanlış dəyişiklik ola bilər.
Repozitoriyanın təkbaşına cavablandıra bilmədiyi suallar
Təsəvvür edin ki, istifadəçi sənədi redaktə edir və sonra yenilənmiş cümləni axtarır, amma nəticələrdə köhnə versiyanı görür. “Axtarışı dərhal yenilə” aydın tələb kimi səslənir. Repozitoriya başlamaq üçün bir neçə mümkün nöqtəni göstərir, amma düzgün həlli öz-özünə müəyyən edə bilmir.
| Sual | Ehtimal olunan mənbə |
|---|---|
| Sənədin hansı versiyası əsas mənbə sayılır? | Mənbə sənəd və reviziya tarixçəsi |
| Köhnə mətn harada qalır? | Sinxronizasiya jurnalları, çıxarış nəticəsi, axtarış indeksi və ya keş |
| Bu məhsul üçün “dərhal” nə deməkdir? | Məhsul vədi və ya xidmət hədəfi |
| Sənədin icazələri məzmunla birlikdə dəyişibmi? | Mənbə icazələri və audit tarixçəsi |
| Köhnəlmiş nəticə yalnız bir istifadəçi, mənbə və ya regionla məhdudlaşır? | Sorğu izləri və istehsal metrikaları |
Axtarış kodu nəticələrin necə qaytarıldığını izah edə bilər. Amma o, əsl problemin sinxronizasiya gecikməsi, köhnəlmiş çıxarış, keşin etibarsızlaşdırılması, icazələrin yayılması, yoxsa məhsulun heç vaxt müəyyən etmədiyi bir gözlənti olduğunu sizə deyə bilməz.
Bu fərq yetkin sistemlərdə daha da vacib olur. Köhnəlmiş görünən bir sahə hələ də legacy müştərini dəstəkləyə bilər. Təkrarlanan kimi görünən bir xidmət fərqli icazə tələbləri olan məlumatları ayırmaq üçün mövcud ola bilər. Həddindən artıq görünən bir yoxlama isə mövcud komandanın heç vaxt görmədiyi istehsal insidentinin kod səviyyəsində yeganə izi ola bilər.
Mürəkkəbliyi silmək dəyərlidir. Amma mürəkkəblik kimi gizlənmiş tarixi silmək baha başa gəlir.
Daha çox kontekst yenə də yanlış cavab yarada bilər
Aşkar həll AI-yə daha çox material verməkdir: bütün repozitoriya, hər bir tiket, hər bir sənəd, hər bir mesaj və hər bir jurnal.
Bu, anlayış yox, giriş yaradır.
Mənbələr köhnəlmiş, bir-biri ilə ziddiyyətli, ehtimala əsaslanan və ya fərqli auditoriyalar üçün yazılmış ola bilər. Beyin fırtınası təsdiqlənmiş spesifikasiyadan üstün tutulmamalıdır. Altı aylıq tələb dünənin məhsul qərarını səssizcə üstələməməlidir. İstehsal jurnalı onu yaradan buraxılış, mühit və kod yolu ilə əlaqələndirilməlidir. Müştəri sorğusu əhatə dairəsi yoxlanmadan universal tələb kimi qəbul edilməməlidir.
Buna görə ciddi kontekst sistemi sadəcə retrieval-dan daha artığını tələb edir. O, bunlar barədə düşünə bilməlidir:
- Səlahiyyət: Tələbi müəyyən etməyə hansı mənbənin ixtiyarı var?
- Aktuallıq: Hansı məlumat hazırkıdır və nə artıq əvəz olunub?
- Mənşə: Hər bir iddia, məhdudiyyət və ya nəticə haradan gəlib?
- Əlaqələr: Hansı məsələ, buraxılış, müştəri, dataset və kod yolu bir-biri ilə bağlıdır?
- İcazələr: Bu tapşırıq üçün hansı mənbələrdən istifadə oluna və bunlar bu şəxsə göstərilə bilər?
Kontekst token yığını deyil. O, zaman, səlahiyyət və sərhədləri olan bir qrafdır.
Daha çox kontekst daha çox sübut yaratmalıdır, sübutsuz daha çox əminlik yox.
Əsl iş vahidi dəyişiklikdir
Redaktorlar və kodlaşdırma alətləri fayllar ətrafında təşkil olunur, çünki dəyişdirdiyimiz şey fayllardır. Mühəndislik komandaları isə dəyişikliklər ətrafında təşkil olunur.
Dəyişiklik bir səbəblə başlayır. O, tələbə çevrilir, koda və dataya toxunur, review-dan keçir, istehsala çatır və yeni sübut yaradır. Əgər bu mərhələlər bir-birindən ayrı qalsa, gələcəkdə hər bir tapşırıq daha bir arxeologiya turu ilə başlayır.
Real proqram təminatı üzərində işləyən AI sistemi bu həyat dövrünü izləməlidir.
İcradan əvvəl, o, sorğunu, aidiyyəti məhdudiyyətləri və ziddiyyətli mənbələri müəyyən etməlidir. O bilməlidir ki, qüsuru düzəldir, gözlənilən davranışı dəyişir, yoxsa yeni müqavilə təqdim edir.
İcra zamanı, o, hər bir mənalı seçimi sübutla əlaqələndirməlidir. Niyə bu modul? Niyə bu miqrasiya strategiyası? Niyə bu budağı saxlamaq lazımdır? İzah kodu yaradan çatdan kənarda da yaşamalıdır.
Tətbiqdən sonra, o, yoxlama nəticələrini, nəzərdən keçirmə qərarlarını və yeni aşkar edilmiş məhdudiyyətləri dəyişikliklə birlikdə əlavə etməlidir. Əks halda növbəti insan — ya da növbəti AI sessiyası — bunları yenidən üzə çıxarmalı olacaq.
Bu, repozitoriyanı redaktə edə bilən alətlə mühəndislik işində iştirak edə bilən sistem arasındakı fərqdir.
AI mühakiməni aradan qaldırmamalı, yenidənqurmanı azaltmalıdır
Daha yaxşı kontekst bəzən avtonom proqram təminatı hazırlanmasına aparan yol kimi təqdim olunur. Onun dərhal verdiyi dəyər daha az dramatik, amma daha faydalıdır: dəyişiklik etməzdən əvvəl reallığı yenidən qurma xərcini azaltmaq.
AI ilkin tələbi uyğun kodun yanına gətirə bilər. Qeyri-adi bir qoruyucu tədbiri izah edən insidenti üzə çıxara bilər. Uğursuz metriklə onu dəyişən relizi əlaqələndirə bilər. Tətbiq başlamazdan əvvəl iki nüfuzlu mənbənin bir-biri ilə razılaşmadığını göstərə bilər.
Bu imkanlar mühəndislik mühakiməsini aradan qaldırmır. Onlar mühakiməni daha məlumatlı edir.
Hansı kompromisin qəbulolunan olduğuna, tələbin tam olub-olmadığına və relizin nə qədər risk daşıya biləcəyinə yenə də insan qərar verməlidir. Sistem sübutları görünən, əsaslandırmanı isə yoxlanıla bilən etməlidir. O, qeyri-müəyyənliyi cilalanmış patch-in arxasında gizlətməməlidir.
Standart “kod yarada bilirmi?” deyil.
Standart budur: “niyə məhz indi düzgün dəyişiklik budur, bunu izah edə bilirmi?”
Repozitoriyanı anlamaqdan işi anlamağa
Kod yazma köməkçiləri əvvəlcə tərtibatçının qarşısındakı faylı anlamaqla faydalı oldular. Repozitoriya barədə məlumatlılıq növbəti böyük addım idi: əlaqəli kodu tapmaq, simvolları izləmək və layihə boyunca dəyişikliklər tətbiq etmək.
Növbəti addım repozitoriyanın ətrafındakı işdən xəbərdar olmaqdır.
Bu o deməkdir ki, kod onu tələb edən spesifikasiya, onu dəqiqləşdirən söhbət, ona etiraz edən istehsal sübutları və sonradan xatırlanmalı olan qərarla əlaqələndirilməlidir. Bu həm də aidiyyətsiz, köhnəlmiş və ya istifadəçinin icazələri xaricində olan kontekstin kənarda saxlanması deməkdir.
Dvina-nı qurarkən davamlı olaraq qayıtdığımız ideyalardan biri budur. İş tək bir faylın, tətbiqin və ya söhbətin içində baş vermir. Məna onların arasındakı əlaqələrdə və bu əlaqələrin zamanla necə dəyişməsində yaşayır.
Repozitoriya əsas olaraq qalır. O, sistem davranışı üçün icra oluna bilən həqiqət mənbəyidir. Sadəcə, məhsul niyyəti, əməliyyat reallığı və ya təşkilati yaddaş üçün tam həqiqət mənbəyi deyil.
Tam hekayə nəyin qurulacağını dəyişir
Yalnız kod olduqda, təbii sual budur:
Bu sistemə hansı dəyişiklik uyğundur?
Daha geniş kontekstlə sual belə olur:
Bu sistemə, bu tələbə, bu tarixçəyə və bu ana hansı dəyişiklik uyğundur?
Həmin ikinci sual məhdudiyyətləri reqressiyaya çevrilməzdən əvvəl üzə çıxarır. O, rəyçilərə implementasiyanın arxasındakı məntiqi verir. Yeni komanda üzvlərinə sistemin niyə məhz bu cür qurulduğunu anlamağa kömək edir. Süni intellektə əsaslı bir rol verir: redaktorun içindəki bir kahin kimi deyil, iş boyu dəlilləri bir araya gətirə bilən bir iştirakçı kimi.
Sizin repo-nuz heç vaxt bütün hekayə olmayıb.
Fürsət qalan hissəni də oxuya bilən və işini necə gördüyünü göstərə bilən sistemlər qurmaqdadır.
