1. Kirish
Bitta ekranning foydalanuvchiga yetkazilishi uchun o'ylagandan ko'ra ko'proq jarayonlardan o'tadi. Rejalashtirishdan tortib, nashr so'rovi, rivojlantirish, sinovgacha bitta oqim sifatida davom etadi. Ushbu safar nashr qilishni hisobga olmagan holda jarayonlarning aksariyatini o'zim hech qanday muammosiz amalga oshirdim.
Ushbu maqola mahsulotga taqdimot berishdan ko'ra jarayonni qayta ko'rib chiqish haqida yozilgan. Bir siklni to'g'ridan-to'g'ri tajribadan o'tkazib, qanday muammolar tug'ilganini, qayerda qiyinchilik his qilganimni va kelgusida nimalarni yaxshilash mumkinligini tartibga solmoqchiman.
2. Rejalashtirish — dasturchi emas, foydalanuvchi nuqtai nazaridan
Rejalashtirish bosqichida eng ko'p o'ylagan narsam foydalanuvchining foydalanish oqimi edi. Dasturlash jarayonida amalga oshiriladigan ish oddiy yo'nalishga qarab tabiiy ravishda e'tibor qaratilishiga olib kelishi mumkin. Biroq, foydalanuvchi real hayotda qanday harakatlar qilishini avvalroq eslab o'tishga harakat qildim.
Yana bir namuna ro'yxatda element statusini o'zgartirish funksiyasi bo'ldi. Dasturchi nuqtai nazaridan satrni bosib, batafsil ekraniga o'tib, qiymatni o'zgartirish va saqlash usuli eng oddiy hisoblanadi. Ekran tuzilishi ham aniq va amalga oshirish murakkabligi ham past.
Biroq, haqiqiy foydalanish senariysi haqida o'ylaganimda, foydalanuvchilar ko'plab elementlarni tekshirib, holatlarni tezda o'zgartirishi ko'p uchraydi. Batafsil ekranlarga takroran o'tish usuli elementlar soni ko'paygan sari keraksiz bosish va ekran almashinuvi yuz beraveradi.
Shuning uchun ro'yxat ekranida darhol holatni o'zgartirish imkonini beruvchi inline tahrirlash usulini tanladim. Amalga oshirish jarayonida satr bo'yicha holatni boshqarish, saqlashda xato bo'lganda tiklash, optimism yangilash kabi qo'shimcha ishlar kerak bo'ldi. Dasturlash xarajatlari oshdi, lekin foydalanuvchining takroran bajarishi kerak bo'lgan ishlarni kamaytirish mumkin bo'ldi.
Albatta, har qanday qarorni amalga oshirishda faqat foydalanuvchi qulayligini hisobga olish mumkin emas. Vaqt va xarajatlarning haqiqiy cheklovlari ham bor. Biroq, qanday tanlov qilsangiz ham, uning sababini aniq anglash muhim deb hisoblardim. Foydalanuvchi tajribasi uchun qabul qilingan tanlovmi yoki muddatlar asosida murosa qilingan tanlovmi, buni farqlash kerakligi sababli keyingi takliflar ham aniqroq bo'ladi.
3. Nashr so'rovi — yetkazishdan muhim bo'lgan narsa yig'ish
Ushbu siklda eng ko'p o'rganilgan bosqich nashr so'rovi jarayoni edi. Nashrning o'zi alohida jamoa tomonidan amalga oshirilgan bo'lsa-da, men uchun belgilangan rol ishni oddiygina chiqarib berish emas, balki qarshi tomon ish olib borishi mumkin bo'lgan holatda yig'ish edi.
Dastlab ekran funksiyasi va tuzilishini tushuntirish bilan kifoyalanishim yetarli deb o'yladim. Biroq, haqiqiy hamkorlik jarayonida men odatiy deb hisoblagan ma'lumotlar qarshi tomon uchun shunday emas edi. Ekran holati yoki harakat usuli, istisno holatlariga nisbatan me'yorlar aniq bo'lmasa, tabiiy ravishda qo'shimcha muhokama va tuzatish ishlari yuzaga keldi.
Yana bir fikrni angladim, ishni boshlashdan oldin yetarli empatiya muhimdir. Har bir kishi o'zida tasavvur qilayotgan ekran ozroq farq qilishi mumkin, shuning uchun buni oldindan muvofiqlashtirmasak, ishdan so'ng yana ko'rsatmalar berish xarajatlari o'ylagandan ko'ra ko'proq bo'ldi.
Natijada nashr so'rovi oddiy uzatish vazifasi emas edi. Men tushungan ma'lumotni qanchalik aniq yig'ish va baham ko'ra olishim hamkorlikning samaradorligini sezilarli darajada ta'sir qiladi. Ushbu tajriba orqali hamkorlikda yuzaga keladigan ko'plab muammolar ish salohiyati muammosi emas, balki ma'lumot uzatish muammosi bo'lishi mumkinligini his qildim.
Kelajakda ish so'rashdan oldin yana bir marta tartibga solib, qarshi tomon ham xuddi shunday tasavvurga ega ekanligini tekshirish jarayoniga ko'proq vaqt ajratishim kerakdek tuyulmoqda.
4. Rivojlantirish — tayyorgarlik qanchalik ko'p bo'lsa, o'sha qadar sodda bo'ladi
Bu ishda rivojlantirish bosqichi o'zi katta muammosiz o'tdi. Backend va frontendni to'liq o'zim boshqardim, lekin taxmin qilinganidan ko'p joylarda to'siqlar bo'lmagan.
Dastlab sabablarga katta e'tibor qaratmagan edim, lekin orqaga qaramaganimda rivojlantirish oson bo'lganini tushundim, chunki avvalgi bosqichda qanchadir yo'nalish belgilangan edi. Nima yaratish kerakligi, ekran qanday holatda bo'lishi kerakligi va foydalanuvchi qaysi jarayon orqali funksiyalardan foydalanishi nisbatan aniq edi. Buni hisobga olib, rivojlantirish jarayonida yangi qarorlar qabul qilishdan ko'ra, allaqachon belgilangan mazmunni amalga oshirishga e'tibor qaratish imkoniga ega bo'ldim.
Frontend va backendni birgalikda boshqarish ham foydali bo'ldi. Umuman olganda, API interfeysi yoki ma'lumotlar tuzilmasini muvofiqlashtirish jarayoni zarur, lekin bu safar bitta jarayon sifatida qarab ish yuritish imkoniyatiga ega bo'ldim. Frontendda talab qilinadigan shaklni hisobga olib, API ni loyihalash imkonini brassam, aksincha, backend tuzilmasini tushungan holda ekranlarni amalga oshirishga imkonim bo'ldi.
Bu tajribadan foydalangan holda, rivojlanish qiyinligi faqat kod yozish vaqtidagina belgilanmaydi, degan fikrni yana eslatib o'tdim. Oldingi bosqichda qancha o'ylangan va tayyorlangan bo'lsa, keyingi rivojlanish jarayonining murakkabligini ancha ham nazorat qildi. Rivojlantirish oson bo'lganligi o'rniga, nega oson bo'lishi mumkinligini o'ylashga majbur bo'lgan ish bo'ldi.
Tegishli misollarni izlaganimda, ba'zi jamoalar rivojlantirishdan ko'ra loyihalash va ekranlarni ta'riflashga ko'proq vaqt sarflashlarini eshitganim qiziquvchan bo'ldi. Dastlab rivojlanish tezligi sekin ko'rinishi mumkin, lekin aslida amalga oshirish bosqichidagi tuzatish xarajatlarini ancha kamaytirib, umumiy o'tish vaqtini qisqartirish usuli edi.
Bu ish davomida bunday usulni tanlash sabablari haqida ozgina tushuncha hosil qila oldim. Rivojlantirish bosqichida tez o'tish imkoniyati ham, barcha qarorlar oldingi bosqichda qabul qilinganligi bilan bog'liq emas edi.
5. Sinov — o'ylaganimizdan kamroq bo'lgan oxirgi bosqich
Eng ko'p achinadigan bosqich sinov bo'ldi.
Bu safar alohida sinov kodini yozmadim va tayyor ekranlarni bevosita tasdiqlash usulida tekshirdim. Funksiyalar kam bo'lgan sharoitda bu usul yetarlicha mumkin edi va aslida katta muammosiz tugatishga erishdim.
Biroq ishni tugatgandan so'ng, sinov inson xotirasiga juda bog'liq ekanini angladim. Ekranlar ko'payib, tuzatishlar takrorlangani sayin, oldin tekshirilgan funksiyalarni qayta ko'rib chiqish zarur bo'lishiga doimo duch kelaman. Hozirda nazoratga olish mumkin bo'lgan darajada, lekin hajmi kattalashgan sari bunday usulning saqlanishi qiyin ko'rinadi.
Xususan, normal ekran jarayoni tabiiy ravishda tekshirilsa, ma'lumotlar yo'q yoki xatolik yuz beradigan kabi istisno holatlar ko'proq e'tibordan chetda qolishi mumkinligini his qildim. Rivojlanish jarayonida bunday holatlarni yetarlicha hisobga olganimni o'yladim, ammo tekshirish bosqichida odatdagi ssenariyga ko'proq e'tibor qaratilishi ko'p uchraydi.
Referatni tartibga solish jarayonida boshqa jamoalarning sinov usullarini izladim. Har bir funksiyani sinov kodida boshqarishdan ko'ra, foydalanuvchilar eng ko'p foydalanadigan asosiy jarayonlarni avtomatlashtirish va qolganlarini qo'shimcha ravishda qo'lda tekshirish usuli ko'p qo'llanilishi uchun qiziqarli edi. Xususan E2E sinovlar orqali asosiy ssenariylarni tasdiqlash yoki Storybook dan foydalanib ekran holatini boshqarish misollarini ko'rish qiziqarli edi.
Hozirgi loyiha o'lchamlari bilan solishtirganda bunday tanlov biroz erta bo'lishi mumkin, lekin tekshirish jarayonining tez-tez ortishi kuzatuvchi usul deb hisoblansa, uni ko'rib chiqish kerak deb hisoblardim. Hammasini bir marta o'zgartirishdan ko'ra, hozirgi usulga kichik xavfsizlik choralarini birma-bir qo'shib borish realistik ko'rinadi.
6. Xulosa qilib
Ushbu ishda eng ahamiyatli jihat shundaki, ekraning foydalanuvchiga yetkazilish jarayonini boshidan oxirigacha boshdan kechirish imkoniyatiga ega bo'lishim edi.
Oldin rejalar, nashr, rivojlantirish, testlarni har birini alohida bosqich sifatida o'ylagandek tuyuldi. Biroq, to'liq jarayondan o'tishim orqali har bir bosqich bir-biriga qattiq bog'langanligini his qilishingiz mumkin edi. Oldingi bosqichda tayyorlangan ma'lumotlar keyingi bosqichni osonlashtirdi, aksincha, noaniq joylar oxiriga borgan sari katta xarajatlarga olib keldi.
Shuningdek, boshqa rollarning nuqtai nazaridan o'ylash imkoniyatini ham oldim. Faqatgina so'rov yuborish va natijalarni olish pozitsiyasida emas, balki qanday ma'lumotlar kerakligi va qaysi joyda qiyinchiliklar yuzaga kelishi haqida bir oz tushuncha hosil qildim. Shukrki, hamkorlik jarayonida nimalarni ko'proq tayyorlashim kerakligi haqida ham ko'p narsalar o'rgandim.
Ushbu xotira natijalar haqidagi yozuvdan ko'ra jarayon haqidagi yozuvga yaqinroq. Nima yaratganimiz ham muhim, lekin u qanday qilib yaratilishini bir to'la tajribadan o'tganim katta foyda keltirdi. Keyingi safar, qandayki aniqlangan kamchiliklarni asta-sekin to'g'rilab, yanada yaxshi bir sikl yaratishni xohlayman.
jun