Програми насправді не існують

ЧедЛавінь

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

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

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

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

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

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

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

Біографія автора наведена на стор 125

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

*

*