Еволюціонує архітектура і стихійне проектування: Дослідження архітектури та проектування

1. Серія контенту:
2. Цей контент є частиною серії: Еволюціонує архітектура і стихійне проектування
3. визначення архітектури
4. архітектура програми
5. архітектура підприємства
6. існуючі визначення
7. визначення проектування
8. Малюнок 1. Спектр підходів до проектування
9. Загальні питання архітектури і проектування
10. Капітал і відсотки
11. Малюнок 2. Технічні борги і відсотки
12. Складність необхідна і привнесена
13. нестримна спільність
14. плани
15. Ресурси для скачування

Еволюціонує архітектура і стихійне проектування

Шляхи до поліпшення сопровождаемости проектів і архітектур

Серія контенту:

Цей контент є частиною # з серії # статей: Еволюціонує архітектура і стихійне проектування

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Эволюционирующая+архитектура+и+стихийное+проектирование

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Еволюціонує архітектура і стихійне проектування

Слідкуйте за виходом нових статей цієї серії.

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

визначення архітектури

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

архітектура програми

Архітектура програми описує основні великі частини, складові додаток. Наприклад, в світі Java архітектура додатки описує дві речі: комбінацію програмних інфраструктур, яка використовується для створення конкретного додатка - т.зв. архітектури рівня інфраструктур - і більш традиційне логічне поділ обов'язків, для якого я залишу найменування архітектура програми. Виділення архітектури інфраструктур як окремої сутності має сенс тому, що більшість практикуючих фахівців з об'єктно-орієнтованим мовам прийшли до висновку, що окремі класи як механізм повторного використання коду неефективні. (Коли в останній раз ви завантажували з Інтернету для використання в проекті один-єдиний клас?) Одиниця повторного використання в сучасних об'єктно-орієнтованих мовах - це бібліотека або програмна інфраструктура. При запуску нового проекту на мові з потужним набором програмних інфраструктур, такому як мову Java, однією з перших архітектурних проблем є архітектура додатки на рівні інфраструктури. Цей стиль повторного використання настільки глибоко укорінився в світі Java, що вже пора говорити про Java не як про об'єктно-орієнтованої мови, а як про інфраструктурно-орієнтованому. Багато в чому, архітектура рівня програмної інфраструктури представляє фізичну структуру, описану конкретними будівельними блоками.

З іншої точки зору, архітектура додатки описує, як поєднуються логічні частини програми. Це сфера шаблонів проектування і інших структурних описів, тому вона має тенденцію до більшої абстракції і швидше логічному, ніж фізичній опису. Наприклад, можна сказати, що Web-додаток дотримується паттерна Model-View-Presenter, без вказівки того, яка програмна інфраструктура використовується для досягнення цієї логічної компонування. Ця логічна компонування, найімовірніше, зображена на всіх маркерних дошках у вашому офісі після початку роботи над новими частинами програми.

архітектура підприємства

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

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

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

існуючі визначення

Визначення архітектури програмного забезпечення давали багато розумних людей, тому я відішлю читача за їжею для роздумів до них. У своїй класичній праці "Who Needs an Architect?" (Див. ресурси ) Мартін Фаулер розглядає кілька визначень. Перше визначення взято зі списку розсилки з екстремального програмування:

"RUP, відштовхуючись від визначення IEEE, визначає архітектуру як найвищий рівень опису концепції системи в її середовищі. Архітектурою програмного забезпечення системи (на даний момент часу) є організація або структура істотних компонентів, що взаємодіють за допомогою інтерфейсів; при цьому ці компоненти в свою чергу складаються з більш дрібних компонентів і інтерфейсів ".

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

Потім Фаулер цитує Ральфа Джонсона (Ralph Johnson), який оскаржує дане вище визначення у відповіді списку розсилки:

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

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

У вищезгаданій статті сам Фаулер дає одне з моїх улюблених визначень архітектури:

Архітектура визначає найголовніше. Що б це не було ".

Це визначення злегка розпливчасто, але при цьому дуже виразно. Багато суперечки з приводу архітектури та проектування виникають від нерозуміння того, що насправді важливо. Для бізнес-аналітика важливо одне, для архітектора - інше. Це визначення природно показує, що необхідно визначити власні терміни з вашого середовища, перш ніж намагатися визначати інші речі.

Визначення Фаулера також підкреслює ще один важливий аспект у визначенні таких тонких речей, як архітектура. "Важливе" не просто по-різному для різних людей і груп; ці відмінності можуть бути взаємовиключними. Наприклад, практично всі SOA балансують між гнучкістю і швидкістю. Працююча у вас стара клієнт / серверна система майже напевно швидше, ніж йде їй на зміну нова версія з Web-інтерфейсами, портлетнимі двигунами і сервісами. Якщо новий додаток написане не геніальними розробниками, додавання додаткових шарів гнучкості призводить до збільшення часу відгуку для користувачів, в результаті чого погіршується оперативність. Можливо, ваш архітектор з тих, хто говорить користувачам: "Так, до речі, нова SOA, яку ми встановлюємо, значно полегшить ваше життя, але працювати ви будете повільніше. Вибачте". Може бути, саме тому архітектори отримують більше, ніж розробники.

А тепер моє улюблене визначення архітектури:

"Те, що потім важко змінити".

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

Закінчуючи обговорення архітектури, було б недоглядом НЕ обговорити саму посаду "архітектор". Кадровикам не подобається, що в нашій галузі такі погані визначення посад. Багато організацій хочуть просунути на більш високу посаду своїх кращих розробників - тих, хто приймає важливі рішення з приводу речей, які важко змінити пізніше, - але терміна краще, ніж "архітектор" в галузі не існує. Також немає і загальне опису посадових обов'язків, тому кожна компанія сама визначає, що ця роль означає. Деякі з архітекторів нагадують Архітектора в кінці другої частини фільму "Матриця" (якого Фаулер кваліфікує як Architectus Reloadus). Це архітектори, які в останній раз писали програмний код десяток років тому, а зараз приймають важливі рішення в компанії. Єдиний інструмент розробника, який вони використовують - це Visio.

Альтернативний варіант архітектора, по Фаулеру, називається Architectus Oryzus (в честь мого колеги Девіда Райса). Такі архітектори активно вносять код в проект, допомагаючи іншим розробникам на найважчих ділянках. В їх обов'язки також входить взаємодія з іншими учасниками проекту, що гарантує, що всі говорять на одній мові, використовують одні і ті ж визначення і розуміють ті частини системи, які їм належить розуміти. Очевидно, таку активну участь має вирішальне значення для досягнення поставлених цілей в еволюціонує архітектурі, і тому ще не раз буде згадуватися в цій серії.

визначення проектування

Більшість розробників мають гарне уявлення про те, що таке проектування, тому я не буду витрачати час на визначення. Проект детально описує, як компоненти програми з'єднуються між собою. Проектування включає в себе такі добре вивчені області, як шаблони проектування, рефакторинг, інфраструктури програмування та інші речі, з якими щодня має справу розробник. Спектр підходів до проектування тягнеться приблизно від BDUF (Big Design Up Front - Великий Початковий Проект) до Cowboy Hacking (ковбойські хакерство), як показано на малюнку 1:

Малюнок 1. Спектр підходів до проектування

Ліва частина спектра на малюнку 1 передбачає, що можливо передбачити всі сотні і тисячі проблем, які з'являються при розробці програмного забезпечення, і намагається скоротити витрати часу на їх рішення. Детальніше про це буде сказано в наступних частинах. Хоча я не став витрачати час на визначення проектування, це не означає, що я не буду багато говорити про нього. Основна частина цієї серії присвячена різним аспектам того, як зробити так, щоб проект виникав сам в процесі розробки, а не вирубувався з каменю перш, ніж будуть написані перші рядки коду.

Загальні питання архітектури і проектування

Маючи тепер робочі визначення архітектури та проекту, я хочу заглибитися в кілька спільних проблемних областей. Всі ці питання зачіпають архітектуру і проектування на фундаментальному рівні, і їх попередній розгляд дозволить посилатися на них пізніше в цій серії. Спочатку обговоримо технічний борг, потім складність, і, нарешті, нестримна спільність.

Капітал і відсотки

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

Розробка програмного забезпечення - це не риття канави. Компроміси під час риття канави означають, що ви просто отримаєте не ідеально рівну канаву. Недоліки сьогоднішньої канави не заважають викопати хорошу канаву завтра. Але програмне забезпечення, побудоване сьогодні, є фундаментом для майбутнього. Компроміси в програмному забезпеченні, допущені сьогодні в ім'я доцільності, вже завтра стають причиною зрослої ентропії. У книзі The Pragmatic Programmer Енді Хант і Дейв Томас говорять про ентропії у виробництві ПО і причини її шкідливого впливу (див. ресурси ). Ентропія є мірою складності, і якщо тимчасове рішення додає складність зараз, за ​​нього доведеться платити весь термін життя проекту.

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

Малюнок 2. Технічні борги і відсотки

Можна порівняти власну складність вирішення з капіталом, а додаткові зусилля, пов'язані з минулими «зрізання кутів» - з відсотками. Але складність - це цікава тема сама по собі.

Складність необхідна і привнесена

Проблеми, які вирішує програмне забезпечення, мають свою внутрішню складність, яку я називаю необхідною. Інша справа - складність, яка виникає у зв'язку з компромісами, через технічні боргів. Вона включає всі нав'язані ззовні підходи, які ускладнюють програмне забезпечення, і, в ідеалі, вона повинна бути відсутнім. Я називаю її привнесеної складністю. Ці терміни детально визначаються й обговорюються в книзі The Productive Programmer (див. ресурси ). Ці терміни не є чітко визначеними: як і поняття проекту, вони характеризують деякі ділянки безперервного спектру. Кілька наведених нижче прикладів допоможуть прояснити їх відмінність.

Один з моїх колег працював над системою нарахування заробітної плати в компанії, працівники якої були об'єднані в профспілку. Однією з пільг, обумовлених профспілкою для деяких своїх членів, був додатковий вихідний день на початку мисливського сезону. (Схоже, у них були хороші переговорники). Всі порушені працівники працювали на одному заводі, але можливість надання додаткового вихідного була узаконеним вимогою до системи нарахування заробітної плати для всієї компанії. Внесене зміна додало багато складнощів в програму, але це була необхідна складність, оскільки вона вирішувала частина бізнес-завдання.

Інший Постійно вінікає приклад, розташованій немного далі по спектру: безпека полів форм введення. Много людей з боку бізнесу думають, что хотят детально контролюваті всі Параметри безпеки шкірного поля. На практике, коли такий контроль реалізується, смороду почти всегда обурюються, оскількі це створює велике НАВАНТАЖЕННЯ на Користувачів, Яким необходимо візначаті и зберігаті всі ЦІ метадані. В одному з наших проектів представник бізнесу Дійсно Хотіли мати Цю функцію, тому ми реалізувалі ее для них частково, на одному екрані. Як только смороду Самі, на власному досвіді, побачим, скільки зусіль нужно для использование такого контролю, смороду відразу вірішілі, Що оскількі доступ до додатка Доступний только з замікалі на ключ офісу, краще використовуват НЕ настолько детальне управління безпеки. Це відмінний приклад проектного рішення, що виникає стихійно після того, як представники бізнесу побачили в реальності, чого вони вимагали.

У дальньому кінці цього спектра розташовані привнесені складності чисто технічної природи, як перші двома версіями технології Enterprise JavaBeans (EJB) і інструментам BizTalk. У деяких проектах додаткові накладні витрати, пов'язані з цими засобами, виправдані, але в більшості випадків вони тільки додають складності.

Привнесена складність часто виникає з трьох речей. Перша вже обговорювалася: «времянки» в коді через графік і інших зовнішніх факторів. По-друге, дублювання, те, що в книзі Pragmatic Programmers називається порушенням принципу DRY (Do not Repeat Yourself - не повторювати). Дублювання - другий за значимістю шкідливий фактор при розробці програмного забезпечення, оскільки воно має тенденцію проникати повсюдно при повному невіданні розробників. Очевидний приклад - це копіювання і вставка коду, але є і безліч більш складних випадків. Наприклад, майже в кожному проекті, який використовує інструменти об'єктно-реляційного відображення (подібні Hibernate або iBatis), зустрічається багато дублювання. Схема бази даних, XML-файл відображення і відповідні класи POJO містять трохи різну, але перетинає інформацію. Можна усунути цю проблему, створивши канонічний джерело такої інформації і генеруючи з нього інші елементи. Дублювання шкодить проектам, оскільки заважає спробам структурних змін і рефакторінга. Якщо відомо, що щось потрібно змінити в трьох різних місцях, ви будете уникати робити це, навіть якщо це обіцяє зробити код краще в довгостроковій перспективі.

Третій фактор, який породжує привнесену складність - це незворотність. Будь-яке рішення, яке не може бути звернено назад, в кінцевому підсумку призводить до появи привнесеної складності. Незворотність позначається як на архітектурі, так і на проекті, хоча збиток все-таки більше поширюється на архітектурний рівень, як на більш загальний. Необхідно всіма силами уникати рішень, які неможливо або обтяжливо повернути назад. Одна з мантр, яку, за чутками, використовують деякі з моїх колег: дочекатися останнього відповідального моменту. Це не означає, що рішення має бути відкладено на період, коли буде вже занадто пізно, але все-таки часу має пройти досить багато. Що являє собою останній відповідальний момент, в який ви можете вибрати якийсь архітектурне рішення? Чим довше можливо уникати цього рішення, тим більше можливостей залишаються відкритими. Запитайте себе: "Мені дійсно потрібно прийняти це рішення зараз?" �� "Що я можу зробити для того, щоб можна було відкласти це рішення?". Дивно, як багато всього можна відкласти до останнього при деякій винахідливості в процесі прийняття рішень.

Розмежування, яке я раніше зробив між архітектурою рівня програмної інфраструктури та архітектурою додатки, природним чином узгоджується з принципом Останнього Відповідального Моменту. Архітектура програми, як правило, є логічною. Наприклад, припустимо, що ви вирішили розділити завдання по шаблону Model-View-Presenter. Дуже часто відразу робиться великий крок до фізичної реалізації цієї логічної архітектури шляхом вибору програмної інфраструктури, яка відповідає деяким або всім з відповідних вимог. Подумайте, чи можна відкласти це рішення, тому що вже обрана фізична реалізація обмежує можливості прийняття інших рішень. Максимальна відстрочка вибору програмної інфраструктури залишає відкритими не забруднену реальністю можливість вибору кращих варіантів.

нестримна спільність

Останню із загальних проблем архітектури і проектування я назвав нестримної спільністю. Схоже, в світі Java з'явилася хвороба: надмірне ускладнення рішень в спробі зробити їх максимально загальними. Мотивація для цього зрозуміла: чим більше додається шарів для розширення, тим легше буде розширювати рішення згодом. Однак це небезпечна пастка. Спільність додає ентропії і тим самим завдає шкоди здатності розвивати цікаві шляхи рішень на початку проекту. Додавання надмірної гнучкості ускладнює всі наступні зміни вихідного коду.

Звичайно, розширюваність не можна ігнорувати. В ідеології agile-розробки є велика фраза, яка підсумовує весь процес реалізації функцій програми: YAGNI (You Is not Gonna Need It - не роби те, що не потрібно). Це мантра допомагає уникнути зайвого ускладнення простих функцій. Просто робіть те, що потрібно зараз, і якщо якийсь функціонал знадобиться пізніше, то потім і додавайте. Я бачив Java-рішення, настільки набиті компромісами в архітектурі та проектуванні заради спільності і розширюваності, що це призводило до провалу проекту. Парадоксально, але планування проекту з розрахунком на максимально довге життя в результаті вкорочувало її. Навчитися рухатися по тонкій грані між розширюваністю і надмірною складністю непросто, і я буду до цього часто повертатися.

плани

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

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів