Екстремальне програмування

к.т.н., доцент Каратанов Олександр Володимирович

Agile marketing statistics

Екстремальне програмування (англ. Extreme Programming, XP) − гнучка методологія розробки ПЗ в умовах неясних або швидко мінливих вимог для невеликих та середніх за розміром команд розробників.

Екстремальне програмування (англ. Extreme Programming, XP) − гнучка методологія розробки ПЗ в умовах неясних або швидко мінливих вимог для невеликих та середніх за розміром команд розробників.

Екстремальне програмування

• Назва методології виходить з ідеї застосувати корисні традиційні методи і практики розробки програмного забезпечення, піднявши їх на новий «екстремальний» рівень.

​

Екстремум функції

Екстремальне програмування

• Дванадцять основних прийомів (практик) екстремального програмування (за першим виданням книги Extreme programming explained) можуть бути об'єднані в чотири групи:
• Короткий цикл зворотного зв'язку (Fine-scale feedback)
1. Розробка через тестування (Test-driven development)
2. Гра в планування (Planning game)
3. Замовник завжди поруч (Whole team, Onsite customer)
4. Парне програмування (Pair programming)
• Безперервний, а не пакетний процес
• Безперервна інтеграція (Continuous integration)
• Рефакторинг (Design improvement, Refactoring)
• Часті невеликі релізи (Small releases)
• Розуміння, що поділяється всіма
• Простота (Simple design)
• Метафора системи (System metaphor)
• Колективне володіння кодом (Collective code ownership) або вибраними шаблонами проектування (Collective patterns ownership)
• Стандарт кодування (Coding standard or Coding conventions)
• Соціальна захищеність програміста (Programmer welfare):
• 40-годинний робочий тиждень (Sustainable pace, Forty-hour week)

Практики екстремального програмування

Рефакторинг

Гра в планування

Стандарт кодування

Замовник завжди поруч

Практики екстремального програмування

Розробка через тестування

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

Безперервна інтеграція

Часті невеликі релізи

Метафора

Простий дизайн

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

40-годинний робочий тиждень

Приймальне тестування

Управлінські та інженерні практики

Управлінські та інженерні практики

Інженерні (технічні) практики

Спрямовані на якість коду, тестованість і ефективність розробки:

Управлінські (організаційні) практики

Спрямовані на управління командою, взаємодію із замовником та керування планами:

Розробка через тестування �(test-driven development)

• Простий підхід: спочатку код, а потім до нього пишуть тести.

​

• В екстремальному програмуванні використовують test-driven development, тобто тестами вперед. Сенс у тому, щоб спочатку написати автоматичний тест, який пройде лише код із потрібною нам логікою, а після цього написати сам код. Якщо код не буде вирішувати наше завдання, то він не пройде тест. А якщо пройде, то він робить те, що потрібно.

​

• ✅ Тести – це в будь-якому випадку добре.

Розробка через тестування �(test-driven development)

• На відміну більшості інших методологій тестування в XP — одне з найважливіших складових.

​

• Екстремальний підхід у тому, що тести пишуться до написання коду.

​

• Кожен модуль повинен мати unit test — тест цього модуля; таким чином, у XP здійснюється regression testing (поворотне тестування, "непогіршення якості" при додаванні функціональності).

Розробка через тестування �(test-driven development)

• Більшість помилок виправляються на стадії кодування.

​

• Тести пишуть самі програмісти; будь-який програміст має право написати тест для будь-якого модуля.

​

• Ще один важливий принцип: тест визначає код, а не навпаки (такий підхід носить назву test-driven development), тобто шматок коду кладеться в сховище тоді і тільки тоді, коли всі тести пройшли успішно, інакше ця зміна коду відкидається.

Acceptance Testing — тестування прийнятності

• Це процес створення автоматизованих (іноді ручних) тестів, що перевіряють, чи система відповідає бізнес-вимогам і очікуванням замовника або користувача.
• На відміну від Unit tests (які пишуть розробники для коду), Acceptance Tests зазвичай пишуться спільно з бізнесом або QA.

🧪 Приклад Acceptance Test

User Story:�"Як покупець, я хочу мати змогу додати товар у кошик, щоб згодом його придбати."

Acceptance Criteria:

• Кнопка «Додати в кошик» доступна для всіх товарів
• Після натискання товар з'являється в кошику
• У кошику відображається правильна кількість товарів

Feature: Додавання товару у кошик

​

Scenario: Додавання одного товару

Given я знаходжусь на сторінці товару

When я натискаю "Додати в кошик"

Then товар має з’явитись у кошику

And кількість товарів у кошику дорівнює 1

Acceptance Test (написаний мовою Gherkin)

Планування процесу (planning game)

• Звичайний підхід: у команди є зразковий графік виходу релізів та розуміння, що має вийти на виході.
• В екстремальному програмуванні команда зустрічається із замовником кожні кілька тижнів і планує наступний етап: що робимо, що не робимо, що найважливіше зробити для проекту. Іноді це справді нагадує гру, коли у команди є записані на картках побажання замовника і їх потрібно вибудувати в оптимальному для реалізації порядку.
• ✅ Планування не зашкодило ще жодному проекту.
• ❌ Замовник повинен бути дуже залученим.

Управлінська практика

Планування процесу (planning game)

• Вся команда збирається разом, приймається колективне рішення про те, які характеристики системи будуть реалізовані в найближчій ітерації.

​

• Набір властивостей визначається користувачами.

​

• У XP трудомісткість кожної якості визначається самими програмістами (тим, хто її реалізовувати).

Управлінська практика

Spike

• Spike — це дослідження, завдання-розвідка, яке команда виконує з метою з’ясування невідомих аспектів, пов'язаних із технічним рішенням або оцінкою складності завдання.

​

• Spike не створює безпосередньо функціональність, а допомагає:
• обрати правильний підхід;
• вивчити технологію;
• перевірити гіпотезу;
• зменшити ризики невизначеності.

Навіщо потрібен Spike?

• Є завдання, яке складно оцінити через нестачу знань або відсутність інформації.
• Треба прийняти технічне рішення між кількома підходами.
• Вивчення нового API, бібліотеки, інструмента.
• Визначення того, які дані нам потрібні, щоб реалізувати вимогу.

​

• Spike ≠ фіча, яка піде в продакшн
• Spike = інвестиція в знання та зниження ризиків

Формат Spike в беклозі (Jira/Backlog)

Тісна взаємодія із замовником �(feed-back, on-site customer)

• Звичайний підхід: замовник ставить завдання, періодично дивиться на результат та відповідає на запитання команди, коли вони виникнуть.

​

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

​

• ❌ Важко знайти замовника, який буде доступний для питань 24/7 і ще розуміється на алгоритмах.

Управлінська практика

Тісна взаємодія із замовником �(feed-back, on-site customer)

• Замовник має бути членом XP-команди (on-site customer).

​

• Він пише власні історії, вибирає історії, які будуть реалізовані в конкретній ітерації, і відповідає на питання, що стосуються бізнесу.

​

• Замовник повинен бути експертом в предметній галузі, що автоматизується.

​

• Необхідна постійна наявність зворотного зв'язку із замовником (feed-back).

Управлінська практика

Парне програмування �(pair programming)

• Одна з найвідоміших XP-практик.

​

• Усі програмісти повинні працювати у парах: один пише код, інший дивиться.

​

• Таким чином, необхідно розміщувати групу програмістів в одному місці, що найлегше зробити на території замовника (всі необхідні члени команди географічно знаходяться в одному місці); XP найбільш успішно працює у нерозподілених колективах програмістів та користувачів.

Ролі програмістів

1. Драйвер – пише код.
2. Спостерігач або штурман – переглядає кожен рядок коду у міру його введення.

​

• Вони часто змінюються ролями (кожні ±30 хвилин).

​

• Під час огляду спостерігач також пропонує ідеї для покращення та вирішення можливих майбутніх проблем.

​

Як це виглядає насправді

Штурман

Драйвер

Що ти, чорт забирай, таке пишеш?

мейн пишеться через 'е' чи 'а'?

Види парного програмування

1. Експерт – експерт

​

• Експерт – новачок

​

• Новачок – новачок

Безперервна інтеграція �та часті релізи

• Звичайний підхід: випуск нових версій найчастіше прив'язаний до спринтів – нова версія виходить раз на 1-2 тижні.

​

• В екстремальному підході слід випускати код у продакшен щодня. Як тільки код проходить усі тести, він йде на випуск.

​

• 🤔 З одного боку, тести пройдені, а отже, все працює. З іншого — менше шансів переробити щось, якщо спаде на думку більш вдала думка.

Безперервна інтеграція �(continuous integration)

• Інтеграція нових частин системи повинна відбуватися якнайчастіше, як мінімум раз на кілька годин.
• Основне правило інтеграції: інтеграцію можна виконувати, якщо всі тести проходять успішно.
• Якщо тести не проходять, то програміст повинен або внести виправлення і тоді інтегрувати складові системи, або взагалі не інтегрувати їх. Правило це жорстке і однозначне — якщо у створеній частині системи є хоч одна помилка, то інтеграцію робити не можна.

Часті релізи (small releases)

• Мінімальна ітерація — один день, максимальна — місяць; чим частіше здійснюються релізи, тим більше недоліків системи буде виявлено.

​

• Перші релізи допомагають виявити недоліки на ранніх стадіях, далі функціональність системи розширюється (на підставі тих же історій користувача).

Часті релізи (small releases)

• Оскільки користувач включається в процес розробки починаючи з першого релізу, то він оцінює систему і видає історію історії плюс feedback.

​

• З цього визначається така ітерація: яким буде новий реліз.

​

• У XP все спрямоване на забезпечення безперервного зворотного зв'язку з користувачами.

Рефакторинг (refactoring)

• Рефакторинг – це оптимізація існуючого коду у бік спрощення, що передбачає постійну роботу зі спрощення коду.

​

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

​

• При реалізації кожної нової властивості системи програміст повинен подумати, чи можна спростити існуючий код і як це допоможе реалізувати нову властивість.

​

• Крім того, не можна поєднувати рефакторинг із дизайном: якщо створюється новий код, рефакторинг треба відкласти.

Рефакторинг (refactoring)

• Звичайний підхід: програмісти займаються рефакторингом в останню чергу (іноді й не займаються зовсім).
• В екстремальному програмуванні рефакторингом займаються постійно: у кожному фрагменті коду, напевно, можна щось поліпшити, а значить, можна брати будь-який старий код і переписувати його в будь-який момент. Завдяки цьому всі намагаються писати простий код, щоби при рефакторингу було менше шансів зламати логіку.
• 🤔 Іноді рефакторинг заради самого процесу не найкраще заняття у програмуванні. Але коли програму рефакторять багато разів, зазвичай вона починає працювати швидше, чого не скажеш про нові версії сучасного софту.

Проста архітектура (simple design)

• Звичайний підхід: команда від початку вибирає приблизну архітектуру проекту і дотримується її.

​

• Екстремальний підхід: команда обирає архітектуру та ідею реалізації лише поточної версії, не плануючи наперед. От будуть нові завдання та кроки — тоді й проектуватимемо далі.

​

• ❌ Іноді це може нашкодити проекту, особливо коли замість мікросервісів виходить моноліт, якого зовсім інші вимоги.
• ✅ Зате поточна версія бадьора, весела та зроблена на актуальних технологіях.

Проста архітектура (simple design)

• Будь-яка властивість системи має бути реалізована якомога простіше.

​

• Програмісти в XP-команді працюють під гаслом: «Нічого зайвого!».

​

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

Принципи простої архітектури

• DRY – не допускайте дублювання коду чи відповідальності

​

• KISS – реалізуйте функціональність найпростішим із доступних способів

​

• YAGNI – не реалізуйте функціональності більше, ніж потрібно для поточної ітерації

DRY

• Don’t Repeat Yourself «Кожна частина знання повинна мати єдине, несуперечливе та авторитетне уявлення в рамках системи».
• Приклад коду на CSS без DRY:

​

​

• Приклад коду CSS з DRY:

.block1 {color: #fff; padding: 15 px; margin: 15 px} �.block2 {color: #fff; padding: 15 px; margin: 15 px}

.block1, .block2 {color: #fff; padding: 15 px; margin: 15 px}

Scanner sc = new Scanner(System.in);�int shoot;�while (true) {� if (sc.hasNextInt()) {� shoot = sc.nextInt();� if (shoot < 0 || shoot > 9) {� System.out.println("Ви ввели неправильне число для пострілу.");� System.out.println("Введіть число від 0 до 9 для пострілу");� continue;� }� break;� } else {� String temp = sc.nextLine();� System.out.println("Ви ввели неправильне число для пострілу.");� System.out.println("Введіть число від 0 до 9 для пострілу");� }�}

Scanner sc = new Scanner(System.in);�int shoot;�while (true) {� System.out.println("Введіть число від 0 до 9 для пострілу");� if (sc.hasNextInt()) {� shoot = sc.nextInt();� if (shoot >= 0 && shoot <= 9) {� break;� }� } else {� sc.nextLine();� }� System.out.println("Ви ввели неправильне число для пострілу.");�}

WET

• Порушення принципу DRY називають WET –
1. "Write Everything Twice" (Пиши все двічі)
2. або "We Enjoy Typing" (Нам подобається друкувати).

​

• Це гра англійських слів «dry» (сухий) та «wet» (вологий).

KISS

• "Keep It Simple, Stupid" (Роби простіше, тупиця) – принцип проектування, прийнятий у ВМС США в 1960 році.
• У розробці ПЗ – принцип, що забороняє використання складніших коштів, ніж необхідно.

• Ваші методи мають бути невеликими, що не перевищують 40-50 рядків.

​

• Кожен метод має вирішувати лише одну проблему.

​

• У вас у проекті багато умов? Переконайтеся, що ви розбили їх на дрібніші блоки коду.

Less is more

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

Закон Деметри

• Закон Деметри намагається розділити обов'язки між класами та зменшити пов'язаність між ними.

​

• Забезпечити незалежність програмних об'єктів друг від друга.

​

• Зменшити спілкування чи зв'язок між різними класами.

​

• Помістити пов'язані класи в той самий пакет, модуль або каталог для досягнення узгодженості.

​

• Дотримання цієї ідеї дозволить вашому додатку бути зручнішим в обслуговуванні, зрозумілим і гнучким.

YAGNI

• «You aren't gonna need it» (Вам це не знадобиться) — процес і принцип проектування ПЗ, при якому як основна мета та/або цінність декларується відмова від надмірної функціональності, тобто відмова додавання функціональності, в якій немає безпосередньої потреби.

Метафора системи

• Дає команді уявлення про те, яким чином система працює в даний час, в яких місцях додаються нові компоненти і яку форму вони мають набути.

Колективне володіння кодом �(collective code ownership)

• Звичайний підхід: код має автора, який відповідає за його правильну роботу.

​

• Екстремальний підхід: кожен може зайти в будь-який фрагмент коду та поправити там будь-що, якщо вважає за потрібне. У результаті кожен може виправити чужу помилку будь-де.

​

• ❌ Це часто призводить до суперечок, чий код кращий і навіщо хтось поліз покращувати те, що й так працювало.

Колективне володіння кодом �(collective code ownership)

• Кожен програміст у колективі XP повинен мати доступ до коду будь-якої частини системи та вносити зміни до будь-якого коду.

​

• Обов'язкове правило: якщо програміст вніс зміни та система після цього працює некоректно, то саме цей програміст повинен виправити помилки.

​

• Інакше робота системи уподібниться до тотального хаосу.

Стандарти кодування �(coding conventions)

• Звичайний підхід: команда вибирає єдиний стиль оформлення та написання коду.
• Екстремальний підхід: за оформленням дивляться супердопитливо, намагаючись регламентувати та стандартизувати кожен чих, навіть якщо він не впливає на працездатність коду в цілому. Ідеально, коли, дивлячись на код, стає незрозуміло, хто його написав, — настільки він відповідає єдиним стандартам.

​

• ✅ Гарна практика, якої часто не вистачає багатьом розробникам.
• ❌ Але не підходить, коли потрібно отримати робочий код швидко. Зачісування дрібниць займає багато часу, але не впливає на працездатність лише на зручність підтримки.

Стандарти кодування �(coding conventions)

• Стандарти кодування потрібні для забезпечення інших практик: колективного володіння кодом, парного програмування та рефакторингу.

​

• Без єдиного стандарту виконувати ці практики як мінімум складніше, а насправді взагалі неможливо: група працюватиме в режимі постійної нестачі часу.
• Детальні стандарти не потрібні, необхідно стандартизувати лише важливі речі.
• Визначення найважливіших об'єктів стандартизації в XP суб'єктивно.

Стандарт оформлення коду

• Стандарт оформлення коду (стандарт кодування, стиль програмування, coding standards, coding convention чи programming style ) - набір правил і угод, що використовуються при написанні вихідного коду деякою мовою програмування.

​

• Найбільш відомі стандарти:
• K&R
• угорська нотація
• стандарти кодування на C# від Microsoft
• стандарти кодування на Java від Sun

Форматування програмного коду

• Це дуже корисно: щоб вирівняти програмний код – виділіть його (наприклад, CTRL+A), потім CTRL+K, CTRL+F.

​

• Редагування → Додатково → Форматувати виділений фрагмент / Форматувати документ.

​

if (<cond>) {

········<body>

}

if (<cond>)

{

········<body>

}

if (<cond>)

········{

········<body>

········}

if (<cond>)

··{

····<body>

··}

Стиль GNU

Стиль Уайтсмітс

Стиль Олмана

стиль за промовчанням пропонується у Microsoft Visual Studio

Стиль «K&R»

з книги Кернігана та Рітчі «Мова програмування Сі»

Стандарт оформлення коду. Загальне

• Поза стандартом мається на увазі:
• відсутність магічних чисел;

​

2. обмеження розміру коду по горизонталі (щоб містився на екрані, зазвичай 80 чи 120 символів) і вертикалі (щоб весь код функції чи методу вміщувався розмір одного экрана).

const int VOTING_AGE = 18;

Стандарт оформлення коду. склад

• Зазвичай стандарт оформлення коду описує:
• способи вибору назв і регістр символів для імен змінних та інших ідентифікаторів:
• запис типу змінної в її ідентифікаторі (угорська нотація) та
• регістр символів (нижній, верхній, верблюжий, верблюжий з малої літери), використання знаків підкреслення для поділу слів;
• стиль відступів при оформленні логічних блоків - чи використовуються символи табуляції, ширина відступу;
• спосіб розміщення дужок , що обмежують логічні блоки;
• використання прогалин при оформленні логічних та арифметичних виразів;
• стиль коментарів та використання документуючих коментарів.

Пробіли та відступи

• Відокремлюйте абзацами кожен оператор:

// Погана практика

int x = 3, y = 7; double z=4.25; x++;

if (a == b) { foo(); }

​

// Гарна практика

int x = 3;

int y = 7;

double z = 4.25;

​

x++;

if (a == b)

{

foo();

}

Гайд із оформлення коду на С++ від Стенфордського університету

Пробіли та відступи

• Ставте пробіли між операторами та операндами:

​

​

• Коли рядок стає довшим за 100 символів, розділіть його на кілька рядків:

​

int x = (a + b) * c / d + foo();

int result = reallyLongFunctionOne() +

reallyLongFunctionTwo() +

reallyLongFunctionThree() +

reallyLongFunctionFour();

Прогалини та відступи

• Залишайте порожні лінії між функціями та між групами виразів:

​

​

​

​

​

​

• Не повинно бути більше 9 рядків коду поспіль без вертикального відступу.

​

void foo()

{

...

}

// Порожня лінія

void bar()

{

...

}

Поради щодо стилю коду

C vs C++

• Використовуйте C++ замість C, якщо це можливо:

// Погана практика: текстовий рядок у стилі Cі

char *str = "Hello there";

​

// Гарна практика: текстовий рядок у стилі C++

string str = "Hello there";

// Погана практика

printf( "Hello, world!\n" );

​

// Гарна практика

cout << "Hello, world!" << endl;

Правила іменування

• Назвіть змінні та функції, використовуючи верблюжийРегістр.
• Називайте класи Паскальним Реєстром,
• Константи – у ВЕРХНЕМ_РЕЄСТРІ.

​

• Ім'я змінної – іменник.

​

• Ім'я функції – дієслово або починається з дієслова. Буває, що імена для стислості роблять іменниками, але дієслова зрозуміліші.

​

• Для імен використовується англійська мова (не трансліт).
• Давайте змінним описові імена, такі як firstName або homeworkScore. Уникайте однолітерних назв на зразок x або c, за винятком ітераторів на зразок i.

​

Коментарі

• Головний коментар. Розміщуйте великий коментар, який описує призначення файлу, вгорі кожного файлу. Припустіть, що читач вашого коментаря є сучасним програмістом, але не кимось, хто вже бачив ваш код раніше.

​

• Заголовок функції/конструктора. Розмістіть заголовковий коментар на кожному конструкторі та функції вашого файлу. Заголовок повинен описувати поведінку та/або мету функції.

​

• Параметри/повернення. Якщо ваша функція приймає параметри, то коротко опишіть їхню мету та зміст. Якщо ваша функція повертає значення, коротко опишіть, що вона повертає.

Коментарі

• Винятки. Якщо ваша функція навмисно видає якісь винятки для певних помилкових випадків, це вимагає згадки.

​

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

​

• TODO. Слід видалити всі // TODO коментарі перед тим, як закінчувати та складати програму.

Ефективність

• Викликаючи велику функцію та використовуючи результат кілька разів, збережіть результат у змінній замість того, щоб постійно викликати цю функцію:

// Погана практика

if (reallySlowSearchForIndex("abc") >= 0) {

remove(reallySlowSearchForIndex("abc"));

}

​

// Гарна практика

int index = reallySlowSearchForIndex("abc");

if (index >= 0) {

remove(index);

}

Коли використовуєте оператори управління на зразок if/else, for, while, завжди використовуйте {} і відповідні відступи, навіть якщо тіло всього оператора управління складається лише з одного рядка:

Ефективність if else

• Уникайте зайвих тестів if:

// Погана практика

if (grade >= 90)

{

cout << "You got an A!" ;

}

if (grade >= 80 && grade < 90)

{

cout << "You got a B!" ;

}

if (grade >= 70 && grade < 80)

{

cout << "You got a C!" ;

}

// Гарна практика

if (grade >= 90)

{

cout << "You got an A!" ;

}

else if (grade >= 80)

{

cout << "You got a B!" ;

}

else if (grade >= 70)

{

cout << "You got a C!" ;

}

Перевірка значень

• Ніколи не перевіряйте значення логічного типу, використовуючи == або != з true чи false:

// Погана практика

if (x == true) {

...

}

else if (x != true) {

...

}

​

// Гарна практика

if (x) {

...

}

else {

...

}

Рівні вкладеності

• Рівень вкладеності має бути небагато.
• Наприклад, перевірки в циклах можна робити через «continue», щоб не було додаткового рівня

for (var i = 0; i < 10; i++)

{

if (i підходить)

{

//<- рівень вкладеності 2

}

}

for (var i = 0; i < 10; i++)

{

if (i не підходить) continue;

// <- рівень вкладеності 1

}

Надмірність

• Якщо ви використовуєте один і той же код двічі або більше, знайдіть спосіб видалити зайвий код, щоб він не повторювався. Наприклад, його можна помістити у допоміжну функцію.
• Якщо повторюваний код схожий, але не зовсім, то постарайтеся зробити допоміжну функцію, яка приймає параметри і представляє частину, що розрізняється:

// Погана практика

foo();

x = 10;

y++;

...

​

foo();

x = 15;

y++;

// Гарна практика

helper(10);

helper(15);

...

​

void helper(int newX) {

foo();

x = newX ;

y++;

}

Функції

• Якщо потрібно повернути значення із функції, використовуйте значення return :

// Погана практика

void max( int a,

int b,

int &result)

{

if (a > b) result = a;

else result = b;

}

​

// Гарна практика

int max(int a, int b)

{

if (a > b) return a;

else return b;

}

Функції

• Якщо у вас є вираз if/else, який повертає логічне значення, повертайте результати тесту безпосередньо:

// Погана практика

if (score1 == score2) {

return true;

}

else {

return false;

}

​

// Гарна практика

return score1 == score2;

Вказівник або посилання як аргумент функції

• Відправляючи об'єкт у функцію як параметр, ви повинні передавати його за посиланням, оскільки якщо його буде передано як значення, то буде скопійовано весь об'єкт. Копіювання об'єктів потребує великих витрат пам'яті.
• Використовуйте змінні посилання, а не вказівники. Однією з причин є те, що посилальні змінні, на відміну від покажчиків, не можуть набувати значення NULL:

// Погана практика

// Приймає покажчик

void process(BankAccount* account) {...}

​

// Гарна практика

// Приймає адресне посилання

void process(BankAccount& account) {...}

Константне посилання

• Якщо ви передаєте об'єкт у функцію і код не змінить виду об'єкта – передайте його як const-посилання:

// Погана практика

// Приймає покажчик

void display(BankAccount account) {...}

​

// Гарна практика

// Приймає константне посилання

void display(const BankAccount& account) {...}

Класи

• Інкапсуляція. Відокремлюйте ваші об'єкти, роблячи всі поля даних у вашому класі private:

class Student

{

private:

int homeworkScore;

...

40-годинний робочий тиждень

• Звичайний підхід: у команді є якась домовленість про робочий час або кількість реалізованих ідей на тиждень. При цьому, якщо треба, можна трохи переробити чи залишитись на вихідні.

​

• В екстремальному програмуванні примусово обмежують робочий час — 40 годин на тиждень або 8 годин з понеділка по п'ятницю. Не встиг — твої проблеми, треба вчитися встигати.

​

• ✅ Ідея в тому, щоб не переробляти та був час на відпочинок.

Управлінська практика

40-годинний робочий тиждень

• Програміст не повинен працювати більше 8 годин на день.

​

• Необхідність понаднормової роботи (overtime) – це чіткий індикатор проблеми на даному конкретному напрямку розробки; до того ж замовник не платить за понаднормову роботу у XP.

​

• Пошук причин понаднормової роботи та їх якнайшвидше усунення — одне з основних правил.

Управлінська практика

Цінності XP

Сміливість

Комунікація

Простота

• Робити тільки те, що потрібно сьогодні — без зайвих функцій “на майбутнє”.
• Мінімальний, але достатній код для вирішення завдання.

Повага

Зворотний зв'язок

• Члени команди поважають один одного, працюють на спільний результат.
• Кожен вносить цінність, і кожна думка має вагу.

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

• Постійна перевірка якості: тести, часті релізи, коментарі від замовника.
• Прийняття рішень на основі результатів, а не припущень.

• Відвага змінювати код, коли це потрібно.
• Готовність визнати помилки, рефакторити, видаляти неактуальне.

План релізів

План ітерації

Приймальне тестування

Щоденна зустріч

Парне обговорення

Модульне тестування

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

Код

Гілки планування та зворотнього зв’язку в екстремальному програмуванні

Повсякденне життя ХР команди

Місяці

Тижні

Дні

День

Години

Хвилини

Секунди

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

За 2016

Практики різних методологій

ВИДИ ЗАБЕЗПЕЧЕННЯ