Все починається з Архітектури

  1. Попередні п'ять років, до літа 2003 року, я був головним архітектором компанії IONA Technologies. ...
  2. Кодування vs. проектування
  3. Дві голови краще
  4. література
  5. На шляху до інтеграції
Попередні п'ять років, до літа 2003 року, я був головним архітектором компанії IONA Technologies. Пригадую, як в перший день керівник відділу кадрів знайомив мене з співробітниками, представляючи: «Наш новий головний архітектор». До кінця того ж дня один з моїх нових колег звернувся до мене, погано розуміючи, в чому полягають мої обов'язки. «У загальному і цілому, - зауважив він, розглядаючи стіни і стелю, - будівля виглядає непогано. І що Ви маєте намір з ним робити? »

У житті Архітектора програмного забезпечення рідко зустрічаються моменти безтурботних веселощів. Моє завдання - зробити так, щоб програми, що становлять основу наших продуктів, були гнучкими, швидкими, розширюваними, надійними, узгодженими, пов'язаними, не містили дублюючих компонентів і до того ж допускали використання максимально ефективних методів розробки. На перший погляд, в цьому немає нічого складного - за умови, що всі програмісти, а також менеджери прагнуть забезпечити всі ці якості, чи не так? На жаль, в нашій галузі відношення до справи, яке визначається формулою «я цього не робив і мені це не потрібно», поширилося вже в загрозливих масштабах. Іноді, навіть коли вдається впровадити Архітектуру, менеджери і розробники все одно примудряються її ігнорувати. Я б став мільйонером, якби отримував по долару за кожну почуту фразу на кшталт такої: «У мене немає часу для того, щоб домагатися відповідності цієї програми нашої архітектурі, я повинен здати її негайно». Подібне ставлення може виникнути через незнання, зарозумілості чи демонстративного нехтування програміста, але, як би там не було, підсумок все один: програмної архітектури або немає зовсім, або вона внутрішньо суперечлива.

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

Технологія як архітектура

Нещодавно мені довелося розмовляти з одним з клієнтів, і той, без тіні сумніву, заявив, що архітектурою інформаційних систем його компанії є Java Message Service (JMS). Зверніть увагу, він не сказав, що архітектура компанії спирається на обмін повідомленнями або що основу її реалізації становить JMS. Ні, він просто заявив, що їх архітектура - це JMS.

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

Сприйняття технології як архітектури обіцяє чимало неприємностей. Як і всі інші технології та специфікації, JMS, врешті-решт, втратить свою актуальність, і компанія мого клієнта буде змушена модернізувати свою «архітектуру». Але, з огляду на схильність клієнта до технологій, він, швидше за все, перескачет на що-небудь нове перш, ніж через прихильність JMS наявне у нього програмне забезпечення проміжного шару застаріє остаточно. Незалежно від того, що він вибере в наступний раз, витрати виявляться вельми істотними. В даному конкретному випадку клієнт, швидше за все, використовував можливості і інтерфейси, властиві саме обраної реалізації JMS. Ці специфічні можливості, швидше за все, «перемішані» зі стандартними можливостями JMS. Таким чином, навіть якщо виробник нової технології, прагнучи допомогти клієнту перетворити успадкований код JMS в нову систему, зможе запропонувати інструментарій того ж роду, він виявиться не дуже корисний. Компанія, якій не вдалося вибудувати системну архітектуру, буде змушена переписувати свою систему при кожній зміні технології.

З огляду на, наскільки високі витрати на перепроектування, незалежно від обсягу змін до базової технології, я не перестаю дивуватися, чому розробники самі себе заганяють в пастку. Можливо, слідуючи Теорії конспірації, вони це роблять для того, щоб забезпечити необхідну таємність своєї роботи, але більшість ІТ-фахівців з тих, з ким мені доводилося зустрічатися, просто про це не думають. Багато в чому це відбувається просто через нестачу абстрактного мислення. Одні розробники не в змозі відокремити наявні завдання від технологій, що використовуються для їх вирішення. Інші вважають, що у них просто немає часу на вироблення прийнятних абстракцій. Дійсно, ставлення «Відчепіться від мене, цю програму я повинен був зробити ще вчора», про який я вже згадував, в ІТ-галузі превалює. Може бути, саме тоді, коли мудрець уявив собі світ, заповнений реалізованими похапцем системами проміжного шару, йому прийшла в голову фраза «поспішиш - людей насмішиш»?

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

Створення визначень в термінах IDL (а не на Java або на C ++) дозволяє повторно використовувати інтерфейси для різних мов і описувати основні компоненти сервісних інтерфейсів, не вдаючись у зайві деталі реалізації. Обидва принципи дають можливість будь-якому розробнику за допомогою Web-браузера та обраного редактора (переважно, звичайно, emacs) висловити основні елементи і правила архітектури на прийнятно високому рівні абстракції.

Брак досвіду в створенні абстракцій може особливо негативно проявитися в контексті сервіс-орієнтованих архітектур (service oriented architecture, SOA) [1]. Розгортання SOA вимагає, щоб спочатку були визначені абстракції сервісів. Цим вона відрізняється від традиційного підходу, при якому спочатку пишуть додатки, а потім створюють конкретні сервіси, необхідні цьому додатку. При використанні SOA мета полягає в тому, щоб створити сервіси на прийнятному рівні абстракції, розраховані на багаторазове використання в різних додатках, а не жорстко прив'язані до одного з додатком.

Кодування vs. проектування

Коли я займав посаду головного архітектора, мій роботодавець вирішив впровадити в компанії методологію екстремального програмування (eXtremal Programming, XP) [2, 3]. І хоча деякі розробники рішуче заперечували проти прийняття XP, в кінцевому підсумку, ми були змушені на нього погодитися, коли наш генеральний директор, в минулому також розробник, прямо цього зажадав. Оскільки XP багато в чому спирається на підхід, схожий на дуже успішні методи итеративной розробки, які я запровадив у компанії кілька років до того, я активно підтримав вказівку генерального директора.

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

Впровадження XP у багатьох викликало негативну реакцію. Голосніше за всіх своє невдоволення висловлювали якраз розробники, котрі володіли великим досвідом проектування програм і створення абстракцій. Вони скаржилися на те, що XP змушує забути про архітектуру і проектуванні і замінює їх «програмуванням по-ковбойські». Вони стверджували, що XP дає розробникам свободу писати все, що вони хочуть, так що в результаті система працює зовсім не так, як очікувалося [4]. Передбачалося, що так званий «рефакторинг» стане методичним способом вдосконалення реалізації програмного забезпечення, не зачіпаючи його зовнішній інтерфейс або методи використання. Однак, на жаль, цей підхід часто використовують просто як виправдання нескінченним переробкам. Хоча XP, звичайно ж, не виправдовує подібну нісенітницю, він може сприяти формуванню менталітету «самотнього стрілка», особливо при відсутності належного спілкування з іншими членами команди. XP і інші ітеративні методи розраховані на те, що кожен член команди знає, що роблять інші. Фактично, XP підтримує парне програмування, при якому два розробника сидять за однією клавіатурою і інтерактивно вживають заходи, які реалізують проект і його тести. Такий підхід, зокрема, допомагає вберегтися від негативних ефектів діяльності ковбоїв від програмування.

Ті, хто противиться впровадженню XP, можуть стати його прихильниками, якщо ми приймемо методологію формування архітектури на базі моделей (model-driven architecture, MDA) [5]. MDA, дотримуючись традицій структурного і об'єктно-орієнтованого програмування, підтримує відкрите проектування. Однак, на відміну від них, MDA розглядає код як результат, який інструментарій генерує на основі проектних моделей, а не як текст, написаний розробником. Аргументи на підтримку MDA здаються цілком логічними. Дійсно, вся історія програмної розробки - це еволюція від написання машинного коду до створення програм на мові Асемблера і далі, до програмування на мовах високого рівня, таких як Java і C ++. З кожним наступним кроком збільшувався і рівень абстракції. Природний прогрес - це рух від низькорівневого програмування, при якому ви тільки пишете код, до високорівневою розробці шляхом створення моделей системи, залишаючи при цьому сам процес «програмування» інструментальним засобам генерації коду. До цих спроб відносяться використання шаблонів аналізу [6] і метадані для створення платформонезавісимость моделі (platform independent model, PIM), на основі якої інструментарій генерує код, званий платформозавісімой моделлю (platform specific model, PSM), для конкретної платформи або системи проміжного шару ( скажімо, J2EE, CORBA або MOM). PSM не тільки дозволяє використовувати шаблони, специфічні для нижележащей платформи, але і загальні шаблони проектування [7]. У певному сенсі MDA вимагає наявності інструментальних засобів, які грають роль, аналогічну ролі інструментарію, який раніше доводилося використовувати для визначення та проектування модульних інтегральних схем.

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

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

Особисто я більше схиляюся до XP, а не до MDA. XP обертається безпосередньо навколо головної цінності, що становить основу програмної системи: самого коду. Без коду не існує системи. Судячи з мого досвіду, прихильники MDA за краще розглядати код як побічний результат, який інструментарій просто генерує на основі відповідних моделей. Хоча я не сумніваюся, що в один прекрасний день ми зрозуміємо справжню мету руху до більш високого рівня абстракції, думаю, що це станеться дуже нескоро. Перехід від одного рівня абстракції до іншого на практиці - річ досить складна [8]. Фахівці з MDA визнають, що пройдуть роки, перш ніж можна буде насправді генерувати код складних програм проміжного шару, які зможуть коректно вирішувати такі завдання, як багатопоточність, транзакції, балансування навантаження і автоматичне відновлення після збоїв. Перш ніж настане цей день, ми розробимо ще безліч систем, і поки я залишаюся прихильником ітерацій, яке поділяється коду, тісної співпраці з користувачами і методів рефакторинга, аналогічних тим, що пропонує XP.

Дві голови краще

Описаний вище підхід, чітко визначає метафори системи, а також інтерфейси і контракти засобами абстрактних мов на зразок IDL, можна реалізувати і в рамках XP, і в рамках MDA. Звичайно, у кожного свій досвід, але особисто я вважаю, що, коли ці принципи реалізуються на основі відкритого і активного спілкування між членами групи, вони дозволяють легко уникнути необхідності готувати багатослівні документи з описом архітектури або використовувати спеціалізований інструментарій для малювання та зберігання діаграм Unified Modeling Language.

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

література
  1. S. Vinoski, "Service Discovery 101", IEEE Internet Computing, vol. 7, no. 1, 2003.
  2. K. Beck, Extreme Programming Explained: Embrace Change, Addison Wesley Longman, 1999..
  3. C. Poole, JW Huisman, "Using Extreme Programming in a Maintenance Environment", IEEE Software, vol. 18, no. 6, 2001..
  4. M. Fowler, Refactoring: Improving the Design of Existing Code, Addison Wesley Longman, 1999..
  5. D. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing, John Wiley & Sons, 2003.
  6. M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997..
  7. E. Gamma et al., Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
  8. S. Vinoski, "It's Just a Mapping Problem", IEEE Internet Computing, vol. 7, no. 3, 2003.

Стів Виноску ( [email protected] ) - головний інженер з нових продуктів компанії IONA Technologies. На програмному забезпеченні проміжного шару спеціалізується більше 15 років. Один з авторів книги «Сучасне програмування CORBA за допомогою C ++» (Advanced CORBA Programming with C ++, Addison Wesley Longman, 1999). Брав участь в стандартизації програмного забезпечення проміжного шару в OMG і W3C.

Steve Vinoski, Do You Know Where Your Architecture Is? IEEE Internet Computing, September-October 2003.

На шляху до інтеграції

Якщо компанії не вдалося вибудувати системну архітектуру, то її фахівцям доведеться переписувати систему при впровадженні кожної нової технології.

І що Ви маєте намір з ним робити?
На перший погляд, в цьому немає нічого складного - за умови, що всі програмісти, а також менеджери прагнуть забезпечити всі ці якості, чи не так?
Може бути, саме тоді, коли мудрець уявив собі світ, заповнений реалізованими похапцем системами проміжного шару, йому прийшла в голову фраза «поспішиш - людей насмішиш»?
Steve Vinoski, Do You Know Where Your Architecture Is?