Подивіться з висоти 300 метрів

ЕрікДорненбург

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

Маленькі квадратики на архітектурних діаграмах представляють цілі системи, а лінії між ними можуть позначати все що завгодно: залежності, потоки даних або спільно використовувані ресурси (наприклад, шину) Такі діаграми зображують систему з висоти 10 кілометрів, приблизно в такому ж масштабі, в якому ми бачимо ландшафт з літака Єдиною альтернативою, як правило, є вихідний код, який можна порівняти з видом на рівні земної поверхні Обидва подання не в силах передати скільки-небудь істотної інформації про якість програмного продукту: одне знаходиться на дуже високому рівні, а інше настільки перевантажено деталями, що за ними не видно структури Очевидно, не вистачає проміжного варіанту – погляду з висоти 300 метрів

«Вид з висоти 300 метрів» надає інформацію на потрібному рівні Він обєднує великі обсяги даних і різні метрики (кількість методів, кількість залежностей1, Цикломатическая складність

Кількість залежностей (class fan out) визначається кількістю класів, на яких заснована реалізація даного класу Квадрат цієї величини визначає вартість підтримки поточної функціональності – Прямуючи науч ред

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

Створювати такі подання вручну і підтримувати їх синхронізацію з програмою – безнадійне заняття Потрібні інструменти, які здатні створювати такі подання на основі єдиного надійного джерела інформації – вихідного коду Для деяких уявлень, скажімо для структурної матриці рішень (design structure matrix), існують комерційні інструменти, проте спеціалізовані подання напрочуд легко створюються за допомогою обєднання невеликих інструментів, що витягають дані і метрики, із загальними пакетами візуалізації Простий приклад: висновок Checkstyle (по суті, набір метрик рівня класів і методів) завантажується в електронну таблицю для побудови діаграм Ті ж метрики можуть відображатися і у форматі ТгееМар з використанням інструментарію InfoViz Відмінним інструментом для відображення графів складних залежностей є також GraphViz

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

Ерік Дорненбург (Erik Doernenburg) – технічний директор компанії ThoughtWorks, Inc; він допомагає клієнтам у проектуванні та реалізації великомасштабних систем рівня підприємства

Цикломатическая складність (cyclomatic complexity) визначається шляхом підрахунку умовних і логічних операторів, циклів, операторів switch, блоків обробки виключень і т д в тілах всіх методів для визначення мінімального числа шляхів виконання програми Цей показник визначає складність покриття коду тестами Значення цього показника, що перевищує 10 (в загальному випадку), означає термінову потребу в рефакторінгу коду – Прямуючи науч ред

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

*

*