Екстремно програмиране

Екстремно програмиране (на английски: eXtreme Programming – XP) e тип програмиране и проектна методология за създаване на софтуер, една от няколкото гъвкави методологии (agile software development methodologies). Основната цел на гъвкавата методология е намиране на по-добри и по-гъвкави решения при създаването на софтуер.

Основни правила от манифеста на гъвкавите методологии , които XP също следва са:

1. Индивидуални качества и комуникация се предпочита пред строги процеси и инструменти
2. Работещ софтуер за сметка на изчерпателна документация
3. Клиентско съдействие измества договорно споразумение
4. Лесно реагиращ на промяна софтуер вместо стриктното следване на план

Основната цел на XP методологията е да редуцира цената на проект, ако се наложи дадена промяна. Оттук си вадим извод, че XP е методология, подходяща да се използва при проекти, които имат често променящи се изисквания и тогава по-стандартни методологии (като Waterfall модела например) не са оптимални за постигане на голяма продуктивност; подходяща е при проекти, които включват нови технологии или непредвидими проблеми, свързани с имплементацията; използва се също така при по-малки и по-лесни за реализация проекти с неофициални методи; добра технология за проекти, изискващи изследване.

Принципи

XP следва свои прости правила и практики, които на пръв поглед може и да не изглеждат надеждни, но всъщност опитът показва, че дават добри резултати:

1. Комуникация – при XP се стимулира вербалната комуникация, за разлика от другите концепции, при които комуникацията става чрез документацията.
2. Простота – при XP се започва с възможно най-опростен дизайн и решение на дадения проблем, който се подобрява, чрез refactoring като при този начин на програмиране се пише за днес, а не за утре.
3. Обратна връзка
   • от системата – с помощта на тестове на единици или периодични интеграционни тестове програмистите имат директна обратна връзка от състоянието на системата след като промените са били въведени; с помощта на тази обратна връзка по-лесно може да се открие грешка в кода и дадения фрагмент да се пренапише.
   • от клиента – функционалните тестове са писани от клиента и от тестерите. Те ще получат ясна представа от моментното състояние на системата. Тези тестове са предвидени да се правят веднъж на 2 – 3 седмици, за да може клиентът отблизо да следи развитието.
   • от екипа – след като клиента веднага каже новите си изисквания екипът веднага да може да даде конкретен отговор колко точно време ще отнеме да се имплементират новите изисквания.
4. Кураж – кураж да правиш дизайн и пишеш код за днес, а не за утре; кураж да пренапишеш даден код, който не отговаря на новите изисквания, независимо от факта, че си му отделил много време и усилия, куража кара разработчиците да се чувстват добре, когато техния код има нужда от refactoring.
5. Уважение – в XP членовете на екипа трябва се уважават един друг, защото се смята, че по-този начин се подобрява работата в екипа, при което се получават по-добри резултати.

Дейности

Дейности, който XP описва и който се използват при самия процес на софтуера разработка:

1. Кодиране – Защитниците на XP смятат, че единственото наистина важно нещо в разработката на софтуер е писането на код.
2. Тестването – без тестване не можем да бъдем сигурни дали нашият продукт наистина отговаря на изискванията на спецификацията; не можем да сме сигурни дали това, което сме написали, е това, което сме искали да напишем – за целта използваме Unit Test; не можем да бъдем сигурни дали това, което сме имали предвид, е това, което е трябвало да имаме предвид – за да проверим това, правим приемствени тестове(acceptance tests) на изискванията, които са дадени от клиента (дадени в exploration phase of release planning).
3. Слушане – За програмистите по принцип не е необходимо да са наясно с бизнес страната на самата система. От друга страна, те трябва да „слушат“, за да знаят от какво се нуждае клиента.
4. Правене на дизайн – При създаването на продукт, използвайки ХР, едно от най-важните неща е създаването на добър дизайн в началото.

Добри практики

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

Външни препратки

• Managing software development using extreme programming
• Extreme Programming: extremeprogramming.org
• Code refactoring