Екстремно програмиране: Разлика между версии
Vodnokon4e (беседа | приноси) м Грешки в статичния код: Липсващ затварящ таг; форматиране: 16x тире, 6lokavica, 7 интервала, кавички, тире-числа (ползвайки Advisor) |
м интервал; козметични промени |
||
Ред 30: | Ред 30: | ||
XP има 12 практики, групирани в 4 области, който са наследени от най-добрите практики на софтуерното инженерство: |
XP има 12 практики, групирани в 4 области, който са наследени от най-добрите практики на софтуерното инженерство: |
||
*'''Fine scale feedback:''' |
* '''Fine scale feedback:''' |
||
**'''''[[Програмиране по двойки]]''''' – двама програмисти, който работят заедно на един компютър, driver и navigator. Докато driver-a пише на компютъра, navigator-а следи работата му. И е добре на половин час да си разменят ролите, а всеки ден да се сменят партньорите. Предимствата на pair programming-а са че по този начин се пише по-верен код, правят се по-малко логически грешки; разменят се знания, защото колкото и да знае даден човек никога не може да знае всичко и винаги може да научи повече; така се сближават хората от екипа, нещо много важно за XP. Ако хората се сменят по-често повече от тях ще бъдат въведени в различните features и по този начин всеки ще е много по-добре запознат с цялостния продукт и комуникацията ще е по-лесна. Смята се, че по този начин има по-малко прекъсвания на работата, което води по-голяма продуктивност. Друго предимство е, че по-малко компютри са необходими, за да се свърши работата, при което свободните могат да бъдат използвани за други цели. |
** '''''[[Програмиране по двойки]]''''' – двама програмисти, който работят заедно на един компютър, driver и navigator. Докато driver-a пише на компютъра, navigator-а следи работата му. И е добре на половин час да си разменят ролите, а всеки ден да се сменят партньорите. Предимствата на pair programming-а са че по този начин се пише по-верен код, правят се по-малко логически грешки; разменят се знания, защото колкото и да знае даден човек никога не може да знае всичко и винаги може да научи повече; така се сближават хората от екипа, нещо много важно за XP. Ако хората се сменят по-често повече от тях ще бъдат въведени в различните features и по този начин всеки ще е много по-добре запознат с цялостния продукт и комуникацията ще е по-лесна. Смята се, че по този начин има по-малко прекъсвания на работата, което води по-голяма продуктивност. Друго предимство е, че по-малко компютри са необходими, за да се свърши работата, при което свободните могат да бъдат използвани за други цели. |
||
**'''''Planning Game''''' – основния planning process; самият planning game е среща на екипа, която се състои веднъж на всяка итерация (обикновено веднъж седмично). Самият planning process се състои от 2 части: release planning и iteration planning |
** '''''Planning Game''''' – основния planning process; самият planning game е среща на екипа, която се състои веднъж на всяка итерация (обикновено веднъж седмично). Самият planning process се състои от 2 части: release planning и iteration planning |
||
**'''''Release Planning''''' – фокусира върху това какви изисквания има за следващия release. Състои се от 3 фази: |
** '''''Release Planning''''' – фокусира върху това какви изисквания има за следващия release. Състои се от 3 фази: |
||
***'''''Exploration Phase''''' – клиента казва какви са изискванията му |
*** '''''Exploration Phase''''' – клиента казва какви са изискванията му |
||
***'''''Commitment Phase''''' – има договаряне каква точно функционалност ще се търси при следващия release и кога се очаква да излезе |
*** '''''Commitment Phase''''' – има договаряне каква точно функционалност ще се търси при следващия release и кога се очаква да излезе |
||
***'''''Steering Phase''''' – при тази фаса изискванията може да бъдат подобрени, да бъдат добавени нови, да бъдат премахнати някой от старите |
*** '''''Steering Phase''''' – при тази фаса изискванията може да бъдат подобрени, да бъдат добавени нови, да бъдат премахнати някой от старите |
||
**'''''Iteration Planning''''' – Тук се обсъждат вече дейностите и задачите на разработчиците, клиента не се намесва. Състои се от 3 фази: |
** '''''Iteration Planning''''' – Тук се обсъждат вече дейностите и задачите на разработчиците, клиента не се намесва. Състои се от 3 фази: |
||
***'''''Exploration Phase''''' – Изискванията се разпределят в различни задачи. |
*** '''''Exploration Phase''''' – Изискванията се разпределят в различни задачи. |
||
***'''''Commitment Phase''''' – Задачите се разпределят между разработчиците и ще бъде оценено времето, необходимо за завуршването им |
*** '''''Commitment Phase''''' – Задачите се разпределят между разработчиците и ще бъде оценено времето, необходимо за завуршването им |
||
***'''''Steering Phase''''' – Представят се завършените задачи и се сравняват с предварителните изисквания |
*** '''''Steering Phase''''' – Представят се завършените задачи и се сравняват с предварителните изисквания |
||
**''''' [[Test Driven Development]]''''' – Използват се Unit tests, който се пишат още преди да е написан кода, за да могат предварително да се предвидят ситуациите, в който кода може да fail-не. При ХР се смята, че продукта е завършен когато не могат да изникнат нови състояния при който кода да fail-не. |
** ''''' [[Test Driven Development]]''''' – Използват се Unit tests, който се пишат още преди да е написан кода, за да могат предварително да се предвидят ситуациите, в който кода може да fail-не. При ХР се смята, че продукта е завършен когато не могат да изникнат нови състояния при който кода да fail-не. |
||
**''''' Whole Team''''' – При ХР клиента е този, за когото е предназначен самия продукт; с ХР не се създават продукти по принцип, за много хора; създават се за даден конкретен клиент, който впоследствие ще използва продукта и самите разработчици поддържат връзка с него. |
** ''''' Whole Team''''' – При ХР клиента е този, за когото е предназначен самия продукт; с ХР не се създават продукти по принцип, за много хора; създават се за даден конкретен клиент, който впоследствие ще използва продукта и самите разработчици поддържат връзка с него. |
||
*'''Continuous process:''' |
* '''Continuous process:''' |
||
**''''' Continuous Integration''''' – Практика, в която разработчиците интегрират често работата си. |
** ''''' Continuous Integration''''' – Практика, в която разработчиците интегрират често работата си. |
||
**''''' Design Improvement''''' – code refactoring |
** ''''' Design Improvement''''' – code refactoring |
||
**''''' Small Releases''''' |
** ''''' Small Releases''''' |
||
*'''Shared Understanding:''' |
* '''Shared Understanding:''' |
||
** '''''Coding Standards''''' |
** '''''Coding Standards''''' |
||
** '''''Collective Code Ownership''''' |
** '''''Collective Code Ownership''''' |
||
Ред 54: | Ред 54: | ||
** [http://www.mayford.ca/xp/metaphor.html System Metaphor] |
** [http://www.mayford.ca/xp/metaphor.html System Metaphor] |
||
*'''Programmer welfare:''' |
* '''Programmer welfare:''' |
||
**'''''Sustainable Pace''''' |
** '''''Sustainable Pace''''' |
||
== Външни препратки == |
== Външни препратки == |
||
*http://extremeprogramming.org |
* http://extremeprogramming.org |
||
*[http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html Code Refactoring] |
* [http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html Code Refactoring] |
||
[[Категория:Процес на софтуерното разработване]] |
[[Категория:Процес на софтуерното разработване]] |
Версия от 14:35, 16 ноември 2018
Екстремно програмиране (Extreme Programming – XP) e методология за създаване на софтуер, една от няколкото гъвкави методологии (agile software development methodologies). Основната цел на гъвкавата методология е намиране на по-добри и по-гъвкави решения при създаването на софтуер.
Основни правила от манифеста на гъвкавите методологии (agilemanifesto.org), които XP също следва са:
- Индивидуални качества и комуникация се предпочита пред строги процеси и инструменти
- Работещ софтуер за сметка на изчерпателна документация
- Клиентско съдействие измества договорно споразумение
- Лесно реагиращ на промяна софтуер вместо стриктното следване на план
Основната цел на XP методологията е да редуцира цената на проект, ако се наложи дадена промяна. Оттук си вадим извод, че XP е методология, подходяща да се използва при проекти, който имат често променящи се изисквания и тогава по-стандартни методологии (като Waterfall модела например) не са оптимални за постигане на голяма продуктивност; подходяща е при проекти, които включват нови технологии или непредвидими проблеми, свързани с имплементацията; използва се също така при по-малки и по-лесни за реализация проекти с неофициални методи; добра технология за проекти, изискващи изследване.
Принципи
XP следва свои прости правила и практики, които на пръв поглед може и да не изглеждат надеждни, но всъщност опитът показва, че дават добри резултати:
- Комуникация – при XP се стимулира вербалната комуникация, за разлика от другите концепции, при който комуникацията става чрез документацията.
- Простота – при XP се започва с възможно най-опростен дизайн и решение на дадения проблем, който се подобрява, чрез refactoring като при този начин на програмиране се пише за днес, а не за утре.
- Обратна връзка
- от системата – с помощта на тестове на единици или периодични интеграционни тестове програмистите имат директна обратна връзка от състоянието на системата след като промените са били въведени; с помощта на тази обратна връзка по-лесно може да се открие грешка в кода и дадения фрагмент да се пренапише.
- от клиента – функционалните тестове са писани от клиента и от тестерите. Те ще получат ясна представа от моментното състояние на системата. Тези тестове са предвидени да се правят веднъж на 2 – 3 седмици, за да може клиентът отблизо да следи развитието.
- от екипа – след като клиента веднага каже новите си изисквания екипът веднага да може да даде конкретен отговор колко точно време ще отнеме да се имплементират новите изисквания.
- Кураж – кураж да правиш дизайн и пишеш код за днес, а не за утре; кураж да пренапишеш даден код, който не отговаря на новите изисквания, независимо от факта, че си му отделил много време и усилия, куража кара разработчиците да се чувстват добре, когато техния код има нужда от refactoring.
- Уважение – в XP членовете на екипа трябва се уважават един друг, защото се смята, че по-този начин се подобрява работата в екипа, при което се получават по-добри резултати.
Дейности
Дейности, който XP описва и който се използват при самия процес на софтуера разработка:
- Кодиране – Защитниците на XP смятат, че единсвтеното наистина важно нещо в разработката на софтуер е писането на код.
- Тестването – без тестване не можем да бъдем сигурни дали нашия продукт наистина отговаря на изискванията на спецификацията; не можем да сме сигурни дали това, което сме написали е това, което сме искали да напишем – за целта използваме Unit Test; не можем да бъдем сигурни дали това, което сме имали предвид е това, което е трябвало да имаме предвид – за да проверим това правим приемствени тестове(acceptance tests) на изискванията, който са дадени от клиента (дадени в exploration phase of release planning).
- Слушане – За програмистите по принцип не е необходимо да са наясно с бизнес страната на самата система. От друга страна те трябва да „слушат“, за да знаят от какво се нуждае клиента.
- Правене на дизайн – При създаването на продукт, използвайки ХР, едно от най-важните неща е създаването на добър дизайн в началото.
Добри практики
XP има 12 практики, групирани в 4 области, който са наследени от най-добрите практики на софтуерното инженерство:
- Fine scale feedback:
- Програмиране по двойки – двама програмисти, който работят заедно на един компютър, driver и navigator. Докато driver-a пише на компютъра, navigator-а следи работата му. И е добре на половин час да си разменят ролите, а всеки ден да се сменят партньорите. Предимствата на pair programming-а са че по този начин се пише по-верен код, правят се по-малко логически грешки; разменят се знания, защото колкото и да знае даден човек никога не може да знае всичко и винаги може да научи повече; така се сближават хората от екипа, нещо много важно за XP. Ако хората се сменят по-често повече от тях ще бъдат въведени в различните features и по този начин всеки ще е много по-добре запознат с цялостния продукт и комуникацията ще е по-лесна. Смята се, че по този начин има по-малко прекъсвания на работата, което води по-голяма продуктивност. Друго предимство е, че по-малко компютри са необходими, за да се свърши работата, при което свободните могат да бъдат използвани за други цели.
- Planning Game – основния planning process; самият planning game е среща на екипа, която се състои веднъж на всяка итерация (обикновено веднъж седмично). Самият planning process се състои от 2 части: release planning и iteration planning
- Release Planning – фокусира върху това какви изисквания има за следващия release. Състои се от 3 фази:
- Exploration Phase – клиента казва какви са изискванията му
- Commitment Phase – има договаряне каква точно функционалност ще се търси при следващия release и кога се очаква да излезе
- Steering Phase – при тази фаса изискванията може да бъдат подобрени, да бъдат добавени нови, да бъдат премахнати някой от старите
- Iteration Planning – Тук се обсъждат вече дейностите и задачите на разработчиците, клиента не се намесва. Състои се от 3 фази:
- Exploration Phase – Изискванията се разпределят в различни задачи.
- Commitment Phase – Задачите се разпределят между разработчиците и ще бъде оценено времето, необходимо за завуршването им
- Steering Phase – Представят се завършените задачи и се сравняват с предварителните изисквания
- Test Driven Development – Използват се Unit tests, който се пишат още преди да е написан кода, за да могат предварително да се предвидят ситуациите, в който кода може да fail-не. При ХР се смята, че продукта е завършен когато не могат да изникнат нови състояния при който кода да fail-не.
- Whole Team – При ХР клиента е този, за когото е предназначен самия продукт; с ХР не се създават продукти по принцип, за много хора; създават се за даден конкретен клиент, който впоследствие ще използва продукта и самите разработчици поддържат връзка с него.
- Continuous process:
- Continuous Integration – Практика, в която разработчиците интегрират често работата си.
- Design Improvement – code refactoring
- Small Releases
- Shared Understanding:
- Coding Standards
- Collective Code Ownership
- Simple Design
- System Metaphor
- Programmer welfare:
- Sustainable Pace