Funksiya ishga tushirilganidan olti oy o‘tib repositoryni ochsangiz, ko‘p narsani qayta tiklashingiz mumkin. Arxitekturani kuzatishingiz, sxemani tekshirishingiz, testlarni o‘qishingiz va aynan qaysi qatorlar o‘zgarganini ko‘rishingiz mumkin.
Ammo odatda qayta tiklab bo‘lmaydigan narsa — aynan o‘sha qatorlarni zarur qilgan suhbatdir.
Kod sizga validatsiya qoidasi nega mavjudligini aytmaydi — masalan, bitta mijoz noto‘g‘ri shakllangan eksport fayllarini yuborgani uchun. U g‘alati retry siyosati quyi tizimdagi takror tranzaksiyalarning oldini olishini tushuntirmaydi. U tozaroq interfeys accessibility testi ortidan rad etilganini yoki xizmat chegarasi muhandislik afzalligidan emas, balki shartnomaviy cheklovdan kelib chiqqanini ko‘rsatmaydi.
Git kod tarixini saqlashda juda kuchli. U niyatni esa faqat jamoa uni ataylab yozib qoldirsa va implementatsiya bilan bog‘liq holda saqlasa, asrab qoladi.
Bu bo‘shliq har doim dasturiy ta’minot muhandisligining bir qismi bo‘lib kelgan. AI kodlash vositalari uni yanada ko‘rinadigan qiladi. Tizim repositorydagi har bir faylni o‘qishi, har bir belgini kuzatishi va texnik jihatdan ishonarli patch yaratishi mumkin, ammo baribir noto‘g‘ri muammoni hal qilishi mumkin.
Muammo kodning chalg‘itishida emas. Kod shunchaki torroq savolga javob bermoqda.
Muhandislik haqiqatining besh qatlami
Mazmunli dasturiy o‘zgarishlarning aksariyati dalillarning besh xil qatlamiga tayanadi.
- Niyat — Foydalanuvchi, mijoz yoki biznes qanday natijani so‘ramoqda? Bu spetsifikatsiya, ticket, support suhbati yoki uchrashuv qaydlarida bo‘lishi mumkin.
- Cheklovlar — Nima buzilmasligi kerak? Moslik bo‘yicha va’dalar, xavfsizlik chegaralari, reglamentlar, shartnomalar, byudjetlar va muddatlar ko‘pincha repositorydan tashqarida bo‘ladi.
- Implementatsiya — Tizim bugun qanday ishlaydi? Kod, testlar, sxemalar, bog‘liqliklar va deployment konfiguratsiyasi shu qatlamni beradi.
- Ish vaqtidagi dalillar — Haqiqiy tizimda nima sodir bo‘lmoqda? Loglar, trace’lar, metrikalar, production ma’lumotlari va incident hisobotlari kodda mantiqli ko‘rinadigan taxminlarga zid bo‘lishi mumkin.
- Qarorlar tarixi — Joriy yondashuv nega tanlangan? Pull requestlar, dizayn muhokamalari, rad etilgan alternativalar va avvalgi incidentlar javobni saqlaydi.
Repository uchinchi qatlamda eng kuchli. U boshqalarining ayrim qismlarini ham o‘z ichiga oladi, ammo ularni to‘liq ifodalash uchun kamdan-kam hollarda yetarli bo‘ladi.
Bu muhim, chunki dasturiy nosozliklar ko‘pincha qatlamlar orasidagi chegaralarda paydo bo‘ladi. Implementatsiya eskirgan spetsifikatsiyaga mos keladi. Tuzatish ticket talabini qondiradi, ammo operatsion cheklovni buzadi. Testlar o‘tadi, chunki ular kechagi taxminlarni kodlagan. Kod ichki jihatdan izchil bo‘ladi, ammo production ma’lumotlari hech kim hujjatlashtirmagan andozaga amal qiladi.
Mahalliy jihatdan to‘g‘ri patch baribir noto‘g‘ri o‘zgarish bo‘lishi mumkin.
Repozitoriy o‘zi mustaqil ravishda javob bera olmaydigan savollar
Tasavvur qiling, foydalanuvchi hujjatni tahrir qiladi va keyin yangilangan gapni qidiradi, ammo natijalarda eski versiyani ko‘radi. “Qidiruvni darhol yangilang” degan talab aniqdek tuyuladi. Repozitoriy boshlash uchun bir nechta ehtimoliy nuqtalarni ko‘rsatadi, ammo u to‘g‘ri yechimni o‘zi mustaqil ravishda belgilab bera olmaydi.
| Savol | Ehtimoliy manba |
|---|---|
| Hujjatning qaysi versiyasi asosiy hisoblanadi? | Asl hujjat va tahrirlar tarixi |
| Eski matn qayerda saqlanib qolgan? | Sinxronlash loglari, extraction chiqishi, qidiruv indeksi yoki kesh |
| Bu mahsulot uchun “darhol” nimani anglatadi? | Mahsulot va’dasi yoki xizmat maqsadi |
| Hujjat mazmuni bilan birga uning ruxsatlari ham o‘zgardimi? | Asl ruxsatlar va audit tarixi |
| Eskirgan natija faqat bitta foydalanuvchi, manba yoki hudud bilan cheklanganmi? | So‘rov izlari va production metrikalari |
Qidiruv kodi natijalar qanday qaytarilishini tushuntirib berishi mumkin. Ammo u haqiqiy nuqson sinxronlashdagi kechikishmi, eskirgan extractionmi, keshni yaroqsizlantirishmi, ruxsatlarning tarqalishimi yoki mahsulot hech qachon belgilamagan kutilmami — buni aytib bera olmaydi.
Bu farq yetuk tizimlarda yanada muhimroq bo‘ladi. Eskirgandek ko‘rinadigan maydon hali ham legacy klientni qo‘llab-quvvatlayotgan bo‘lishi mumkin. Takrordek ko‘rinadigan servis turli ruxsat talablari bo‘lgan ma’lumotlarni ajratib turayotgan bo‘lishi mumkin. Haddan tashqari tuyuladigan tekshiruv esa joriy jamoa hech qachon ko‘rmagan production hodisasining kod darajasidagi yagona izi bo‘lishi mumkin.
Murakkablikni olib tashlash qadrli. Murakkablik niqobi ostidagi tarixni olib tashlash esa qimmatga tushadi.
Ko‘proq kontekst ham baribir noto‘g‘ri javobga olib kelishi mumkin
Eng ravshan yechim — AI’ga ko‘proq material berish: butun repozitoriy, har bir ticket, har bir hujjat, har bir xabar va har bir log.
Bu tushunish emas, kirish imkonini yaratadi.
Manbalar eskirgan, bir-biriga zid, taxminiy bo‘lishi yoki turli auditoriyalar uchun yozilgan bo‘lishi mumkin. Brainstorm tasdiqlangan spetsifikatsiyadan ustun turmasligi kerak. Olti oy oldingi talab kechagi mahsulot qarorini sezdirmasdan bekor qilmasligi kerak. Production log uni yaratgan release, muhit va kod yo‘li bilan bog‘langan bo‘lishi kerak. Mijoz so‘rovi qamrovi tekshirilmasdan universal talab sifatida qabul qilinmasligi kerak.
Shuning uchun jiddiy kontekst tizimiga faqat retrievalning o‘zi yetmaydi. U quyidagilar haqida fikr yurita olish usuliga muhtoj:
- Vakolat: Talabni qaysi manba belgilashga haqli?
- Dolzarblik: Qaysi ma’lumot joriy, qaysisi esa allaqachon almashtirilgan?
- Kelib chiqish: Har bir da’vo, cheklov yoki xulosa qayerdan kelib chiqqan?
- Munosabatlar: Qaysi issue, release, mijoz, dataset va kod yo‘li o‘zaro bog‘liq?
- Ruxsatlar: Bu vazifa uchun qaysi manbalardan foydalanish va ularni qaysi shaxsga ko‘rsatish mumkin?
Kontekst — tokenlar uyumi emas. U vaqt, vakolat va chegaralarga ega grafdir.
Ko‘proq kontekst ko‘proq dalil berishi kerak, dalilsiz ko‘proq ishonch emas.
Ishning haqiqiy birligi — o‘zgarish
Muharrirlar va kodlash vositalari fayllar atrofida tashkil etilgan, chunki biz o‘zgartiradigan narsa fayllardir. Muhandislik jamoalari esa o‘zgarishlar atrofida tashkil etilgan.
O‘zgarish sabab bilan boshlanadi. U talabga aylanadi, kod va ma’lumotlarga ta’sir qiladi, reviewdan o‘tadi, productionga yetib boradi va yangi dalillarni yaratadi. Agar bu bosqichlar uzilib qolsa, har bir keyingi vazifa yana bir arxeologiya bosqichidan boshlanadi.
Haqiqiy dasturiy ta’minot ustida ishlaydigan AI tizimi shu hayotiy siklga amal qilishi kerak.
Implementatsiyadan oldin, u so‘rovni, tegishli cheklovlarni va bir-biriga zid manbalarni aniqlashi kerak. U nuqsonni tuzatayotganini, kutilgan xatti-harakatni o‘zgartirayotganini yoki yangi kontrakt joriy qilayotganini bilishi kerak.
Implementatsiya davomida, u har bir mazmunli tanlovni dalillar bilan bog‘lashi kerak. Nega aynan shu modul? Nega aynan shu migratsiya strategiyasi? Nega bu branch saqlab qolinadi? Izoh kodni yaratgan chatdan keyin ham saqlanib qolishi kerak.
Joriy etilgandan so‘ng, u o‘zgarishga verifikatsiya natijalari, ko‘rib chiqish qarorlari va yangi aniqlangan cheklovlarni biriktirishi kerak. Aks holda keyingi odam — yoki keyingi AI sessiyasi — ularni qaytadan aniqlashiga to‘g‘ri keladi.
Bu, repozitoriyni tahrir qila oladigan vosita bilan muhandislik ishida ishtirok eta oladigan tizim o‘rtasidagi farqdir.
AI mulohazani yo‘qotmasligi, balki qayta tiklash zaruratini kamaytirishi kerak
Yaxshiroq kontekst ba’zan avtonom dasturiy ta’minot ishlab chiqishga eltuvchi yo‘l sifatida taqdim etiladi. Uning bevosita qiymati bundan kamroq shov-shuvli, ammo foydaliroq: o‘zgarish kiritishdan oldin voqelikni qayta tiklash xarajatini kamaytirish.
AI dastlabki talabni tegishli kod yoniga olib kelishi mumkin. U noodatiy himoya chorasi sababini tushuntiradigan hodisani yuzaga chiqarishi mumkin. U muvaffaqiyatsiz metrikani uni o‘zgartirgan reliz bilan bog‘lashi mumkin. U implementatsiya boshlanishidan oldin ikki ishonchli manba bir-biriga zid ekanini ko‘rsatishi mumkin.
Bu imkoniyatlar muhandislik mulohazasini yo‘q qilmaydi. Ular mulohazani yaxshiroq ma’lumotga tayangan holga keltiradi.
Qaysi murosa maqbul ekanini, talab to‘liq yoki yo‘qligini va reliz qanchalik xavfni o‘z zimmasiga olishi mumkinligini baribir inson hal qilishi kerak. Tizim dalillarni ko‘rinadigan, mulohaza yuritishni esa tekshirib bo‘ladigan qilishi kerak. U noaniqlikni sayqallangan patch ortiga yashirmasligi kerak.
Mezon “u kod generatsiya qila oladimi?” emas.
Mezon “nega aynan hozir bu to‘g‘ri o‘zgarish ekanini tushuntira oladimi?”dir.
Repozitoriydan xabardorlikdan ish jarayonidan xabardorlikka
Kod yozish yordamchilari dastlab ishlab chiquvchi oldidagi faylni tushunish orqali foydali bo‘la boshladi. Repozitoriydan xabardorlik keyingi yirik qadam bo‘ldi: bog‘liq kodni topish, simvollarni kuzatish va loyiha bo‘ylab o‘zgarishlarni qo‘llash.
Keyingi qadam — repozitoriy atrofidagi ish jarayonidan xabardorlik.
Bu kodni uni so‘ragan spetsifikatsiya, uni aniqlashtirgan suhbat, unga shubha uyg‘otgan production dalillari va keyinchalik esda saqlanishi kerak bo‘lgan qaror bilan bog‘lashni anglatadi. Bu, shuningdek, aloqasiz, eskirgan yoki foydalanuvchi ruxsatlaridan tashqaridagi kontekstni chiqarib tashlashni ham anglatadi.
Dvina’ni yaratayotganimizda, bu biz qayta-qayta murojaat qiladigan g‘oyalardan biridir. Ish bitta fayl, ilova yoki suhbat ichida sodir bo‘lmaydi. Ma’no ular orasidagi bog‘lanishlarda va bu bog‘lanishlar vaqt o‘tishi bilan qanday o‘zgarishida yashaydi.
Repozitoriy hanuz muhim. U tizim xatti-harakatining bajariladigan haqiqat manbaidir. Shunchaki, u mahsulot niyati, operatsion voqelik yoki tashkiliy xotiraning to‘liq haqiqat manbai emas.
To‘liq hikoya nima qurilishini o‘zgartiradi
Faqat kodning o‘zi bilan tabiiy savol quyidagicha bo‘ladi:
Bu tizimga qanday o‘zgarish mos keladi?
Kengroq kontekst bilan savol quyidagicha bo‘ladi:
Bu tizimga, bu talabga, bu tarixga va aynan shu lahzaga qanday o‘zgarish mos keladi?
O‘sha ikkinchi savol cheklovlarni regressiyaga aylanishidan oldin aniqlab oladi. U ko‘rib chiquvchilarga implementatsiya ortidagi mantiqni beradi. U yangi jamoa a’zolariga tizim nega aynan shunday ko‘rinishda ekanini tushunishga yordam beradi. U AI uchun asosli rol beradi: muharrir ichidagi biror oracle emas, balki ishning turli qismlaridan dalillarni jamlay oladigan ishtirokchi.
Sizning repongiz hech qachon butun hikoya bo‘lmagan.
Imkoniyat — uning qolgan qismini ham o‘qiy oladigan va o‘z ishini ko‘rsata oladigan tizimlarni yaratishdir.
