«Зрізання кутів» зараз обійдеться занадто дорого потім

Худоба Макфі

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

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

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

Тут мається на увазі одна з гнучких методик розробки, що отримала назву TDD (Test-Drived Design, проектування, направляемое тестами) У цій методиці відправною точкою процесу проектування є НЕ моделювання діаграм, а написання тестів – Прямуючи науч ред

BPEL (Business Process Execution Language) – заснований на XML мова формального опису бізнес-процесів і протоколів їх взаємодії (див http:// ruwikipediaorg / wiki / BPEL) – Прямуючи ред

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

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

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

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

Худоба Макфі (Scot Mcphee) – австралійський розробник і архітектор з 15-річним досвідом програмування та проектування додатків Останні 8 років працював головним чином з технологіями сімейства J2EE

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

*

*