Зробити наспіх і втекти – злочин

Ніклас Нільссон

Час наближається квечеру Команда дружно працює над новою функціональністю, запланованої для поточної ітерації здається, навіть повітря в кімнаті пульсує в робочому ритмі Однак Джон трохи поспішає: його чекає побачення Втім, він встигає дописати свою частину коду, компілює її, реєструє в системі управління вихідним кодом – і поспішно йде Кілька хвилин по тому загоряється «червоне світло»: збірка додатки порушена У Джона не було часу на автоматизовані тести, тому він поступив за принципом «зробити наспіх і втекти», через що застопорилася робота всієї команди

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

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

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

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

Ніклас Нільссон (Niclas Nilsson) – консультант і викладач в області розробки програмного забезпечення, а також письменник, глибоко захоплений мистецтвом програмування, цінитель гарної архітектури та дизайну Є одним із співзасновників factorlO і редактором матеріалів в співтоваристві архітектури ПЗ на сайті InfoQ

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*