Як моя команда може уникнути частих помилок після рефакторингу?

Щоб трохи ознайомитись: я працюю в компанії з приблизно дванадцятьма розробниками Ruby on Rails (+/- інтернів). Віддалена робота є загальною. Наш продукт складається з двох частин: досить жирне серцевина та тонка до великих замовницьких проектів, побудованих на ньому. Клієнтські проекти зазвичай розширюють ядро. Переписування ключових особливостей не відбувається. Я можу додати, що в ядрі є деякі досить погані частини, які потребують нагальної реконструкції. Є специфікації, але в основному для замовницьких проектів. Найгірша частина ядра неперевірена (не так, як це має бути ...).

Розробники розбиваються на дві команди, що працюють з одним або двома ПО на кожен спринт. Зазвичай один проект замовника суворо асоціюється з однією з команд та ОП.

Тепер наша проблема: досить часто ми ламаємо речі один одного. Хтось із команди A розширює чи рефакторирует основну функцію Y, викликаючи несподівані помилки для одного із замовницьких проектів команди B. Переважно зміни не оголошуються щодо команд, тому помилки потрапляють майже завжди несподівано. Команда B, включаючи PO, думала про функцію Y стабільною і не перевіряла її перед випуском, не знаючи про зміни.

Як позбутися від цих проблем? Яку "техніку оголошення" ви можете мені порадити?

Я б рекомендував прочитати « Ефективна робота зі спадковим кодексом» Майкла С. Пір’я . Це пояснює, що вам справді потрібні автоматизовані тести, як ви можете легко їх додати, якщо у вас їх ще немає, і яким "кодом пахне" рефактором яким чином.

Крім того, ще однією основною проблемою у вашій ситуації є відсутність спілкування між двома командами. Наскільки великі ці команди? Чи працюють вони над різними відставаннями?

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

У нас найгірша частина ядра неперевірена (як це має бути ...).

У цьому проблема. Ефективний рефакторинг сильно залежить від набору автоматизованих тестів. Якщо у вас таких немає, починають з’являтися проблеми, які ви описуєте. Це особливо важливо, якщо ви використовуєте динамічну мову на зразок Ruby, де немає компілятора, який би вловлював основні помилки, пов'язані з передачею параметрів методам.

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

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

Якщо ви заморозите поведінку вашого ядра, виконуючи випуск ^1, і ви додаєте його до приватної системи управління артефактами ² , то будь-який проект клієнта може оголосити про свою залежність від основної версії X , і він не буде порушений наступним випуском X + 1 .

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

Крім того, я думаю, вам потрібно краще визначити, що таке "ядро", а який підмножина - "ключ". Ви, здається, (правильно) уникаєте вносити багато змін у "ключові компоненти", але ви допускаєте часті зміни "основних". Для того, щоб на щось покластися, ви повинні тримати це стабільним; якщо щось не є стабільним, не називайте це стрижнем. Можливо, я міг би запропонувати називати це "допоміжними" компонентами?

РЕДАКТУВАННЯ : Якщо ви дотримуєтеся умов у системі Semantic Versioning , то будь-яка несумісна зміна API API повинна бути відзначена суттєвою зміною версії . Тобто, коли ви змінюєте раніше існуючу поведінку ядра або щось видаляєте, а не просто додаєте щось нове. Згідно з цією умовою, розробники знають, що оновлення з версії '1.1' до '1.2' є безпечною, але перехід від '1.X' до '2.0' є ризиковим і потребує ретельного перегляду.

^{1: Я думаю, що у світі Ruby 2 це називається дорогоцінним каменем
: еквівалент Nexus на Java або PyPI на Python}

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

Те саме для TDD. Я не бачу, як це може вирішити це.

Ваше рішення не технічне. Потрібно чітко визначити «основні» межі та призначити комусь роль «сторожового собаки», будь то ведучий розробник чи архітектор. Будь-які зміни в ядрі повинні пройти через цю сторожу. Він несе відповідальність за те, щоб кожен вихід з усіх команд об'єднався без занадто великих пошкоджень.

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

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

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

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

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

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

Усі ми знаємо, що одиничні тести - це дорога. Але ми також знаємо, що реально ретро підлаштувати їх до основи важко.

Конкретна методика, яка може бути корисною для вас при розширенні функціоналу, - це спробувати тимчасово та локально перевірити, чи не була змінена існуюча функціональність. Це можна зробити так:

Оригінальний псевдо код:

def someFunction
   do original stuff
   return result
end

Тимчасовий тестовий код:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

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

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

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

Без усього цього, одиничні тести не допоможуть багато, окрім того, як на останніх етапах зафіксують, що між частинами системи щось не збито. Ви хочете це знати, але ви хочете дізнатися це рано, дуже рано, і команди, що спілкуються між собою, координують зусилля, і насправді мають частий доступ до роботи, яку виконує інша команда (тому регулярні доручення, а не одна велика здійснювати через кілька тижнів або місяців, за 1-2 дні до пологів).
Ваша помилка НЕ ​​в коді, звичайно, не в коді іншої команди, яка не знала, що ви возиться з інтерфейсом, про який пишете. Ваша помилка у вашому процесі розвитку, відсутність спілкування та співпраці між людьми. Тільки те, що ти сидиш у різних кімнатах, не означає, що слід ізолювати себе від інших хлопців.

Перш за все, у вас є проблема комунікації (ймовірно, також пов'язана з проблемою побудови команди ), тому я думаю, що рішення вашої справи має бути зосереджено на ... ну, спілкуванні, а не на техніці розвитку.

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

Тож ми залишаємося з питанням спроб покращити комунікацію між командами. Це можна вирішити двома способами:

• з людьми. Це означає, що ваша компанія визначає когось як основного архітектора модуля (або будь-якого lingo, що підходить для вищого керівництва), який буде відповідати за якість та доступність коду. Ця людина втілить серцевину. Таким чином, вона поділиться всіма командами та забезпечить належну синхронізацію між ними. Крім того, вона також повинна виступати в ролі рецензента коду, присвяченого основного модуля для підтримки його узгодженості;
• з інструментами та робочими процесами. Наклавши на ядро неперервну інтеграцію , ви зробите сам кодовий код комунікаційним носієм. Спочатку для цього знадобляться певні зусилля (додавання в нього автоматизованих тестових наборів), але потім щомісячні звіти про ІС стануть грубим оновленням стану основного модуля.

Докладніше про CI як процес комунікації ви можете знайти тут .

Нарешті, у вас є проблема з відсутністю роботи в команді на рівні компанії. Я не є великим прихильником подій в командному будівництві, але це здається випадком, коли вони були б корисні. Чи регулярно проводяться загальнонаціональні зустрічі? Чи можете ви запросити людей з інших команд до ретроспектив вашого проекту? Або, можливо, пива ввечері в п'ятницю?