Кращі програми не будують – їх вирощують

Білл де Ора

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

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

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

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

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

3Назва цього антіпаттерна явно перегукується з книжкою «Death March» (Йордон Е «Шлях камікадзе» – М: Лорі, 2008) – Прімечред

Джерело: Форд Н, Найгард М, де Ора Б, 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>

*

*