Page 8 - 4252

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

Підсумок
Архітектура - це принцип організації компонентів усередині системи: їх
кількість, якість, інтерфейси і протоколи взаємодії.
Що залежить від архітектури? Від неї залежить ціна на підтримку і розроб-
ку нових фіч, трудовитрати на побудову цілої системи з використанням даної
архітектури. Тобто формально від архітектури залежить найважливіший пара-
метр розробки - собівартість. А побічно ще і можливість повторного викорис-
тання коду, а разом з ним і зменшення трудовитрат на кожну подальшу розроб-
ку.
Добре, ми з'ясували що архітектура це дуже важливий аспект розробки.
Але що ж це таке? У контексті PHP5 додатки з упором в парадигму - це ієрар-
хія класів, інтерфейси та схеми їх взаємодії.
Вибір або створення архітектури залежить від конкретних завдань. На-
приклад, наскільки універсальним планується додаток, які модулі повинні бути
присутніми, яка запланована навантаження на ресурс.

ПРИНЦИПИ ПРОЕКТУВАННЯ

Якість архітектури

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

7