Пробне рішення

Створюйте пробні рішення для відповіді на складні технічні питання, для обґрунтування тих або інших технологічних рішень. При ухваленні будь-якого технологічного рішення існує ризик і пробні рішення покликані зменшити його.

Вам це не знадобиться

Утримаєтеся від заповнення системи речами, які знадобляться в майбутньому. Тільки 10% від очікуваного дійсно знадобиться вам в первинному вигляді, тобто 90% вашого часу буде витрачено даремно.

Безжально Рефакторить!

Рефакторинг зрештою економить час і покращує якість продукту.

Зберігайте код ясним і зрозумілим щоб його було легко зрозуміти, модифікувати і розширювати. Упевніться що все написано один і лише один раз. Зрештою, це займає менше часу чим доводити до пуття заплутану систему.

Кодування

• Замовник завжди поряд.

• Весь код повинен відповідати прийнятому стандарту.

• Весь код повинен бути створений парним програмуванням.

• Часта інтеграція коду.

• Колективне владіння кодом.

• Залишати оптимізацію на потім.

Замовник

Одна з вимог XP - замовник завжди доступний. Він повинен не просто допомагати команді розробників, а бути її членом. Всі фази XP проекту вимагають комунікації із замовником. Але в якості консультанта потрібний експерт.

User Stories пишуться замовником за допомогою розробників. Замовник допомагає упевнитися що більшість бажаних функцій системи покрита User Story.

У час планування релізу замовникові необхідно обговорити вибір User Stories які будуть включені в планований реліз. Також, можливо, потрібно буде погоджувати період самого релізу. Замовник ухвалює рішення що відносяться до цілей бізнесу.

Угода про кодування

Ви в команді, яка працює над даним проектом тривалий час. Люди приходять і йдуть. Ніхто не кодує поодинці і код належить всім. Завжди будуть моменти, коли необхідно буде зрозуміти і скоректувати чужий код. Розробники видалятимуть або змінюватимуть дублюючий код, аналізуватимуть і покращуватимуть чужі класи і тому подібне. З часом не можна буде сказати хто автор конкретного класу.

Отже, всі повинно підкорятися загальним стандартам кодування - форматування коди, іменування класів, змінних, констант, стиль коментарів. Всі члени команди повинні домовитися про загальні  стандарти кодування. Неважливо яких. Правило полягає в тому, що всі їм підкоряються. Ті, хто не бажає їх дотримувати покидає команду.

Парне програмування

Весь код для системи (а це означає за винятком пробних рішень) пишеться парами. Два розробники сидять поряд. Один набирає, інший дивиться. Час від часу вони міняються. Не дозволяється працювати поодинці. Якщо з якоїсь причини другої з пари пропустив щось (хворів, відходив і тому подібне) він зобов'язаний проглянути всі зміни зроблені першим.

Часта інтеграція

Розробники, по-можливості, повинні інтегрувати і випускати свій код кожні декілька годин. Кожна пара розробників повинна віддавати свій код як тільки для цього з'являється розумна можливість. Це може бути коли всі UnitTest-и проходять на 100%.

Колективне володіння кодом

Колективне володіння кодом стимулює розробників подавати ідеї для всіх частин проекту, а не тільки для своїх модулів. Будь-який розробник може змінювати будь-який код для розширення функціональності, виправлення помилок або рефакторінга.

Залишайте оптимізацію на потім

Ніколи не оптимізуйте нічого до закінчення кодування. Зробіть щоб це працювало, потім щоб працювало правильно, потім щоб працювало швидко.

Тестування

• Будь-який код повинен мати Unit Test.

• Всі Unit тести повинні проходити перед віддачею.

Функціональні тести періодично виконуються і їх результати публікуються.

Unit Test-и

Unit тести грають ключову роль в XP. Вони дозволяють швидко міняти код не боячись наробити нових помилок. Unit тест пишеться для кожного класу, тест повинен перевіряти всі аспекти роботи класу - тестувати все що може не працювати.