ITRampage

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

Чи можна намалювати мапу невідомої території?

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

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

Архітектори у баштах зі слонячої кістки

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

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

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

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

Я й досі не знаю теорії парсингу, не знаю точно що таке LALR (Look Ahead LR) чи LR (Left to right), трохи знайомий з WSN (Wirth Syntax Notation), але досить легко розробляю парсери чи генератори парсерів за граматиками на WSN (та парсери самого WSN) для зовнішніх предметно-орієнтованих мов (DSL). З висоти свого досвіду можу сказати, що неможливо повноцінно зрозуміти, як працює парсер чи генератор парсерів без того, аби реалізувати принаймні один. Також, можу сказати, що неможливо розробити ефективну архітектуру парсеру чи генератора парсерів без того, аби їх не реалізувати. Іншими словами, архітектурні артефакти пояснюють через візуалізацію як працює щось вже існуюче, а не диктують як щось повинне працювати.

Планування – не те, чим здається

Більшість людей розуміють планування неправильно. Їх планування – це фантазії про майбутне, а не набір тактик та ресурсів для їх застосування.

Планування більшості людей схоже на загострення топора для дуєлі на пістолях. Розробка архітектури рішення є прикладом саме такого планування.

Software – це не Hardware

Будь-яке software можна реалізувати в Hardware і навпаки, але є причини, чому і software і hardware існують одночасно.

Hardware неможливо змінювати, виправляти чи оновлювати. Його важко, дорого й затратно по часу виготовляти. Його неможливо виготовляти поступово, крок за кроком. Саме тому для Hardware існує upfront архітектура. Саме тому hardware реалізує дуже обмежені, базові можливості обчислень, якими вже користується більш гнучке Software. Для програмного забезпечення не можу бути адекватної upfront архітектури, бо інакше доцільніше було б реалізувати його як апаратне забезпечення.

Software – це і є план. Навіщо Вам ще якийсь план до планів, які мають постійно змінюватися, аби відповідати швидкоплинній реальності?! Це все дурня вигадана менеджерами, які отримують гроші за підготовку та дотримання планів. Менеджери рідко хочь щось розуміють у предметній області, бо вони просто-напросто погоничі (буквально!). Менеджери вважають, що дев’ять жінок здатні народити дитину за місяць і намагаються підкорити своїй примітивній моделі усі процеси, яких не розуміють.

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

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

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

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

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