Команда успадковує модуль виставлення рахунків, який ніхто до кінця не розуміє. У ньому немає тестів, що захищають існуючу поведінку. Запропоновано спринт для його «очищення», і план полягає в тому, щоб переписати ядро в новій структурі. Ніхто не може сказати, як вони дізнаються, що нова версія все ще правильно стягує плату з клієнтів.
Це ілюстративний сценарій, а не задокументований інцидент. Він описує прогалину, яку має заповнити навчальний проект з рефакторингу: інженери, які бачать, що код є безладним, але ще не можуть спланувати обмежене покращення та показати, що поведінка була збережена.
Цей посібник призначений для керівників інженерних відділів та менеджерів з інженерії. У ньому розповідається, як описати проблему продуктивності, діагностувати прогалини, підготувати та практикувати проектування, опрацювати кейс та оцінити, чи можна застосувати навички до реальної роботи. Йдеться про проектування навчання. Код, тести та правила вашої програми повинні бути перевірені старшими інженерами вашого власного стеку.
Що таке навчальний проект з рефакторингу?
Навчальний проєкт з рефакторингу — це структурована робота над застарілим кодом, метою якої є нарощування можливостей, так і покращення коду. Учні планують невеликі, обмежені зміни, захищають існуючу поведінку за допомогою тестів, покращують дизайн невеликими кроками та демонструють докази того, що нічого не зламалося. Код стає кращим, і, що ще важливіше, інженери практикують судження, яке їм знадобиться щодо реального технічного боргу.
Швидкі факти
| Питання | Коротка відповідь |
|---|---|
| Яке завдання? | Планування та перевірка обмеженого покращення застарілого коду. |
| Який бал ви отримуєте? | Аналіз ризиків та докази збереження існуючої поведінки. |
| Чи є широке переписування хорошим навчальним проектом? | Зазвичай ні. Це приховує навичку, що відпрацьовується, і ускладнює демонстрацію збереженої поведінки. |
| Чи достатньо тесту на тему шаблонів рефакторингу? | Ні. Це підтверджує передумови, але не те, чи може інженер планувати та перевіряти зміни. |
| Хто перевіряє зміст? | Менеджер з інженерії та старший інженер, який знає кодову базу. |
| Чого не можуть виправити тренування? | Відсутність випробувального обладнання, тиск скидання, нечіткість власності та брак часу на технічне обслуговування. |
| Звідки ви знаєте, що це спрацювало? | Новий, небачений раніше кейс із використанням застарілого коду, оцінений за узгодженими критеріями, з подальшим відстеженням реальної роботи. |
1. Опишіть проблему продуктивності
Почніть із завдання: сплануйте та перевірте обмежене покращення застарілого коду. «Обмежене» – важливе слово. Учень вибирає зміну, достатньо малу для завершення, і може сказати, що входить, а що виходить за межі області застосування.
Важливо бути точним у термінології. Мартін Фаулер описує рефакторинг як контрольований метод покращення дизайну існуючої кодової бази, що складається з невеликих трансформацій, що зберігають поведінку. Фраза «збереження поведінки» – це те, що відрізняє рефакторинг від переписування, і саме це має бути помітно під час навчання. Сама метафора технічного боргу був придуманий Вордом Каннінгемом, а обговорення Фаулера є корисним нагадуванням про те, що борг можна брати навмисно та розсудливо, тому не кожен незручний модуль є помилкою, яку потрібно виправляти.
Книга Майкла Фезерса про застарілий код дотримується тієї ж практики. У описі видавця зазначено, що вона навчає розробників писати тести, які гарантують вони не змінюють додаток ненавмисно, а також взяти під контроль існуюче програмне забезпечення без повного переписування.
Напишіть заяву про продуктивність одним реченням і попросіть керівника інженерного відділу перевірити її: «Враховуючи застарілий модуль і визначену мету, інженер пропонує обмежену зміну, додає тести, які визначають поточну поведінку, вносить зміни невеликими кроками та показує, що поведінка зберігається».
2. Діагностуйте прогалини у навчанні та контексті
Перш ніж щось створювати, порівняйте необхідне завдання з тим, що ви зараз практикуєте та оцінюєте. Зазвичай три питання відрізняють прогалину в навчанні від чогось іншого:
- Чи використовує сучасна практика реальне завдання? Якщо навчання охоплює шаблони рефакторингу у слайдах, але ніхто ніколи не змінює непротестований код, ніхто не практикував захисну поведінку. Якщо оцінювання – це тест із множинним вибором на запахи коду, воно вимірює запам'ятовуваність.
- Що таке когнітивний попит? У переглянутій таксономії Блума оцінка безпеки змін здійснюється на рівнях аналізу та оцінки, а розробка плану та тестування сягає рівня створення. Зіставлення дій з цими рівнями розглядається в нашому посібнику зіставлення навчальних завдань з таксономією Блума.
- Чи щось, окрім навичок, заважає? Перевірте персонал, інструменти та процедури. Якщо збірка займає годину, ніхто не буде часто проводити тести. Якщо технічне обслуговування ніколи не планується, інженери будуть рефакторингувати лише таємно. Повідомляйте про причини, не пов'язані з навчанням, людям, які можуть їх виправити.
3. Розробіть цілеспрямовану підготовку та практику
Як тільки ви зрозумієте, які прогалини може заповнити навчання, дайте кожному етапу окреме завдання.
Підготовка. Перевірте передумови за допомогою короткої діагностики: як працює ваша тестова структура, що таке тест характеристики та як ваша команда перевіряє та об'єднує матеріали. Для цього етапу підходить самостійне навчання. Перевірка повторення підтверджує лише передумови.
Практика. Використовуйте систематичні проекти рефакторингу з чіткою структурою. Почніть з невеликого, безпечного зразка, а потім переходьте до реальної, але обмеженої частини вашої власної кодової бази. Ката «Позолочена троянда» – це добре відома відправна точка для першого кроку. Це README, який підтримується Емілі Бейч. рекомендує писати тести перед зміною коду і розглядає вправу як практику у виконанні невеликих кроків, частому запуску тестів та поступовому вдосконаленні дизайну. Розумна послідовність для кожного проекту така: визначити мету та межі, написати тести, які фіксують те, що робить код сьогодні, змінювати по одному елементу за раз, запускати тести після кожного кроку та записувати те, що ви дізналися.
Зворотний зв'язок. Пов’язуйте зворотний зв’язок із рішеннями, а не із загальною оцінкою. Фраза «Ви витягли логіку знижок, але ваші тести охопили лише щасливий шлях, тому ви могли не помітити зміни округлення» корисніша, ніж «3 з 5».
Вступ викладача в реальному часі чи асинхронний огляд? Живий внесок додає найбільшої цінності, коли вибір неоднозначний, наприклад, чи зупинитися та додати пропущений тест, чи продовжити. Асинхронного перегляду достатньо, коли учні порівнюють свій план і тести з анотованою експертною версією. Багато команд використовують обидва варіанти: спочатку підготовку у власному темпі, а потім фасилітовану сесію зі складних випадків.
4. Розгляньте реалістичний приклад
Ілюстрація. Керівник інженерного відділу повинен перевірити кейс та критерії відповіді перед використанням.
Справа. Застаріла функція обчислює загальну суму замовлення, включаючи знижку, податок та правило доставки. Вона не має тестів. Команда пропонує реструктуризувати весь модуль виставлення рахунків, щоб зробити його «чистішим».
Завдання. Учень пояснює, що він робитиме, наводить зібрані докази та вказує, яка додаткова інформація чи підтримка йому потрібна.
Перша спроба. «Я б розділив модуль на три сервіси та переніс логіку, а потім перевірив би цифри на етапі підготовки». Учень обрав значну зміну та пізню ручну перевірку. Немає можливості сказати, чи стара та нова версії узгоджуються щодо граничних випадків.
Зворотній зв'язок та повторна спроба. Рецензент запитує, що функція робить сьогодні для порожнього кошика, знижки, яка робить загальну суму від'ємною, та випадку округлення. Повторна спроба просить учня звузити область до однієї поведінки та сказати, як він доведе, що вона не змінилася.
Сильніша спроба. «Я б поки що залишив структуру модуля в спокої. Я б записав те, що функція order total повертає сьогодні для набору вхідних даних, включаючи граничні випадки, як тести. Потім я б витягнув розрахунок знижки в окрему функцію, запустив тести після цього єдиного кроку та зупинився. Я б зазначив, що правило доставки має поведінку, яку я не розумію, і запитав би колегу, перш ніж торкатися його». Зверніть увагу, що ця відповідь обмежує зміни, спочатку захищає поведінку та називає те, що невідомо.
Чому кожна відповідь є обґрунтованою або неповною. Оцінюйте кожен варіант за затвердженими критеріями, а не за вподобаннями рецензента. Перша спроба може бути розумним довгостроковим напрямком, але вона є неповною як план, оскільки не містить жодних доказів збереженої поведінки. Більш переконлива спроба є невеликою, такою, що перевіряється, та чесною щодо невизначеності.
5. Оцінка можливостей та планування передачі
Доказом можливостей є виконання нового випадку зі старим кодом, з яким учень ще не стикався. Оцініть аналіз ризиків та докази збереження поведінки. Проста рубрика використовує шкалу від 0 до 2 за кожен критерій:
| критерій | Спостережувані докази |
|---|---|
| Виконання завдання | Планує та перевіряє обмежене покращення застарілого коду, а також записує дії та докази, що стоять за ними. |
| Обґрунтування | Пояснює обмеження, альтернативи та невизначеність, а також перевіряє ризики та докази того, що поведінка була збережена. |
| Межі | Використовує затверджені процедури та звертається по допомогу, коли інформації чи повноважень недостатньо. |
Опорні точки: 0 – відсутнє або непідтверджене, 1 – часткове з відповідними пропусками, а 2 – повне та обґрунтоване відповідно до узгоджених критеріїв. Визначте критичні помилки окремо, такі як зміна поведінки без проведення тесту, який би це помітив, тому загальний бал не може їх приховати. Ця рубрика є пропозицією, а не затвердженим стандартом готовності: адаптуйте її разом з керівником інженерії та випробуйте. Наш посібник з розробка інтерактивної практики з корисним зворотним зв'язком показує, як писати відгуки, що посилаються на рішення.
Плануйте перенесення ретельно. Після вправи дайте кожному інженеру невеликий, реальний борг для обговорення з рецензентом або проведіть короткий ретроспективний огляд нещодавньої зміни, яка щось зламала. Перевіряйте перенесення після відповідного досвіду реальної роботи, а не одразу після семінару.
Де допомагає інтерактивна доставка
Інтерактивні формати допомагають усім взяти на себе зобов'язання, перш ніж вони побачать групу. Під час живої сесії фасилітатор може показати короткий фрагмент застарілого коду, попросити кожного інженера надіслати першу зміну, яку вони внесуть, і як вони доведуть її безпеку, а потім розкрити розгортання перед обговоренням. Той самий запит може виконуватися у власному темпі для підготовки. AhaSlides підтримує інтерактивне навчання та перехід між живою та самостійною подачею. Це інструмент для презентацій та навчання, а не місце для запуску чи аналізу коду, тому запускайте сам рефакторинг у власному середовищі. Перевірте будь-яку конкретну функцію створення, зворотного зв'язку чи звітності, на яку ви плануєте покладатися, відповідно до вашого власного робочого процесу. Щоб отримати рекомендації щодо вибору форматів, дивіться нашу статтю про коли використовувати адаптивне, інтерактивне та живе навчання.
Виміряйте, що змінилося
Заздалегідь вирішіть, що покаже, що інженери можуть виконати завдання. Порівняйте якість аналізу ризиків та докази збереженої поведінки на невидимому випадку з базовим рівнем. Визначте, хто включений, знаменник та терміни. Якщо результати покращаться, перевірте, що ще змінилося за той самий період, наприклад, нові інструменти для тестування, швидше складання або зміна власника, перш ніж зараховувати навчання.
Обмеження, які можуть залишитися
- Час для проведення робіт з технічного обслуговування. Якщо роботи з боргами ніколи не плануються, кваліфіковані інженери все одно не матимуть де застосувати ці навички.
- Тестове оснащення. Без зручного випробувального ремня або швидкого складання важко підтримувати дрібні кроки та часті перевірки.
- Покриття справ. Один із застарілих випадків демонструє кілька видів ризику. Оцінка не описує судження інженера загалом.
- Оцінювання того, коли не проводити рефакторинг. Деякий код краще не змінювати, замінювати або взагалі не використовувати, і це рішення вимагає більше, ніж просто навичок.
- Трансфер Виконання в ката не те саме, що виконання в виробничому модулі під тиском.
Заздалегідь назвіть їх спонсорам та сплануйте окремі виправлення. Навчання покращує те, що інженер може планувати та доводити. Воно не створює часу чи інструментів.
Часті питання
Що таке навчальний проект з рефакторингу?
Це структурована практика роботи зі застарілим кодом, де інженери планують невеликі зміни, захищають існуючу поведінку за допомогою тестів, змінюють дизайн невеликими кроками та показують, що нічого не зламалося.
Чи є повне переписування гарним способом дізнатися про технічний борг?
Зазвичай ні. Переписування є великим, його важко перевірити, і воно приховує навичку, яку ви хочете розвинути. Обмежена зміна з тестами, що фіксують поточну поведінку, робить логіку видимою.
Як ви оцінюєте, чи можуть інженери безпечно проводити рефакторинг?
Наведіть новий випадок зі старим кодом та оцініть аналіз ризиків і докази збереження поведінки відповідно до узгоджених критеріїв. Тест на шаблони рефакторингу підтверджує лише передумови.
Вам потрібна зразкова кодова база для навчання?
Вам потрібне безпечне місце для тренувань. Багато команд починають із загальнодоступного ката, а потім переходять до обмеженої частини власного коду. Ваш інженер-менеджер повинен підтвердити придатність коду.
З чого почати
Виберіть один невеликий, періодично впроваджений тип застарілих змін у вашій кодовій базі. Напишіть опис продуктивності, попросіть керівника інженерії перевірити випадок та тести, які б показали збережену поведінку, а також складіть трикритерійну рубрику зі шкалою від 0 до 2 та списком критичних помилок. Проведіть пілотне випробування з невеликою групою, перш ніж розгортати.
Щоб побачити, як вправу з прийняття рішень щодо рефакторингу можна виконати в режимі реального часу з вашою власною командою та використовувати повторно у власному темпі згодом, ознайомтеся з AhaSlides.
