Ekstremal dasturlash amaliyotlari - Extreme programming practices

Ekstremal dasturlash (XP) an tezkor dasturiy ta'minotni ishlab chiqish amalga oshirish uchun foydalaniladigan metodologiya dasturiy ta'minot loyihalar. Ushbu maqolada ushbu metodologiyada qo'llaniladigan amaliyotlar batafsil bayon etilgan. Ekstremal dasturlash to'rt yo'nalish bo'yicha guruhlangan 12 ta amaliyotga ega eng yaxshi amaliyotlar ning dasturiy ta'minot.[1]

Nozik o'lchovli teskari aloqa

Dasturlashning juftligi

Dasturlashning juftligi barcha kodlarni bitta ish stantsiyasida bitta topshiriq bo'yicha dasturlash ikki kishi tomonidan ishlab chiqarilganligini anglatadi. Bitta dasturchi ish stantsiyasini boshqaradi va asosan batafsil kodlash haqida o'ylaydi. Boshqa dasturchi katta rasmga ko'proq e'tibor qaratadi va birinchi dasturchi tomonidan ishlab chiqarilgan kodni doimiy ravishda ko'rib chiqadi. Dasturchilar rollarni daqiqadan soatgacha davom etadilar.

Juftliklar aniqlanmagan; dasturchilar sheriklarini tez-tez almashtirib turishadi, shunda hamma hamma nima qilayotganini biladi va hamma butun tizimni, hattoki ularning mahorat doirasidan tashqaridagi qismlarni ham yaxshi biladi. Shunday qilib, juft dasturlash ham jamoaviy aloqani yaxshilashi mumkin. (Bu ham Kollektiv mulkchilik tushunchasi bilan yonma-yon yuradi).

O'yinni rejalashtirish

Ekstremal dasturlashdagi asosiy rejalashtirish jarayoni "Planning Game" deb nomlanadi. O'yin - bu takrorlash uchun bir marta, odatda haftada bir marta sodir bo'ladigan uchrashuv. Rejalashtirish jarayoni ikki qismga bo'linadi:

  • Relizni rejalashtirish: Bu qaysi talablar yaqin kelajakda chiqarilishini va ular qachon etkazib berilishini belgilashga qaratilgan. Mijozlar va ishlab chiquvchilar bularning ikkalasi. Relizni rejalashtirish uch bosqichdan iborat:
    • Qidiruv bosqichi: ushbu bosqichda mijoz tizim uchun yuqori qiymat talablarining qisqa ro'yxatini taqdim etadi. Bular yozib qo'yiladi foydalanuvchi hikoyasi kartalar.
    • Majburiyatning bosqichi: majburiyat bosqichida biznes va ishlab chiquvchilar o'zlarini qo'shiladigan funktsiyalarga va keyingi chiqish sanasiga bag'ishlashadi.
    • Rulda boshqarish bosqichi: Rulda qilish bosqichida reja sozlanishi, yangi talablar qo'shilishi va / yoki mavjud talablar o'zgartirilishi yoki olib tashlanishi mumkin.
  • Takrorlashni rejalashtirish: Bu ishlab chiquvchilarning faoliyati va vazifalarini rejalashtiradi. Ushbu jarayonda mijoz ishtirok etmaydi. Takrorlashni rejalashtirish ham uch bosqichdan iborat:
    • Qidiruv bosqichi: Ushbu bosqichda talab turli xil vazifalarga o'tkaziladi. Vazifalar vazifa kartalarida qayd etiladi.
    • Majburiyat bosqichi: Dasturchilarga topshiriqlar beriladi va uni bajarish uchun sarflanadigan vaqt taxmin qilinadi.
    • Rulni boshqarish bosqichi: Vazifalar bajariladi va yakuniy natija asl foydalanuvchi hikoyasiga mos keladi.

Rejalashtirish o'yinining maqsadi mahsulotni etkazib berishga yo'naltirishdir. Amalga oshiriladigan materiallar qachon kerak bo'lishi va ishlab chiqarilishini aniq sanalarini taxmin qilish o'rniga, buni amalga oshirish qiyin, u to'g'ridan-to'g'ri yondashuv yordamida etkazib berishga "loyihani boshqarishni" maqsad qilib qo'ygan.[2] O'yinni rejalashtirish yondashuvi, shuningdek, dasturiy ta'minotdan tashqari loyihalar va jamoalar tomonidan kontekstda qabul qilingan ishbilarmonlik chaqqonligi.[3]

Relizni rejalashtirish

Qidiruv bosqichi

Bu talablarni yig'ish va ushbu talablarning har birining ish samaradorligini baholashning takrorlanadigan jarayoni.

  • Hikoya yozing: Biznes muammoga duch keldi; uchrashuv davomida rivojlanish ushbu muammoni aniqlashga va talablarni olishga harakat qiladi. Biznes muammosi asosida, bir hikoya (foydalanuvchi hikoyasi ) yozilishi kerak. Bu biznes tomonidan amalga oshiriladi, bu erda ular tizimning bir qismini nima qilishni xohlashlarini ta'kidlashadi. Rivojlanish ushbu voqeaga hech qanday ta'sir ko'rsatmasligi muhimdir. Hikoya foydalanuvchi hikoyasi kartasida yozilgan.
  • Hikoyani taxmin qiling: rivojlanish hikoya kartasida nazarda tutilgan ishni bajarish uchun qancha vaqt ketishini taxmin qiladi. Rivojlanish, shuningdek, muammoni tahlil qilish yoki hal qilish uchun boshoqli echimlarni yaratishi mumkin. Ushbu echimlar taxmin qilish uchun ishlatiladi va har bir kishi muammoni aniq tasavvurga ega bo'lgandan keyin bekor qilinadi. Shunga qaramay, bu biznes talablariga ta'sir qilmasligi mumkin.
  • Hikoyani ajratish: Takrorlashni rejalashtirishni boshlashdan oldin har qanday dizaynning muhim murakkabligi hal qilinishi kerak. Agar rivojlanish voqeani taxmin qila olmasa, uni ajratish va yana yozish kerak.

Agar biznes boshqa talablarni ilgari sura olmasa, majburiyat bosqichiga o'tadi.

Majburiyat bosqichi

Ushbu bosqich xarajatlar, foyda va jadval ta'sirini aniqlashni o'z ichiga oladi. Uning to'rtta komponenti mavjud:

  • Qiymat bo'yicha saralash: Biznes foydalanuvchi hikoyalarini saralash Biznes qiymati.
  • Xatar bo'yicha saralash: taraqqiyot voqealarni xavf-xatarga qarab saralaydi.
  • Tezlikni o'rnating: Rivojlanish loyihani qaysi tezlikda amalga oshirishi mumkinligini belgilaydi.
  • Miqdorini tanlang: Keyingi nashrda tugallanadigan foydalanuvchi hikoyalari tanlanadi. Foydalanuvchilarning hikoyalari asosida chiqish sanasi belgilanadi.
Qiymat bo'yicha saralash

Biznes tomoni foydalanuvchi hikoyalarini biznes qiymati bo'yicha saralaydi. Ular ularni uchta qoziqqa ajratadilar:

  • Muhim: hikoyalar, ularsiz tizim ishlay olmaydi yoki ma'nosi yo'q.
  • Muhim Biznes qiymati: Ishbilarmonlik uchun muhim ahamiyatga ega bo'lgan muhim bo'lmagan foydalanuvchi hikoyalari.
  • Yaxshi bo'lishi kerak: muhim biznes qiymatiga ega bo'lmagan foydalanuvchilar haqidagi hikoyalar.
Xavf bo'yicha saralash

Ishlab chiquvchilar foydalanuvchi haqidagi hikoyalarni xavf-xatarga qarab tartiblashadi. Shuningdek, ular uchta qoziqga bo'linadi: past, o'rta va yuqori xavfli foydalanuvchilar haqidagi hikoyalar. Quyida bunga yondashishning namunasi keltirilgan:

  • Xatarlar indeksini aniqlang: har bir foydalanuvchi hikoyasiga quyidagi omillarning har biri bo'yicha 0 dan 2 gacha indeks bering:
    • To'liqlik (biz hikoyaning barcha tafsilotlarini bilamizmi?)
      • Tugallangan (0)
      • Tugallanmagan (1)
      • Noma'lum (2)
    • O'zgaruvchanlik (o'zgarishi mumkinmi?)
      • past (0)
      • o'rta (1)
      • baland (2)
    • Murakkablik (uni qurish qanchalik qiyin?)
      • oddiy (0)
      • standart (1)
      • murakkab (2)

Foydalanuvchi hikoyalari uchun barcha indekslar qo'shilib, foydalanuvchi hikoyalariga past (0-1), o'rta (2-4) yoki yuqori (5-6) xavf indekslari beriladi.

Rulda boshqarish bosqichi

Rulni boshqarish bosqichida dasturchilar va ishbilarmonlar jarayonni "boshqarishi" mumkin. Ya'ni ular o'zgarishlarni amalga oshirishi mumkin. Foydalanuvchilarning shaxsiy hikoyalari yoki turli xil foydalanuvchilar hikoyalarining nisbiy ustuvorliklari o'zgarishi mumkin; taxminlar noto'g'ri bo'lishi mumkin. Bu rejani mos ravishda sozlash uchun imkoniyatdir.

Takrorlashni rejalashtirish

Rejalashtiriladigan jamoaviy tezlikni belgilash nuqtalarini hisobga olgan holda. Takrorlanish davomiyligi 1 dan 3 haftagacha bo'lishi mumkin.

Qidiruv bosqichi

Takrorlashni rejalashtirishning tadqiqot bosqichi vazifalarni yaratish va ularni amalga oshirish vaqtini taxmin qilishdan iborat.

  • Talabni vazifalarga tarjima qiling: Vazifalar kartalariga joylashtiring.
  • Combine / Split task: Agar dasturchi topshiriqni juda kichik yoki juda katta bo'lganligi sababli baholay olmasa, dasturchi vazifani birlashtirishi yoki ajratishi kerak bo'ladi.
  • Vazifani taxmin qilish: Vazifani amalga oshirish uchun qancha vaqt ketishini taxmin qiling.
Majburiyat bosqichi

Takrorlashni rejalashtirishning majburiyat bosqichida dasturchilarga har xil foydalanuvchi hikoyalariga havola qiladigan vazifalar beriladi.

  • Dasturchi topshiriqni qabul qiladi: Har bir dasturchi o'zi uchun javobgar bo'lgan vazifani tanlaydi.
  • Dasturchi vazifani taxmin qiladi: Dasturchi endi vazifa uchun javobgar bo'lganligi sababli, u oxir-oqibat vazifani baholashi kerak.
  • O'rnatilgan yuk koeffitsienti: Yuk koeffitsienti bitta takrorlash davomida dasturchi uchun amaliy ishlab chiqish vaqtining ideal miqdorini aks ettiradi. Masalan, 40 soatlik haftada, uchrashuvlarga 5 soat ajratilsa, bu 35 soatdan oshmaydi.
  • Balanslash: Jamoa tarkibidagi barcha dasturchilarga topshiriqlar berilgach, topshiriqlarning taxminiy vaqti va yuk koeffitsienti o'rtasida taqqoslash amalga oshiriladi. Keyin dasturchilar o'rtasida vazifalar tenglashtiriladi. Agar dasturchi haddan tashqari ishdan bo'shatilgan bo'lsa, boshqa dasturchilar uning ba'zi vazifalarini bajarishi kerak va aksincha.
Rulda boshqarish bosqichi

Vazifalarni amalga oshirish iteratsiyani boshqarish bosqichida amalga oshiriladi.

  • Vazifa kartasini oling: Dasturchi o'zi bajargan vazifalardan biri uchun topshiriq kartasini oladi.
  • Hamkor toping: dasturchi bu vazifani boshqa dasturchi bilan birgalikda amalga oshiradi. Bu amalda yana muhokama qilinadi Juft dasturlash.
  • Vazifani loyihalash: Agar kerak bo'lsa, dasturchilar topshiriqning funktsional imkoniyatlarini ishlab chiqadilar.
  • Yordamida vazifani bajaring Sinovga asoslangan rivojlanish (TDD) (pastga qarang)
  • Funktsional testni ishga tushirish: Funktsional testlar (tegishli foydalanuvchi hikoyasi va topshiriq kartasidagi talablar asosida) bajariladi.

Sinovga asoslangan rivojlanish

Birlik sinovlari kod qismlarining funksionalligini tekshiradigan avtomatlashtirilgan testlar (masalan, sinflar, usullar). XP-da, birlik sinovlari yakuniy kod kodlashdan oldin yoziladi. Ushbu yondashuv dasturchini uning kodi ishlamay qolishi mumkin bo'lgan sharoitlar haqida o'ylashga undash uchun mo'ljallangan. XP-da, dasturchi kod ishlamay qolishi mumkin bo'lgan boshqa shartlarni topa olmaganida, ma'lum bir kod bilan tugatilganligini aytadi.

Sinovga asoslangan rivojlanish quyidagi bosqichlar bo'ylab velosipedda tez harakatlanish orqali davom etadi, har bir qadam ko'pi bilan daqiqalarni oladi, yaxshisi juda kam. Har bir foydalanuvchi hikoyasi odatda bir-ikki kunlik ish vaqtini talab qilishi sababli, har bir hikoya uchun juda ko'p miqdordagi bunday tsikllar kerak bo'ladi.

  • Yozing birlik sinovi: Dasturchilar ishlab chiqarish kodida funktsiyalar to'liq bajarilmaganligi sababli muvaffaqiyatsiz bo'lishi kerak bo'lgan minimal testni yozadilar.
  • Yangi testning muvaffaqiyatsizligini tomosha qiling: Dasturchilar test haqiqatan ham muvaffaqiyatsiz tugaganligini tasdiqlaydilar. Vaqtni behuda sarflash tuyulishi mumkin bo'lsa-da, bu qadam juda muhim, chunki u ishlab chiqarish kodining holatiga bo'lgan ishonchingiz to'g'riligini tasdiqlaydi. Agar test muvaffaqiyatsiz tugasa, dasturchilar test kodida xato mavjudligini yoki ishlab chiqarish kodi yangi test tomonidan tavsiflangan funktsiyalarni qo'llab-quvvatlashini aniqlashlari kerak.
  • Kodni yozing: Dasturchilar etarli miqdordagi ishlab chiqarish kodini yozadilar, shunda yangi sinov muvaffaqiyatli o'tadi.
  • Sinovni ishga tushirish: Qurilma sinovlari yangi ishlab chiqarish kodining yangi sinovdan o'tganligini va boshqa hech qanday sinovlardan o'tmaganligini tekshirish uchun amalga oshiriladi.
  • Qayta ishlovchi: Barchasini olib tashlang kod hidlaydi ham ishlab chiqarish, ham sinov kodidan.

Yuqoridagi jarayonning yanada qizg'in versiyasini Bob Tog'aning TDD ning uchta qoidasiga qarang.[4]

Butun jamoa

XP ichida "mijoz" hisobni to'laydigan emas, balki tizimdan haqiqatan ham foydalanadigan hisoblanadi. XP mijoz har doim yonida bo'lishi va savollar berish uchun tayyor bo'lishi kerakligini aytadi. Masalan, moliyaviy boshqaruv tizimini ishlab chiquvchi guruh tarkibiga moliyaviy ma'mur kirishi kerak.

Uzluksiz jarayon

Doimiy integratsiya

Ishlab chiquvchilar jamoasi har doim dasturiy ta'minotning so'nggi versiyasi ustida ishlashlari kerak. Turli xil jamoalar a'zolari turli xil o'zgarishlar va yaxshilanishlar bilan mahalliy ravishda saqlangan versiyalarga ega bo'lishlari mumkinligi sababli, ular bir necha soat ichida yoki muhim tanaffus yuz berganda, o'zlarining joriy versiyasini kodlar omboriga yuklashga harakat qilishlari kerak. Doimiy integratsiya keyinchalik integratsiya muammolari sababli loyiha tsiklida kechikishlarga yo'l qo'ymaydi.

Dizaynni takomillashtirish

XP doktrinasi faqat bugungi kunda zarur bo'lgan narsalarni dasturlashni va uni iloji boricha sodda tarzda amalga oshirishni targ'ib qilganligi sababli, ba'zida bu tizimda qolib ketishi mumkin. Buning alomatlaridan biri ikki tomonlama (yoki bir nechta) parvarishlash zarurati: funktsional o'zgarishlar bir xil (yoki shunga o'xshash) kodning bir nechta nusxalarini o'zgartirishni talab qiladi. Yana bir alomat shundaki, kodning bir qismidagi o'zgarishlar boshqa ko'plab qismlarga ta'sir qiladi. XP doktrinasida aytilishicha, bu sodir bo'lganda tizim sizga aytadi refaktor kodingizni arxitekturani o'zgartirib, oddiyroq va umumiyroq qilish.

Kichik nashrlar

Dasturiy ta'minotni etkazib berish aniq qiymatni yaratadigan jonli funksiyalarning tez-tez chiqarilishi orqali amalga oshiriladi. Kichik nashrlar mijozga loyihaning rivojlanishiga ishonchni qozonishga yordam beradi. Bu butun jamoaning kontseptsiyasini saqlab qolishga yordam beradi, chunki xaridor endi haqiqiy tajribaga asoslanib loyiha bo'yicha o'z takliflarini taklif qilishi mumkin.

Umumiy tushuncha

Kodlash standarti

Kodlash standarti bu butun ishlab chiquvchi guruh loyiha davomida amal qilishga rozi bo'lgan kelishilgan qoidalar to'plamidir. Standart tanlangan dasturlash tili doirasida manba kodi uchun izchil uslub va formatni, shuningdek, nuqsonlar ehtimolini kamaytirish uchun oldini olish kerak bo'lgan turli xil dasturiy tuzilmalarni va naqshlarni belgilaydi.[5] Kodlash standarti til sotuvchisi tomonidan belgilangan standart konventsiyalar (masalan, Sun tomonidan tavsiya etilgan Java dasturlash tili uchun kod konventsiyalari) yoki ishlab chiquvchilar guruhi tomonidan belgilangan odatiy bo'lishi mumkin.

Ekstremal dasturiy ta'minotni qo'llab-quvvatlovchi kod, ya'ni o'z-o'zini hujjatlashtirish iloji boricha maksimal darajada. Bu ehtiyojni kamaytiradi kod sharhlari, bu kodning o'zi bilan sinxronlashdan chiqishi mumkin.[6]

Kollektiv kodga egalik

Kollektiv kodga egalik ("jamoaviy kodga egalik" va "umumiy kod" deb ham nomlanadi) har bir kishi barcha kodlar uchun javobgar bo'lishini anglatadi; shuning uchun hamma kodning biron bir qismini o'zgartirishi mumkin. Kollektiv kodga egalik qilish nafaqat tashkiliy siyosat, balki hissiyotdir. "Ishlab chiquvchilar tizim kontekstini tushunganlarida, ko'rib chiqilayotgan kodga o'z hissalarini qo'shganlarida, kodlar sifatini yuqori deb bilganlarida, mahsulot foydalanuvchi ehtiyojlarini qondirishiga ishonganlarida va yuqori guruhlarning birlashishini sezganlarida jamoaviy kod egaliklarini ko'proq his qiladilar."[7] Juft dasturlash, ayniqsa bir-birining ustiga o'ralgan juftlikning aylanishi ushbu amaliyotga o'z hissasini qo'shadi: turli juftliklarda ishlash orqali dasturchilar tizim kontekstini yaxshiroq tushunadilar va kod bazasining ko'proq sohalariga hissa qo'shadilar.

Jamoa kodiga egalik huquqi rivojlanishni tezlashtirishi mumkin, chunki xato topgan dasturchi uni darhol tuzatishi mumkin, bu esa xatolarni kamaytiradi. Shu bilan birga, dasturchilar kodni o'zgartirganda, ular yaxshi tushunmaydigan xatolarni ham kiritishlari mumkin. Etarli darajada aniq belgilangan birlik sinovlari bu muammoni yumshatishi kerak: agar kutilmagan bog'liqliklar xatolarni keltirib chiqaradigan bo'lsa, unda birlik sinovlari o'tkazilganda ular muvaffaqiyatsizlikka uchraydi.

Kollektiv kod egalik qilish a'zolarning zaxira nusxasini yaxshilashga, bilim va o'rganishni ko'proq taqsimlanishiga, kodning umumiy mas'uliyatiga, kodning yuqori sifatiga va qayta ishlashning pasayishiga olib kelishi mumkin. Ammo bu a'zolarning to'qnashuvini kuchayishiga, xatolarning ko'payishiga, ishlab chiquvchilarning aqliy oqimining o'zgarishiga va ularning fikrlash uzilishlariga, rivojlanish vaqtining ko'payishiga yoki kodni kamroq tushunishiga olib kelishi mumkin.[8]

Oddiy dizayn

Dasturchilar dasturiy ta'minotni loyihalashda "eng yaxshisi eng yaxshisi" yondashuvini qo'llashlari kerak. Har safar yangi kod yozilsa, muallif o'zidan "xuddi shu funktsiyani joriy qilishning oddiy usuli bormi?" Deb so'rashi kerak. Agar javob ijobiy bo'lsa, oddiyroq kursni tanlash kerak. Qayta ishlashdan murakkab kodni soddalashtirish uchun ham foydalanish kerak.

Tizim metaforasi

Tizim metaforasi - bu tizim qanday ishlashi haqida hamma - mijozlar, dasturchilar va menejerlar aytib beradigan hikoya. Bu sinflar va usullar uchun nomlash kontseptsiyasi, bu faqat bir guruh a'zosi uchun ma'lum bir sinf / usulning funktsiyasini faqat uning nomidan taxmin qilishni osonlashtirishi kerak. Masalan, kutubxona tizimi yaratishi mumkin loan_records (sinf) uchun qarz oluvchilar (sinf), va agar element muddati o'tgan bo'lsa, u make_overdue operatsiyasini bajarishi mumkin katalog (sinf). Har bir sinf yoki operatsiya uchun funktsional imkoniyat butun jamoaga ravshan.

Dasturchilarning farovonligi

Barqaror sur'at

Kontseptsiya shundan iboratki, dasturchilar yoki dasturiy ta'minot ishlab chiqaruvchilari haftada 40 soatdan ortiq ishlamasliklari kerak, agar bir hafta davomida qo'shimcha vaqt bo'lsa, keyingi haftada ko'proq ish vaqtini o'z ichiga olmaydi. Rivojlanish tsikllari doimiy integratsiyaning qisqa tsikllari bo'lgani uchun va to'liq rivojlanish (bo'shatish) davrlari tez-tez uchrab turadiganligi sababli, XP-dagi loyihalar boshqa loyihalar talab qiladigan (qo'shimcha vaqtni talab qiladigan) odatdagi siqilish vaqtiga amal qilmaydi.

Bundan tashqari, ushbu tushunchaga odamlar yaxshi dam olsalar, eng yaxshi va ijodiy ishlashlari kiradi.

Barqaror sur'atlarga erishish uchun asosiy imkoniyat tez-tez kodlarni birlashtirish va har doim bajariladigan va sinovdan o'tgan yuqori sifatli koddir. Doimiy qayta ishlash uslubi yangi va sergak ong bilan jamoa a'zolarini majbur qiladi. Jamoa disklari ichida ishlashning intensiv hamkorlik usuli dam olish kunlari to'ldirilishi kerak.

Yaxshi sinovdan o'tgan, doimiy ravishda birlashtirilgan, tez-tez joylashtirilgan kod va atrof-muhit, shuningdek, kutilmagan ishlab chiqarish muammolari va uzilishlar chastotasini va shu bilan bog'liq bo'lgan tungi va dam olish kunlari talab qilinadigan ishlarni minimallashtiradi.

Shuningdek qarang

Adabiyotlar

  1. ^ Bek, K. Ekstremal dasturlash haqida tushuntirish: O'zgarishlarni qabul qiling 2-chi. tahrir. Addison-Uesli, 2000 bet 54
  2. ^ Melnik, Grigori; Maurer, Frank (2004). Tezkor usullar bilan tanishish: uch yillik tajriba. 30-chi Euromicro konferentsiyasi materiallari. IEEE. 334-341 betlar. CiteSeerX  10.1.1.296.4732. doi:10.1109 / EURMIC.2004.1333388.
  3. ^ Leyburn, E. (2013). Tezkor tashkilotni boshqarish: biznesni boshqarish uchun oriq yondashuv. London: IT-boshqaruv nashri: 146–150.
  4. ^ Martin, Robert. "TDD ning uchta qoidasi".
  5. ^ Kolava, Adam; Huizinga, Dorota (2007). Avtomatlashtirilgan nuqsonlarning oldini olish: dasturiy ta'minotni boshqarish bo'yicha eng yaxshi amaliyot. Wiley-IEEE Computer Society Press. p. 75. ISBN  978-0-470-04212-0.
  6. ^ http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt
  7. ^ Sedano, Todd; Ralf, Pol; Pereyr, Seriya. "Jamoa kodiga egalik qilish amaliyoti va idrok etilishi". ACM.
  8. ^ Ribeyro, Danilo va Silva, Fabio va Valensa, Diana va Freytas, Elyda va Frantsiya, Sezar. (2016). Ishlab chiquvchilar nuqtai nazaridan umumiy koddan foydalanishning afzalliklari va kamchiliklari: Sifatli o'rganish.

Tashqi havolalar