GitHubda PR qachon tez ko’rib chiqiladi?

GitHubda PR qachon tez ko’rib chiqiladi?

GitHubda PR qachon tez ko'rib chiqiladi?

Siz kichik yoki katta jamoada ishlayotgan, yoki bir nechta vaqt zonalarida tarqalgan jamoada yoki hamma #WFH (uydan ishlash) ishlayotgan bo’lishi mumkun bunday holatlarda sizning PR(Pull Request) ko’rib chiqish ko’p vaqt talab qiladi va siz buni odatda ko’p vaqt kutasiz.

Pull Request (PR) ko’rib chiqish jarayonini tezlashtrish, hamkasblardan tezroq fikr olishni(feedback) osonlashni ko’rib chiqamiz.

PR muallifi sifatida:

Agar dasturchi rassom bo’lsa Pull Request(PR) bu san’at

Xususiyat(feature) yoki vazifani amalga oshirishda:

  • JIRA chiptasidan Qabul qilish mezonlarini(AC) yoki Github muammosi tafsilotlarini yaxshi tushunganingizga ishonch hosil qiling.
  • Tech Lead yoki Senior dasturchilarga vazifa integratsiyasining taklif qilingan arxitekturasini muhokama qiling(agar kerak bo’lsa).
  • Arxitektura eng so’nggi amaliyotlariga rioya qilishiga va SOLID tamoyillariga asoslanganligiga ishonch hosil qiling.
  • Kod vazifani qabul qilish mezonlariga muvofiq tasdiqlash uchun tegishli test holatlarini yozing.
PR yaratganingizda:
  • Sizda qabul qilish mezonlari(AC) bilan JIRA chiptasi yoki topshiriq tafsilotlarini o’z ichiga olgan Github muammosi bo’lishi kerak
  • Tushunish qiyinroq bo’lgan joylar uchun kod sharhlarini taqdim eting
  • Siz kiritmoqchi bo’lgan o’zgarishlarning batafsil tavsifini bering
  • PR tez ko’rib chiqish uchun etarlicha kichik ekanligiga ishonch hosil qiling.
  • PRning qat’iy o’lchami yo’q, lekin PR qancha kichik bo’lsa uning ko’rib chiqish jarayoni shunchalik tez bo’ladi va men PR 30 dan ortiq fayl qo’shmasligi/o’zgartirmasligi va qo’shimchalar/o’chirishlar 1000 qator(LOC)dan oshmasligi kerak deb hisoblayman
  • Agar PR kattalashishi mumkin bo’lsa, PRni kichikroq parchalarga bo’ling va PR tavsifida ularni takidlab o’ting. Masalan: mobil ilovada odatiy xususiyatni amalga oshirish uchun PRni quyidagilarga bo’lish mumkin:
    — №1: UI’ga bog’liq o’zgarishlarni birinchi PR’da
    — №2: API/DB integratsiyasini tegishli o’garishlarni ikkinchi PR’da
PR yaratgandan so’ng:
  • O’zingizning PRingizni ko’rib chiqing. Siz potentsial muammolarni topishingiz va ularni tezda hal qilishingiz mumkin
  • PR bo’yicha fikr-mulohazalarni(feedback) ijobiy qabul qiling, sabrli va yaxshi tinglovchi bo’ling. Hamkasblaringizdan o’rganishga ochiq bo’ling
  • Agar sharhlovchi PRga o’zgartirishlar kiritishni so’ragan bo’lsa va siz o’zgarishlar haqida to’liq tushunmasangiz, Zoom, Slack yoki MS Teams kabi boshqa aloqa kanallari orqali sharhlovchi bilan bevosita bog’lanishga harakat qiling
  • Agar sharhlovchi bilan to’g’ridan-to’g’ri aloqa o’rnatishning iloji bo’lmasa (masalan, sharhlovchi boshqa vaqt zonasida bo’lsa), qo’shimcha ma’lumot so’rab PR sharhiga xushmuomalalik bilan javob bering va yechim qanday ko’rinishi haqida har qanday taklifni so’rang

PR sharhlovchisi sifatida:

Fikr-mulohaza bildirayotganda hurmat bilan munosabatda bo’ling. Maqsad muammolarni oldindan topish va kod bazasini yaxshilashdir

  • Muallif kiritmoqchi bo’lgan o’zgarishlarni tushunish uchun PR tavsifini, JIRA chiptasini / Github nashrini o’qing.
  • Branch’ni tekshirish va yechimni ishga tushirish yaxshi amaliyotdir. Bu juda muhim, chunki siz papka tuzilishini(folder structure) ko’ra olmaysiz, foydalanilmagan importlar va UI/UX bilan bog’liq muammolar va boshqalar.
  • PR butunlay bir marta ko’rib chiqilishi kerak. Agar muallif bir vaqtning o’zida barcha fikr-mulohazalarni oladigan bo’lsa, PRni birlashtirish(merge PR) vaqti sezilarli darajada qisqarishi mumkin. Kodlarni bo’lib-bo’lib ko’rib chiqish jamoada kechikishlar va asabiylashish keltirib chiqaradi.
  • Oddiy savollar uchun o’zgartirish talab qilmang, bu ko’p holatlar uchun to’g’ri. Biroq, agar savolga javob berilmasa, PRni birlashtirmaslik kerak deb hisoblasangiz, istisnolar bo’lishi mumkin.
  • PRlarni ko’rib chiqishda aniq va oqilona bo’ling. Muallif siz so’ragan o’zgarishlarni tushunishi uchun sharhlarda misollar keltiring. Misol uchun. «Ushbu kod blokini yaxshilang.» deyish o’rniga, har qanday (psevdo) kod bilan qanday o’zgarishlar kutilishini taklif qiling.
  • Etiborli bo’ling va o’zgartirishni so’ragan PRlarni ko’ring. Bu sharhlar ko’rib chiqilayotganda PRni qayta ko’rib chiqishni o’tkazib yubormaslikni ta’minlaydi.
  • PRlarni ko’rib chiqish uchun har kuni ajratilgan vaqtni belgilang. PRlarni ko’rib chiqish bizning kundalik vazifamizning juda muhim qismidir.
  • PR boshqa dasturchilarlar tomonidan ko’rib chiqilgan va tasdiqlangan bo’lsa ham, PRni to’g’ri ko’rib chiqing. Boshqa dasturchilarlar sezmagan ayrim yaxshilanish yoki xatolarni ko’rishingiz mumkin.

Jamoa sifatida:

Kodni ko’rib chiqish haqiqiy kodni yozish kabi muhimdir. Shuning uchun siz kundalik vazifalar ro’yxatingizga kodni ko’rib chiqish uchun vaqt kiritishingiz kerak.

  • JIRA ish jarayoniga Code Review qo’shing
  • Kodni ko’rib chiqish — bu turli xil darsturchilar va vaqt zonalaridagi bir nechta darsturchilar bilan hamkorlik qilish usuli
  • Har qanday fikr-mulohazalarni minnatdorchilik bilan o’rganish va bilim almashish imkoniyati sifatida qabul qiling.

Yangi maqolani o’qish uchun shaxsiy sahifamga va @devlogsbyazizkhuja telegram kanalimga qo’shilib oling!

Umumiy Dasturlash
GitHubda PR qachon tez ko’rib chiqiladi?