Кіріспе

Экстремалды бағдарламалау (XP) – бағдарламалық жүйелерді жасауға қолданылатын шапшаң бағдарламалық әдістеме. Осы мақалада осы әдістемеде қолданылатын тәжірибелер егжей-тегжейлі сипатталады. Экстремалды бағдарламалау бағдарламалық инженерияның ең жақсы тәжірибелерінен туындаған төрт салаға бөлінген 12 тәжірибеден тұрады.

Жұптық бағдарламалау

Парлы бағдарламалау – бір тапсырманы орындау үшін екі адам бірлесіп код жасайтын бағдарламалау әдісі. Бір бағдарламашы жұмыс станциясын басқарады және негізінен кодтаудың егжей-тегжейлі аспектілеріне назар аударады. Екінші бағдарламашы кең көрініске (үлкен суретке) көбірек ден қояды және бірінші бағдарламашы жасайтын кодты үнемі тексеріп отырады. Бағдарламашылар минуттан сағатқа дейінгі аралықта рөлдерді ауыстырады. Жұптар тұрақты емес; бағдарламашылар жиі серіктестерін ауыстырады, осылайша әркімнің не істеп жатқанын білуге және жүйенің барлық бөлігімен, тіпті өз біліктілігінен тыс бөліктермен де таныс болуға мүмкіндік алады. Осы арқылы парлы бағдарламалау командалық байланысты жақсартады. (Бұл ұжымдық меншік принципімен де үйлеседі).

Жоспарлау ойыны

Экстремалды бағдарламалаудағы негізгі жоспарлау процесі – Жоспарлау ойыны. Ойын – бұл әдетте аптасына бір рет болатын, әр итерацияда өткізілетін жиналыс. Жоспарлау процесі екі бөлімге бөлінеді:

Шығарылымды жоспарлау: Бұл қандай талаптардың қандай жақын мерзімді шығарылымдарға енгізілетінін және оларды қашан жеткізу керектігін анықтауға бағытталған. Бұл процеске клиенттер мен әзірлеушілер қатысады. Шығарылымды жоспарлау үш кезеңнен тұрады:
Іздестіру кезеңі: Бұл кезеңде клиент жүйе үшін жоғары құнды талаптардың тізімін ұсынады. Бұл талаптар пайдаланушы әңгімелері карточкаларына жазылады. Міндеттеме кезеңі: Бұл кезеңде бизнес және әзірлеушілер енгізілетін функционалдыққа және келесі шығарылым күніне міндеттеме береді. Басқару кезеңі: Басқару кезеңінде жоспарды өзгертуге, жаңа талаптар қосуға және/немесе қолданыстағы талаптарды өзгертуге немесе алып тастауға болады. Итерациялық жоспарлау: Бұл әзірлеушілердің қызметтері мен тапсырмаларын жоспарлайды. Бұл процеске клиент қатыспайды. Итерациялық жоспарлау да үш кезеңнен тұрады:
Іздестіру кезеңі: Бұл кезеңде талап түрлі тапсырмаларға аударылады. Тапсырмалар тапсырма карточкаларында тіркеледі. Міндеттеме кезеңі: Тапсырмалар бағдарламалаушыларға беріледі және оларды орындауға қажетті уақыт бағаланады. Басқару кезеңі: Тапсырмалар орындалады және түпкі нәтиже бастапқы пайдаланушы әңгімесімен сәйкес келеді. Жоспарлау ойынының мақсаты – өнімді жеткізуге бағыттау. Тапсырылатын өнімдердің қажеттілігі мен өндірілуінің нақты күндерін болжаудың орнына, бұл қиын, ол "жобаны тікелей тәсілмен" жеткізуге бағытталған. Жоспарлау ойыны тәсілі тек бағдарламалық қамтамасыз ету жүйелерінен аспайтын даму аяларында ғана емес, сонымен қатар қолданылады. Мысалы, оны бизнес-шапшаңдықты дамыту үшін командалар қолданады.

Барлау кезеңі

Бұл талаптарды жинау және осы талаптардың әрқайсысының жұмысқа тигізетін әсерін бағалаудың қайталанатын процесі. Бизнес проблемасымен келді; кездесу кезінде жасаушылар осы проблеманы анықтауға және талаптарды алуға тырысады. Бизнес проблемасы негізінде әңгіме (пайдаланушы әңгімесі) жазылуы керек. Мұны бизнес жасайды, олар жүйенің бір бөлігінен не күтетінін көрсетеді. Дамушылардың бұл әңгімеге әсер етуі маңызды емес. Әңгіме пайдаланушы әңгімесі картасына жазылады. Әңгімені бағалау: Дамушылар әңгіме картасында көрсетілген жұмысты іске асыруға қанша уақыт кететінін бағалайды. Дамушылар сондай-ақ проблеманы талдау немесе шешу үшін сынақ шешімдерін жасауға болады. Бұл шешімдер бағалау үшін қолданылады және барлығы проблеманы толық түсінгеннен кейін жойылады. Қайтадан, бұл бизнес талаптарына әсер етуі керек емес. Әңгімені бөлу: Итерация жоспарлауды бастамас бұрын, әрбір жобалаудағы күрделі мәселелерді шешу қажет. Егер дамушылар әңгімені бағалай алмаса, оны бөліп, қайта жазу керек. Егер бизнес тағы талаптар келтіре алмаса, міндеттеме кезеңіне көшесіз.

Міндеттеме кезең

Бұл кезең шығындарды, пайданы және жоспарға тигізетін әсерді анықтауды қамтиды. Оның төрт компоненті бар:

Құндылығы бойынша сұрыптау: Бизнес пайдаланушы әңгімелерін Бизнес құндылығы бойынша сұрыптайды. Тәуекел бойынша сұрыптау: Даму әңгімелерді тәуекел бойынша сұрыптайды. Жылдамдық орнату: Даму олардың қандай жылдамдықпен жұмыс істей алатынын анықтайды. Көлемді таңдау: Келесі релизде аяқталуы тиіс пайдаланушы әңгімелері таңдалады. Бұл пайдаланушы әңгімелеріне сүйене отырып, релиз күні анықталады.

Құны бойынша сұрыптау

Бизнес-бөлім пайдаланушы оқиғаларын бизнес-құндылығы бойынша реттейді. Оларды үш топқа бөледі:
Маңызды: жүйе жұмыс істемейтін немесе мағынасыз болып қалатын оқиғалар. Жоғары бизнес-құндылығы бар: маңызды емес, бірақ бизнестің дамуына үлкен әсер ететін пайдаланушы оқиғалары. Қосымша мүмкіндік: бизнестің дамуына үлкен әсері жоқ пайдаланушы оқиғалары.

Басқару кезеңі

Бағыттау кезеңінде бағдарламашылар мен бизнес өкілдері процесті "бағыттай алады". Яғни, олар өзгерістер енгізе алады. Жеке пайдаланушы туралы аңдармалар немесе әртүрлі пайдаланушы туралы аңдармалардың салыстырмалы маңыздылығы өзгертілуі мүмкін; болжамдар дұрыс болмауы мүмкін. Бұл жоспарды тиісінше түзету мүмкіндігі.

Итерациялық жоспарлау

Команданың жылдамдығын ескере отырып, жоспарланатын жұмыс көлемі анықталады. Итерация ұзақтығы 1-ден 3 аптаға дейін болуы мүмкін.

Барлау кезеңі

Итерацияны жоспарлаудың зерттеу кезеңі тапсырмаларды құру және оларды іске асыруға қажетті уақытты бағалаудан тұрады. Тәжірибені тапсырмаларға айналдыру: Тапсырмаларды тапсырма карталарына жазу. Біріктіру/Бөлшектеу: Егер бағдарламашы тапсырманы тым кішкентай немесе тым үлкен деп санаса, оны бағалай алмаса, тапсырманы біріктіру немесе бөлу қажет. Тапсырманы бағалау: Тапсырманы іске асыруға кеткен уақытты бағалау.

Міндеттеме кезең

Итерацияны жоспарлау кезеңінің міндеттеме кезеңінде бағдарламашыларға әртүрлі пайдаланушы оқиғаларына сілтеме жасайтын міндеттер тағайындалады. Бағдарламашы міндетті қабылдайды: Әр бағдарламашы өзі жауапкершілік алатын міндетті таңдайды. Бағдарламашы міндетті бағалайды: Бағдарламашы енді міндетке жауапты болғандықтан, міндеттің соңғы бағасын беруі тиіс. Жұмыс жүктемесін белгілеу: Жұмыс жүктемесі бір итерация ішінде бағдарламашының жұмысына жұмсалатын идеалды уақыт мөлшерін көрсетеді. Мысалы, егер аптасына 40 сағат жұмыс уақыты болса, ал 5 сағаты жиналыстарға кетсе, онда бұл көрсеткіш 35 сағаттан аспауы керек. Теңгерімдеу: Топтың барлық бағдарламашыларына міндеттер тағайындалғаннан кейін, міндеттердің бағаланған уақыты мен жұмыс жүктемесі арасында салыстыру жасалады. Содан кейін міндеттер бағдарламашылар арасында теңестіріледі. Егер бағдарламашының жұмыс жүктемесі артық болса, басқа бағдарламашылар оның бір бөлігін өз мойнына алуы керек, және керісінше.

Сынақпен жүргізілетін даму

Бөлшек сынақтар – кодтың бөліктерінің (мысалы, класс, әдістер) функционалдығын тексеріп көрсететін автоматтандырылған сынақтар. XP (Extreme Programming) шеңберінде, код жазылатынға дейін бөлшек сынақтар жазылады. Бұл тәсіл бағдарламашыны кодтың қалай қате жұмыс істеуі мүмкін екенін ойлауға итермелейді. XP бағдарламашы белгілі бір код бөлігін аяқтады деп есептейді, егер ол кодтың қате жұмыс істеуі мүмкін жағдайларды таба алмаса. Сынақпен басқарылатын әзірлеме (Test-Driven Development) келесі қадамдарды жылдам циклмен орындайды, әр қадамға көбінесе бірнеше минуттан аспайтын уақыт бөлінеді, тіпті одан да аз уақыт қажет болуы мүмкін. Әрбір пайдаланушы әңгімесін (user story) жүзеге асыру үшін әдетте бір-екі күн жұмыс қажет болғандықтан, әңгіме үшін мұндай циклдердің көп саны қажет болады. Бөлшек сынақ жазу: Бағдарламашылар өндірістік кодта функционалдық толыққандай іске асырылмағандықтан, сәтсіз аяқталуға тиіс минималды сынақты жазады. Жаңа сынақтың сәтсіз аяқталғанын көру: Бағдарламашылар сынақтың шынымен сәтсіз аяқталғанын растайды. Бұл уақытты ысырап ету сияқты көрінсе де, бұл қадам өте маңызды, себебі ол өндірістік кодтың күйі туралы сіздің болжамыңыздың дұрыс екенін тексеріп көрсетеді. Егер сынақ сәтсіз аяқталмаса, бағдарламашылар сынақ кодінде қате бар ма, әлде өндірістік код жаңа сынақта сипатталған функционалдықты қолдай ма екенін анықтауы керек. Код жазу: Бағдарламашылар жаңа сынақтың сәтті өтуі үшін жеткілікті өндірістік код жазады. Сынақты іске қосу: Бөлшек сынақтар жаңа өндірістік кодтың жаңа сынақтан өтетінін және басқа сынақтардың сәтсіз аяқталмайтынын тексеру үшін іске қосылады. Кодты қайта құру (Refactor): Өндірістік және сынақ кодтарынан кез келген нашар кодты (code smell) жою. Жоғарыда аталған процестің күштірек нұсқасы үшін Бобтың (Uncle Bob) ТДД-ның үш ережесіне көз жүгіртіңіз.

Бүкіл команда

XP-де "клиент" – есеп төлейтін адам емес, жүйені нақты пайдаланатын адам. XP клиент әрқашан қатысуы керек және сұрақтарға жауап беруге дайын болуы тиіс дейді. Мысалы, қаржылық басқару жүйесін құрастыратын командаға қаржылық әкімші де кіруі керек.

Тұрақты интеграция

Даму тобы әрқашан бағдарламалық жасақтаманың ең соңғы нұсқасымен жұмыс істеуі тиіс. Команда мүшелерінің әрқайсысының локальды түрде әртүрлі өзгертулер мен жақсартулар енгізілген нұсқалары болуы мүмкін. Сондықтан, олар ағымдағы нұсқаларын код қоймасына әр бірнеше сағат сайын немесе маңызды үзіліс болғанда жүктеуге тырысуы керек. Үнемі интеграция жасау жоба циклының кейінгі кезеңдерінде интеграция мәселелерінен туындайтын кешігулердің алдын алады.

Жобалауды жетілдіру

XP доктринасы тек қазіргі күні қажетті нәрсені бағдарламалауды және оны мүмкіндігінше қарапайым етіп іске асыруды ұсынады, сондықтан кейде жүйе тоқтап қалуы мүмкін. Мұның бір белгісі – екі (немесе бірнеше) рет техникалық қолдау көрсету қажеттігі: функционалдық өзгерістер бірдей (немесе ұқсас) кодтың бірнеше нұсқасын өзгертуді талап ете бастайды. Тағы бір белгісі – кодтың бір бөлігіне енгізілген өзгерістер көптеген басқа бөліктерге әсер етеді. XP доктринасы мұндай жағдай туғанда, жүйе сізге архитектураны өзгертіп, кодты жаңартуды, оны қарапайымдауды және жалпылауды талап етеді дейді.

Кішігірім шығарылымдар

Бағдарламалық жасақтаманы жеткізу жиі шығарылатын, қолданыстағы функционалдық мүмкіндіктер арқылы жасалады, бұл нақты пайда әкеледі. Шағын шығарылымдар клиентке жобаның барысына сенімділік қалыптастыруға көмектеседі. Бұл команданың барлық мүшелерінің біртұтас жұмыс істеу қағидасын сақтауға мүмкіндік береді, себебі клиент енді жоба бойынша нақты тәжірибесіне сүйене отырып ұсыныстар жасай алады.

Кодтау стандарты

Кодтау стандарты – жоба бойындағы барлық әзірлеу тобының келісіп ұстануға міндетті ережелер жиынтығы. Стандарт таңдалған бағдарламалау тілінде бастапқы кодтың біркелкі стилін және форматын, сондай-ақ ақаулардың пайда болу ықтималдығын азайту үшін қолданудан аулақ болу керек әртүрлі бағдарламалау құрылымдарын мен үлгілерін анықтайды. Кодтау стандарты тіл жасаушысының белгіленген стандартты талаптары (мысалы, Sun ұсынған Java бағдарламалау тіліне арналған кодтау талаптары) немесе әзірлеу тобының жеке анықтамасы болуы мүмкін. Экстремалды бағдарламалау жақтастары мүмкіндігінше өзін-өзі түсіндіретін кодты қолдайды. Бұл кодтың өзімен үйлесімсіз болатын кодқа түсініктемелерді қажет етпейді.

Кодтың ұжымдық меншігі

Кодекстің ұжымдық меншігі (кейде "командалық кодты меншік ету" және "ортақ код" деп те аталады) – барлық кодқа әркімнің жауапкершілікте болуы, демек, кез келген адам кодтың кез келген бөлігін өзгертуге құқылы. Ұжымдық кодты меншік ету – ұйымдық саясат ғана емес, сонымен қатар сезім. "Бағдарламашылар жүйе контекстін түсінгенде, тиісті кодқа үлес қосқанда, код сапасы жоғары деп санағанда, өнім пайдаланушының қажеттіліктерін қанағаттандырады деп сенгенде және командадағы ынтымақ жоғары болғанда, кодты командалық меншік ретінде сезінеді". Жұптық бағдарламалау, әсіресе жұптарды ауыстырып алмастыру, осы тәжірибеге көмектеседі: түрлі жұптармен жұмыс істеу арқылы бағдарламашылар жүйе контекстін жақсырақ түсінеді және код базасының көп бөлігіне үлес қосады. Ұжымдық кодты меншік ету дамуды үдетуі мүмкін, себебі қате байқаған әзірлеуші оны дереу түзетуге мүмкіндік алады, бұл жалпы қателер санын азайтады. Дегенмен, бағдарламашылар жақсы түсінбеген кодты өзгерту кезінде қателер жіберуі мүмкін. Бұл мәселені шешу үшін жеткілікті түрде жақсы анықталған бірлік тесттері болуы керек: егер күтпеген тәуелділіктер қате тудырса, бірлік тесттерін іске қосу сәтсіздіктерді көрсетеді. Ұжымдық кодты меншік ету команда мүшелерінің сенімді түрде қолдау көрсетуіне, білім мен тәжірибенің таралуына, кодқа ортақ жауапкершілікке, код сапасының артуына және жұмысты қайта жасау қажеттілігінің азаюына әкелуі мүмкін. Бірақ бұл команда мүшелері арасындағы қақтығыстардың күшеюіне, қателердің көбеюіне, бағдарламашылардың ойлау процесінің бұзылуына, даму уақытының ұзаруына немесе кодты түсінудің нашарлауына да алып келуі мүмкін.

Қарапайым дизайн

Бағдарламашылар бағдарламалық жасақтаманы жобалауда "қарапайымдық - ең жақсысы" қағидасын ұстануы керек. Жаңа код жазғанда автор өзінен-өзі "осы мүмкіндікті (функционалдылықты) енгізудің оңайырақ жолы бар ма?" деп сұрауы тиіс. Егер жауап "иә" болса, оңайырақ жол таңдалуы керек. Күрделі кодты оңайлату үшін рефакторингті де пайдалану қажет.

Жүйелік метафора

Жүйе метафорасы - бұл жүйенің қалай жұмыс істейтінін клиенттердің, бағдарламашылардың және менеджерлердің барлығына түсінікті болатын оқиға. Бұл – команда мүшесіне сыныптың немесе әдістің атауынан ғана оның қызметін болжауға мүмкіндік беретін сыныптар мен әдістерді атау концепциясы. Мысалы, кітапхана жүйесі қарыз алушылар үшін қарыз тіркелгілерін (сынып) жасайды, ал егер зат мерзімінен кешіксе, каталогта (сынып) мерзімінен кешіккен операциясын орындайды. Әрбір сынып немесе операцияның қызметі команданың барлық мүшелеріне түсінікті болады.

Тұрақты қарқын

Бағдарламашылар мен бағдарламалық жасақтаманы дамытушылар аптасына 40 сағаттан артық жұмыс істемеуі керек, ал егер бір аптада қосымша жұмыс болса, келесі аптада одан көп жұмыс істемеуі тиіс. Даму циклдары үздіксіз интеграцияның қысқа циклдары болғандықтан және толық даму (шығару) циклдары жиі болатындықтан, XP-дегі жобалар басқа жобаларға тән, үлкен күш жұмсауды (қарбалас уақытты) қажет етпейді. Сондай-ақ, адамдар жақсы демалыс алғанда ең жақсы нәтиже беретіні және шығармашылықпен жұмыс істейтіні осы тұжырымдамаға енгізілген. Тұрақты қарқынға қол жеткізудің маңызды факторы – жиі кодты біріктіру және әрқашан жұмыс істейтін, сынақтан өткізілген, жоғары сапалы код. Жұмыс процесіндегі үнемі жаңару команда мүшелерінің жаңа және сергек болуына көмектеседі. Команда ішіндегі қарқынды ынтымақтастық демалыс күндері қайта қуаттану қажеттілігін тудырады. Жақсы сыналған, үздіксіз интеграцияланған, жиі жарияланатын код және орталар күтпеген өндірістік мәселелер мен істен шығу жиілігін азайтады, сондай-ақ олармен байланысты кешкі және демалыс күндері жұмыс істеу қажеттілігін де азайтады.