Экстрэмальнае праграмаваньне

Экстрэма́льнае праграмава́ньне — (па-ангельску: extreme programming, XP) — парадыгма і мэтадалёгія праграмаваньня, прызначаная ў першую чаргу для распрацоўкі праектаў «малой і сярэдняй рызыкі», то бок такіх, дзе канчаткова невядомыя ўсе дэталі рэалізацыі.

Агляд

Прыхільнікі мэтадалёгіі экстрэмальнага праграмаваньня ставяць зьмены, якія адбываюцца падчас разьвіцьця мэтадалёгіі, у шэраг натуральных, непазьбежных і пажаданых аспэктаў праектаў распрацоўкі праграмнага забесьпячэньня. Яны ўпэўненыя, што здольнасьць адаптацыі да зьменлівых патрабаваньняў у любы момант існаваньня праекту — найбольш рэалістычны і больш эфэктыўны падыход, чым спроба вызначыць усе патрабаваньні ў пачатку распрацоўкі праекту, а пасьля марнаваць час на трыманьне зьменаў праекту ў межах патрабаваньняў.

Аўтарамі мэтадалёгіі экстрэмальнага праграмаваньня зьяўляюцца Кэнт Бэк, Ўорд Канінгем і Рон Джэфрыз. Кнігу па мэтадалёгіі напісаў Кэнт Бэк, якая была выдадзеная ў 1999 годзе пад назвай Extreme Programming Explained.

Мэта экстрэмальнага праграмаваньня

У кнізе Extreme Programming Explained экстрэмальнае праграмаваньне апісваецца як мэтодыка, якая зьяўляецца:

• Спробай аб’яднаць простасьць для чалавека і прадуктыўнасьць
• Мэханізмам сацыяльных зьменаў
• Шляхам да паляпшэньня
• Стылем распрацоўкі
• Тэхнікай распрацоўкі праграмнага забесьпячэньня

Асноўнай мэтай экстрэмальнага праграмаваньня зьяўляецца памяншэньне кошту зьменаў. У звычайных мэтадалёгіях распрацоўкі сыстэм патрабаваньні да сыстэмы вызначаныя ў пачатку распрацоўкі праекту і часта зьяўляюцца нязьменнымі ад моманту іх вызначэньня. Гэта азначае, што кошт зьмены патрабаваньняў на наступных стадыях распрацоўкі будзе высокім.

Экстрэмальнае праграмаваньне дазваляе скараціць выдаткі на зьмену патрабаваньняў падчас распрацоўкі. Сыстэма, падчас распрацоўкі якой выкарыстоўваецца экстрэмальнае праграмаваньне, зьяўляецца больш гнуткай у дачыненьні да магчымых зьменаў патрабаваньняў.

Практыкі экстрэмальнага праграмаваньня

Экстрэмальнае праграмаваньне мае 12 практык, аб’яднаных у чатыры групы, якія былі складзеныя на падставе лепшых практык распрацоўкі праграмнага забесьпячэньня:

Кароткі цыкль зваротнай сувязі

• Парнае праграмаваньне
• Гульня ў плянаваньне
• Распрацоўка праз тэставаньне
• Замоўца заўсёды побач

Непарыўны працэс

• Непарыўная інтэграцыя
• Паляпшэньне структуры (рэфактарынг)
• Частыя невялікія рэлізы

Усеагульнае разуменьне

• Стандарт кадаваньня
• Калектыўнае валоданьне кодам
• Прастата
• Мэтафара сыстэмы

Умовы для праграміста

• 40-гадзінны працоўны тыдзень

Кароткі цыкль зваротнай сувязі

Парнае праграмаваньне

Парнае праграмаваньне патрабуе двух праграмістаў для напісаньня коду, якія займаюцца распрацоўкай на адным працоўным месцы. Калі адзін з праграмістаў выконвае пэўнае дзеяньне, другі ў гэты момант займаецца тым, што можна зрабіць без выкарыстаньня кампутара: напрыклад, адзін піша юніт-тэст, а другі думае пра структуру клясы, які будзе пасаваць гэтаму тэсту. Першы зь іх займаецца дэтальным кадаваньнем, а другі назірае за працэсам уцэлым і праглядае код, які стварае першы праграміст. Час ад часу яны мяняюцца месцамі.

Пары не фіксаваныя: рэкамэндуецца іх перавызначаць так часта, як гэта магчыма, так каб кожны ведаў, чым займаецца любы іншы. У выніку павялічваецца ўзаемадзеяньне ўнутры каманды.

Гульня ў плянаваньне

Галоўны працэс плянаваньня ў межах мэтадалёгіі экстрэмальнага праграмаваньня называецца гульнёй у плянаваньне. Працэс плянаваньня складаецца зь дзьвюх частак. Першая — плянаваньне рэлізу — арыентаваная на вызначэньне таго, якія патрабаваньні ўключаныя ў які рэліз і калі ён мусіць быць зроблены. У гэтай частцы плянаваньня ўдзел бяруць як распрацоўнікі, так і замоўцы. Другая — плянаваньне ітэрацыі — плянаваньне задачаў і дзеяньняў распрацоўнікаў. У гэтай частцы ўдзел бяруць толькі распрацоўнікі.

Распрацоўка праз тэставаньне

Юніт-тэсты — аўтаматычныя тэсты для тэставаньня асобных частак коду. У канцэпцыі экстрэмальнага праграмаваньня юніт-тэсты пішуцца да напісаньня канчатковага коду, які мусіць прайсьці гэты тэст. Гэты падыход прызначаны для стымуляваньня праграміста да выяўленьня патэнцыйных умоў, калі ягоны код можа працаваць памылкова. Згодна экстрэмальнага праграмаваньня, праграміст скончыў напісаньне пэўнай часткі коду тады, калі ён больш ня можа прыдумаць умовы, пры якой гэты код будзе працаваць няправільна.

Замоўца заўсёды побач

У межах экстрэмальнага праграмаваньня замоўца — гэта ня той, хто плоціць грошы, а той, хто насамрэч выкарыстоўвае сыстэму. Згодна экстрэмальнага праграмаваньня, замоўца заўсёды мусіць быць на сувязі для вырашэньня пытаньняў.

Непарыўны працэс

Непарыўная інтэграцыя

Практыка непарыўнай інтэграцыі прадугледжвае, што каманда распрацоўнікаў заўжды працуе над апошняй вэрсіяй прадукта. Улічваючы, што кожны распрацоўнік можа мець уласную лякальную копію кода, ён мусіць загружаць яе для сынхранізацыі кожныя некалькі гадзін. Непарыўная інтэграцыя дазваляе пазьбегнуць затрымак пазьней, выкліканых праблемамі з інтэграцыяй.

Паляпшэньне структуры

Экстрэмальнае праграмаваньне прадугледжвае праграмаваньне толькі таго, што патрабуецца на бягучы момант, і рэалізацыю найбольш простым з дапушчальных спосабаў. Таму часам гэта можа прывесьці да тармажэньня распрацоўкі сыстэмы. Адной з праяваў гэтага зьяўляецца неабходнасьць падвойнай (ці шматразовай) падтрымкі: функцыянальныя зьмены патрабуць зьменаў аднаго і таго ж (ці падобнага) коду ў некалькіх месцах. Яшчэ адной праявай зьяўляецца тое, што пасьля зьмена коду ў адным месцы патрабуе зьменаў яго і ў іншых частках. Таму згодна экстрэмальнага праграмаваньня, калі гэта адбываецца, сыстэма паведамляе пра неабходнасьць правядзеньня рэфактарынгу коду шляхам зьмяненьня архітэктуры, каб зрабіць яе больш простай і агульнай.

Частыя невялікія рэлізы

Дэманстраваньне праграмнага забесьпячэньня адбываецца ў прамежкавых рэлізах. Агульны плян рэлізаў вызначаецца падчас пачатковага абмеркаваньня праекту. Звычайна кожны рэліз прызначаецца для дэманстрацыі работы маленькага кавалачка агульнай праграмы, які можа працаваць самастойна і не залежыць ад кампанэнтаў, якія будуць распрацаваныя ў будучыні. Частыя невялікія рэлізы дазваляюць замоўцу ўпэўніцца, што работа над праектам сапраўды ідзе.

Усеагульнае разуменьне

Стандарт кадаваньня

Стандарт кадаваньня — гэта пагадненьне адносна набору правілаў напісаньня коду, якіх уся каманда згодная прытрымлівацца падчас усяго пэрыяду распрацоўкі праекту. Стандарт вызначае стыль і фармат зыходнага коду ў межах выбранай мовы праграмаваньня. Стандарт кадаваньня можа быць як стандартам, вызначаным распрацоўнікам мовы праграмаваньня, так і зусім іншым, вызначаным толькі камандай распрацоўнікаў.

Калектыўнае валоданьне кодам

Калектыўнае валоданьне кодам азначае, што кожны адказны за ўвесь код. А гэта, у сваю чаргу, азначае, што кожны мае права ўносіць зьмены ў любую частку коду. Парнае праграмаваньне падтрымлівае гэтую практыку: працуючы ў парах, усе праграмісты атрымліваюць доступ да ўсіх частак коду. Важная перавага калектыўнага валоданьня кодам у тым, што яно паскарае распрацоўку, бо пры выяўленьні памылкі яе можа выправіць любы праграміст.

Калі ў кожнага праграміста ёсьць права зьмяняць код, узьнікае рызыка зьяўленьня памылак, што зробленыя праграмістамі, якія лічаць, што яны ведаюць, што робяць, не разглядаючы пэўныя залежнасьці. Добра створаныя юніт-тэсты вырашаюць гэтую праблему: калі неразгледжаныя залежнасьці спараджаюць памылку, яна будзе выяўленая падчас наступнага запуску юніт-тэстаў.

Прастата

Праграмісты мусяць карыстацца падыходам «просты — лепшы» у праектаваньні праграмнага забесьпячэньня. Калі аўтар піша новы кавалак коду, ён мусіць задаць сабе пытаньне, а ці найпрасьцейшы гэта спосаб рэалізаваць такую функцыянальнасьць. Вядома, што мусіць быць выбраны найпрасьцейшы спосаб, калі даступна некалькі зь іх. Для спрашчэньня складанага коду таксама мусіць выкарыстоўвацца рэфактарынг.

Мэтафара сыстэмы

Мэтафара сыстэмы — гэта канцэпцыя назваў клясаў і мэтадаў, якая мусіць зрабіць зразумелым для ўдзельнікаў каманды па назьве, што менавіта робіць тая ці іншая кляса або мэтад.

Умовы для праграміста

40-гадзінны працоўны тыдзень

Канцэпцыя палягае ў тым, што праграміст або распрацоўнік праграмнага забесьпячэньня не павінен працаваць больш за 40 гадзінаў на тыдзень, і калі падчас пэўнага тыдня адбылася перапрацоўка, то на наступным тыдні яна недапушчальная. З-за таго, што цыклі распрацоўкі зьяўляюцца кароткімі цыклямі непарыўнай інтэграцыі, і што цыклі поўнай распрацоўкі (рэліза) больш частыя, у праектах экстрэмальнага праграмаваньня адсутнічае тыповая праблема недахопу часу, як гэта часьцяком бывае ў іншых праектах і таму патрабуецца перапрацоўка.

Крытыка мэтадалёгіі

Праціўнікі парадыгмы экстрэмальнага праграмаваньня высоўваюць наступныя пункты крытыкі мэтадалёгіі:

• Адсутнасьць дакладнай спэцыфікацыі
• Пастаянны доступ да працэсу распрацоўкі прадстаўніка кліента
• Калектыўнае валоданьне кодам — кожны можа зьмяняць любую частку сыстэмы.