Dev thinking loud

TDD, PP va AI Bir oralar Birlashgan Qirollikdan inglizlar bilan bir proyektda birga ishladik. Ularning tezlikdan ko'ra sifatni ustun ko'rishlari har qadamda sezilib turar edi. Har "feature" uchun "refinement session"lar albatta bo'lar, sessionda "feature" qanday qilib "implement" qilinishining har qadami qayd qilinib "ticket"ga yozib qo'yilar edi. Bajaruvchi i ishga deyarli qiynalmas edi, chunki hamma "design decision"lar qilingan bo'lardi. U paytlari copilot edi chiqqan, faqatgina funksiya yozib berishni bilar edi. Jamoada ikkita qattiq qoida bor edi: 1) "Test-driven development (TDD)" - testlarning "implementation"dan oldin yozilishi 2) "Pair-programming (PP) for new features" - yangi qoshilayotgan imkoniyatlar uchun juft-dasturlash uslibi. U proyektga qadar shaxsiy tajribamda testlarni yozish yoki "implementation"dan keyin edi (beuracracy) yoki umuman yo'q edi (ha, shunday proyektlar ham bo'lgan va kam emas). Bazan shunday holatlar bo'ladi, sizga proyektga qo'shilishdan oldin shunaqa savollar berishadiki u proyekt ideal deb o'ylaysiz, qo'shilganingizdan keyin esa holat idealdan ancha uzoq ekanligini ko'rasiz va u kirishdagi savollarning bazilari sizga ma'nosiz tuyuladi. Bu gal ham shunday bo'lsa kerak deb o'ylagandim, chunki TDD tatbiqini faqat kitoblarda o'qigandim. Kutilmaganda ko'rdimki har ikki qoida (TDD vs PP) amalda qattiq qo'llaniladi. Ikkisi ham avvalida noodatiy tuyuldi, qanday qilib test yozishimiz mumkin agar hali "implementation"ni yozmagan bo'lsak deb o'ylardim, lekin jamoadoshlarimdan buni qanday amalga oshirishni tez orada o'rganib oldim. Masala muammoning yechimidan nima kutayotganimizni oldindan o'ylash haqida ekan. Undan tashqari PP ham boshida juda galati tuyuldi, jamoada kun boshida guruh teng ikkiga bo'linadi va har guruhdan bir odam narigi guruhdan birini tanlaydi va kun ohirigacha u bilan tanlangan ticket(lar) ustida birga ishlaydi. Odatda juftlar "shuffling" bo'lardi, yani bir odam bilan ketma-ket ikki kun ishlay olmasdik. Process juda qiziq, bir odam "navigator" boshqasi esa "implementor" (bazan "typist" deb aytilardi, chunki uning vazifasi asosan "keyboard"da tugma bosish) vazifasini bajaradi va har 15 minutda vazifa almashishadi. "Navigator"ning vazifasi muammoni qo'yish, u haqida fikr yuritish, "implementor"ga nima qilishi kerakligini aytib turish. Mabodo ticketda "refinement"da o'tkazib yuborilgan "case"lar bo'lsa ular uchun "tradeoff"larni ko'zdan kechirish va "design decision"larni qabul qilish. Bu orada "implementor"ning fikrini ham so'rab ko'radi. Tez orada bu uslubga ham ko'nikib qoldim. Bazan jamoa bazi sabablarga ko'ra toq sonli bo'lib qolar edi, shu paytlari kimdir yolg'iz ishlashi kerak bo'lar edi. Shunday holatga men tushib qolsam o'zimni noqulay his qilar, qilayotgan ishimning sifatiga shubhalanar edim. Bularni nega gapirib berdim? Hozirgi kundagi AI "workflow"larni o'sha paytdagi "PP session"larga o'xshataman, faqat bu yerda endi AI faqat "implementor/typist" emas, balki oradagi chegara biroz surilgandek. Endi AI faqat kod yozmaydi, balki izlanish ham qiladi, muammoga yechimlarni ko'zdan kechiradi, "tradeoff"larga qarab ajratib chiqadi va biz("navigator")larga taqdim qiladi, bizga esa "design decision"larni qabul qilish va ish tugaganda uni "review" qilish qoladi. AI bilan oramizdagi mehnat taqsimotini "mechanics and responsibility" ga bo'lgim keladi, "Mechanics" AIda, "responsibility" esa hanuz insonda.