У видавництві “Фабула” вийшов друком україномовний переклад книги Роберта Мартіна «Чистий Agile». Публікуємо уривок із книги. 

Рефакторинг — це метод удосконалення структури коду без зміни поведінки, визначеної тестами. Інакше кажучи, ми змінюємо імена, класи, функції та вирази, не провалюючи жодного тесту. Ми вдосконалюємо структуру системи, не впливаючи на її поведінку.

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

Види змін, здійснених під час рефакторингу, варіюють від незначних формальних до глибоких реструктуризаційних. Ці зміни можуть бути простими перейменуваннями або складними замінами операторів switch на поліморфні програми виклику операцій. Великі функції буде розділено на менші, із  прийнятнішими назвами. Списки аргументів буде змінено на об’єкти. Класи з  великою кількістю методів буде розділено на багато менших класів. Функції буде переміщено з  одного класу в  інший. Із  класів буде вилучено підкласи або внутрішні класи. Залежності буде інвертовано, а  модулі  — переміщено крізь архітектурні межі.

І доки все це відбувається, ми постійно проводимо тести. 

Червоний/Зелений/Рефакторинг

Процес рефакторингу вбудовано в  три правила керованої тестами розробки за допомогою того, що називається циклом «Червоний/ Зелений/Рефакторинг» (рис. 5.1).

1. Спершу ми створюємо тест, який не спрацьовує. 

2. Потім робимо так, аби код пройшов тестування. 

3. Потім вичищаємо код. 

4. Повертаємося до кроку 1.

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

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

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

    Слово рефакторинг ніколи не повинно з’являтися в графіку робіт. Це не той різновид діяльності, який виконується плановано. Ми не резервуємо час на рефакторинг, бо це лишень частина нашого похвилинного й  погодинного підходу до написання програмного забезпечення.

Значний рефакторинг

Іноді вимоги змінюються так, що ви усвідомлюєте: наявний дизайн та архітектура системи неоптимальні і  потрібно внести значні зміни в  структуру програми. Такі зміни вносяться протягом циклу «Червоний/Зелений/Рефакторинг». Ми не створюємо проєкт програми для того, аби потім змінювати його структуру. Ми не резервуємо час у  графіку для такого значного рефакторингу. Натомість ми переносимо код невеликими кроками, продовжуючи додавати нові функції під час звичайного циклу Agile.

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

Просте проєктування

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

Правила простого проєктування Кента Бека.

1. Пройдіть всі тести. 

2. Розкрийте наміри. 

3. Видаліть продубльовані елементи. 

4. Скоротіть кількість елементів.

Цифри на позначення пунктів указують на порядок виконання дій і пріоритет, який їм надається.

    Пункт 1 цілком очевидний. Код повинен пройти всі тести. Код повинен працювати.

У пункті 2 говориться: після того як код запрацює, його слід увиразнити. Це має розкрити наміри програміста. Код повинен бути легким для читання й інформативним. Тут ми вводимо багато простих змін і  косметичних засобів для рефакторингу. Ми також розділили великі функції на дрібніші, дали їм кращі назви.

У пункті 3 вказано: після того як ми досягли максимальної описовості й  виразності коду, відбувається пошук і  видалення будь-якого дублювання в  його межах. Не слід лишати в  коді повторення того самого. Під час такої діяльності проведення рефакторингу зазвичай проходить складніше. Іноді видалити дублювання так само просто, як і перемістити дубльований код у функцію та викликати його з різних місць. В іншому разі для цього потрібні цікавіші рішення, наприклад патерни проєктування : шаблонний метод, стратегія, декоратор або відвідувач.

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

Завдання простого проєктування  — зберегти проєктну вагу коду якомога меншою.

Проєктна вага коду

Складність програмного проєкту варіює від досить простого до надзвичайно складного. Що складніша конструкція, то більшим є когнітивне навантаження на програмістів. Це навантаження — проєктна вага. Що більша вага цієї конструкції, то більше часу й  сил потрібно програмістам для осягнення системи й управління нею.

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

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

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

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

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

По-перше, парна робота не є обов’язковою. Ніхто не мусить робити цього з  примусу. По-друге, парна робота може бути періодичною. Існує багато вагомих причин час від часу працювати над кодом самостійно. Кількість програмістів, які працюють у парі, має становити десь 50 %. Ця цифра не є принциповою. Вона може коливатися від 30 до 80 %. Переважно це індивідуальний та командний вибір.

Що таке парне програмування?

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

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

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

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

Пари зазвичай недовговічні. Парне програмування може тривати цілий день, але найчастіше  — не більше години-двох. Навіть парна робота впродовж стислого терміну від 15 до 30 хвилин може бути корисною.

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

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

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

Навіщо потрібне парне програмування?

Ми працюємо в  парі й  поводимося як команда. Члени команди не діють ізольовано одне від одного. Натомість вони співпрацюють. Коли член команди відстає, інші закривають прогалину, утворену ним, і продовжують просуватися до мети. Робота в парі — це найкращий спосіб поділитися знаннями з членами команди та запобігти утворенню інформаційних бар’єрів. Це найкращий спосіб переконатися, що в  команді немає незамінних людей.

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

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

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

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