Экстрэмальнае праграмаваньне: розьніца паміж вэрсіямі

д
артаграфія, вікіфікацыя, шаблён
д (артаграфія, вікіфікацыя, шаблён)
'''Экстрэма́льнае праграмава́ньне ''' — ([[Ангельская {{мова-en|анг.]] ''Extreme Programming'', ''XP''}})  — [[Парадыгма праграмаваньня|парадыгма]] і [[Мэтадалёгія праграмаваньня|мэтадалёгія праграмаваньня]], прызначаная ў першую чаргу для распрацоўкі праектаў «малой і сярэдняй рызыкі», то бок такіх, дзе канчаткова невядомаяневядомыя ўсе дэталі рэалізацыі.
 
== Агляд ==
 
Прыхільнікі мэтадалёгіі экстрэмальнага праграмаваньня ставяць зьмены, якія адбываюцца падчас разьвіцьця мэтадалёгіі, у шэраг натуральных, непазьбежных і пажаданых аспэктаў праектаў распрацоўкі праграмнага забесьпячэньня. Яны ўпэўненыя, што здольнасьць адаптацыі да зьменлівых патрабаваньняў у любы момант існаваньня праекту  — найбольш рэалістычны і больш эфэктыўны падыход, чым спроба вызначыць усе патрабаваньні ў пачатку распрацоўкі праекту, а пасьля марнаваць час на трыманьне зьменаў праекту ў межах патрабаваньняў.
 
Аўтарамі мэтадалёгіі экстрэмальнага праграмаваньня зьяўляюцца [[Кэнт Бэк]], [[Ўорд Канінгем]] і [[Рон Джэфрыз]]. Кнігу па мэтадалёгіі напісаў Кэнт Бэк, якая была выдадзеная ў [[1999]] годзе пад назвай ''Extreme Programming Explained''.
У кнізе ''Extreme Programming Explained'' экстрэмальнае праграмаваньне апісваецца як мэтодыка, якая зьяўляецца:
 
* Спробай аб'яднацьаб’яднаць простасьць для чалавека і прадуктыўнасьць
* Мэханізмам сацыяльных зьменаў
* Шляхам да паляпшэньня
* Стылем распрацоўкі
* Тэхнікай распрацоўкі праграмнага забесьпячэньня
 
Асноўнай мэтай экстрэмальнага праграмаваньня зьяўляецца памяншэньне кошту зьменаў. У звычайных мэтадалёгіях распрацоўкі сыстэм патрабаваньні да сыстэмы вызначаныя ў пачатку распрацоўкі праекту і часта зьяўляюцца нязьменнымі ад моманту іх вызначэньня. Гэта азначае, што кошт зьмены патрабаваньняў на наступных стадыях распрацоўкі будзе высокім.
== Практыкі экстрэмальнага праграмаваньня ==
 
Экстрэмальнае праграмаваньне мае 12 практык, аб'яднаныхаб’яднаных у чатыры групы, якія былі складзеныя на падставе лепшых практык [[Распрацоўка праграмнага забесьпячэньня|распрацоўкі праграмнага забесьпячэньня]]:
 
'''Кароткі цыкль зваротнай сувязі'''
 
* [[#Парнае праграмаваньне|Парнае праграмаваньне]]
* [[#Гульня ў плянаваньне|Гульня ў плянаваньне]]
* [[#Распрацоўка праз тэставаньне|Распрацоўка праз тэставаньне]]
* [[#Замоўца заўсёды побач|Замоўца заўсёды побач]]
 
'''Непарыўны працэс'''
 
* [[#Непарыўная інтэграцыя|Непарыўная інтэграцыя]]
* [[#Паляпшэньне структуры|Паляпшэньне структуры]] ([[рэфактарынг]])
* [[#Частыя невялікія рэлізы|Частыя невялікія рэлізы]]
 
'''Усеагульнае разуменьне'''
 
* [[#Стандарт кадаваньня|Стандарт кадаваньня]]
* [[#Калектыўнае валоданьне кодам|Калектыўнае валоданьне кодам]]
* [[#Прастата|Прастата]]
* [[#Мэтафара сыстэмы|Мэтафара сыстэмы]]
 
'''Умовы для праграміста'''
 
* [[#40-гадзінны працоўны тыдзень|40-гадзінны працоўны тыдзень]]
 
=== Кароткі цыкль зваротнай сувязі ===
 
==== Парнае праграмаваньне ====
 
Парнае праграмаваньне патрабуе двух праграмістаў для напісаньня коду, якія займаюцца распрацоўкай на адным працоўным месцы. Калі адзін з праграмістаў выконвае пэўнае дзеяньне, другі ў гэты момант займаецца тым, што можна зрабіць без выкарыстаньня кампутара: напрыклад, адзін піша [[юніт-тэст]], а другі думае пра структуру клясы, які будзе пасаваць гэтаму тэсту. Першы зь іх займаецца дэтальным кадаваньнем, а другі назірае за працэсам уцэлым і праглядае код, які стварае першы праграміст. Час ад часу яны мяняюцца месцамі.
 
Пары не фіксаваныя: рэкамэндуецца іх перавызначаць так часта, як гэта магчыма, так каб кожны ведаў, чым займаецца любы іншы. У выніку павялічваецца ўзаемадзеяньне ўнутры каманды.
==== Гульня ў плянаваньне ====
 
Галоўны працэс плянаваньня ў межах мэтадалёгіі экстрэмальнага праграмаваньня называецца гульнёй у плянаваньне. Працэс плянаваньня складаецца з дзьвюх частак. Першая  — плянаваньне рэлізу  — арыентаваная на вызначэньне таго, якія патрабаваньні ўключаныя ў які рэліз і калі ён мусіць быць зроблены. У гэтай частцы плянаваньня ўдзел бяруць як распрацоўнікі, так і замоўцы. Другая  — плянаваньне ітэрацыі  — плянаваньне задач і дзеяньняў распрацоўнікаў. У гэтай частцы ўдзел бяруць толькі распрацоўнікі.
 
==== Распрацоўка праз тэставаньне ====
 
[[Юніт-тэст]]ы  — аўтаматычныя тэсты для тэставаньня асобных частак коду. У канцэпцыі экстрэмальнага праграмаваньня юніт-тэсты пішуцца да напісаньня канчатковага коду, які мусіць прайсьці гэты тэст. Гэты падыход прызначаны для стымуляваньня праграміста да выяўленьня патэнцыйных умоў, калі ягоны код можа працаваць памылкова. Згодна экстрэмальнага праграмаваньня, праграміст скончыў напісаньне пэўнай часткі коду тады, калі ён больш ня можа прыдумаць умовы, пры якой гэты код будзе працаваць няправільна.
 
==== Замоўца заўсёды побач ====
 
У межах экстрэмальнага праграмаваньня замоўца  — гэта ня той, хто плоціць грошы, а той, хто насамрэч выкарыстоўвае сыстэму. Згодна экстрэмальнага праграмаваньня, замоўца заўсёды мусіць быць на сувязі для вырашэньня пытаньняў.
 
=== Непарыўны працэс ===
 
==== Непарыўная інтэграцыя ====
 
 
=== Усеагульнае разуменьне ===
 
==== Стандарт кадаваньня ====
 
Стандарт кадаваньня  — гэта пагадненьне адносна набору правілаў напісаньня коду, якіх уся каманда згодная прытрымлівацца падчас усяго пэрыяду распрацоўкі праекта. Стандарт вызначае стыль і фармат зыходнага коду ў межах выбранай мовы праграмаваньня. Стандарт кадаваньня можа быць як стандартам, вызначаным распрацоўнікам [[мова праграмаваньня|мовы праграмаваньня]], так і зусім іншым, вызначаным толькі камандай распрацоўнікаў.
 
==== Калектыўнае валоданьне кодам ====
==== Прастата ====
 
Праграмісты мусяць карыстацца падыходам «просты  — лепшы» у праектаваньні праграмнага забесьпячэньня. Калі аўтар піша новы кавалак коду, ён мусіць задаць сабе пытаньне, а ці найпрасьцейшы гэта спосаб рэалізаваць такую функцыянальнасьць. Вядома, што мусіць быць выбраны найпрасьцейшы спосаб, калі даступна некалькі зь іх. Для спрашчэньня складанага коду таксама мусіць выкарыстоўвацца рэфактарынг.
 
==== Мэтафара сыстэмы ====
 
Мэтафара сыстэмы  — гэта канцэпцыя назваў [[кляса (праграмаваньне)|клясаў]] і [[мэтад (праграмаваньне)|мэтадаў]], якая мусіць зрабіць зразумелым для удзельнікаў каманды па назьве, што менавіта робіць тая ці іншая кляса або мэтад.
 
=== Умовы для праграміста ===
 
==== 40-гадзінны працоўны тыдзень ====
 
Канцэпцыя палягае ў тым, што праграміст або распрацоўнік праграмнага забесьпячэньня не павінен працаваць больш за 40 гадзінаў на тыдзень, і калі падчас пэўнага тыдня адбылася перапрацоўка, то на наступным тыдні яна недапушчальная. З-за таго, што цыклі распрацоўкі зьяўляюцца кароткімі цыклямі непарыўнай інтэграцыі, і што цыклі поўнай распрацоўкі (рэліза) больш частыя, у праектах экстрэмальнага праграмаваньня адсутнічае тыповая праблема недахопу часу, як гэта часьцяком бывае ў іншых праектах і таму патрабуецца перапрацоўка.
 
 
== Крытыка мэтадалёгіі ==
* Адсутнасьць дакладнай спэцыфікацыі
* Пастаянны доступ да працэсу распрацоўкі прадстаўніка кліента
* Калектыўнае валоданьне кодам  — кожны можа зьмяняць любую частку сыстэмы.
 
[[Катэгорыя:Праграмаваньне]]
156 705

зьменаў